denoの備忘録 2024/10~
ちょっとしたdenoのスクリプトをv1からv2にmigrationしたりjsrを使うように書き換えるなどしてみてdenoをしてみたくなった。
気になったことを書いていく
v1 -> v2 migration + jsr
- deno.lockの更新方法がわからなかった
- denoのimportの書き方がわからなかった (with deno.json)
-
https://deno.land/std@<version>/*
@std/*@<version>
への変更方法がわからなかった - nodeのpolyfillの使い方がわからなかった (今もわかっていない)
💭 あと、github copilotがほとんど役に立たなかった
一番わかりづらかったのが @std/*
のどこに何があるかという移行先の部分かも?
そのあとimportの記述の仕方にモヤモヤを抱えていた
- deno.jsonのimport mapとファイルに書くimportとdeno.lockの兼ね合い
- ファイル単位でimportするべき?
- 末尾の
.ts
は付ける?
- 末尾の
結局のところnodeのpolyfillの使い方がわかってなかった
- "node:<path>" でimportするみたい
- そもそも node APIというセクションがドキュメントに用意されている
jsrの検索が微妙な気がする。。
どうやらarchivedされたパッケージは検索の対象に載らないがそのページは存在するみたいな感じらしい。混乱した。
-
@std/flags
がdeprecatedらしい - deprecatedなパッケージを一覧で表示して確認したい
- jsrの検索結果の一覧に
deprecated
みたいなラベルがついていると嬉しい -
@std/flags
というクエリーで検索しても@std/flags
が先頭に来ないし/flags
だけのものとか絞れない?
jsrをCDNのようにして使う方法あるんだろうか?
とりあえず、jsxをちょっとしたテンプレートエンジンとして使うことから始めて色々考えてみる。
サーバー側で動くコードはあまり欲しくない気がする。今のところはhtmlに変換されるような何かが欲しい。
- denoでtsxを実行はできる
- hono/jsxを使ってみる
- hono/jsxを文字列を返す方法で使う方法はわかっていない
- preactを使ってみる
コマンドライン引数パーサーに関するもやもやを吐き出した
denoの逆引き
denoのちょっとした作業を忘れてしまうのでメモ
deno.lockの更新
以下のような形で更新する --lock
は省略するとdeno.lockを更新する
$ deno cache --lock deno.lock <file>
format
$ deno fmt <file>
lint
$ deno lint <file>
型チェックは (deno run
の際には行われない)
$ deno check <file>
denoの更新
deno upgrade
が使えない場合もあった。homebrewでインストールしたものだと無理だった(それはそう)
$ deno --version
deno 1.45.5 (release, x86_64-apple-darwin)
v8 12.7.224.13
typescript 5.5.2
$ deno upgrade
error: This deno was built without the "upgrade" feature. Please upgrade using the installation method originally used to install Deno.
This deno was built without the "upgrade" feature. Please upgrade using the installation method originally used to install Deno.
curlでインストールするような形にしておくと deno --upgrade
が効く。しかし雑な管理方法ではあるかもしれない。
jsr上で直接ファイルを見られる
github上で見るより楽かも?
ファイルサーバー
pythonでいうhttp.serverのような形でhtmlを手軽にローカルで確認したい。
$ deno run --allow-net --allow-read jsr:@std/http/file-server
Listening on:
- Local: http://localhost:8000
v1 -> v2 migration
jsrへの移行とv1 -> v2のmigrationを同時にやってしまったのでどちらの作業がどちらに関係しているのかあんまり切り分けられていない。
migration guiede
雰囲気を感じるやつ
deno lintのエラーを潰す
deno lint
で色々警告が出る。
| await Deno.write(
| ^^^^^^^^^^
= hint: Use `.write()` from the given class instance instead
| await Deno.fdatasync(file.rid);
| ^^^^^^^^^^^^^^
= hint: Use `.syncData()` from the given class instance instead
| Deno.close(file.rid);
| ^^^^^^^^^^
= hint: Use `.close()` from the given class instance instead
Found x problems
Checked 1 file
以下の記事がヘルプメッセージにお勧めされる
readLines()を治す
消えたらしい。そのものずばりなdiscussionがあって便利だった。
@std/streams
に慣れようみたいな感じっぽい。ところで何をimportするべきかとかがあまりわからない。
(out of context)
🐾 examplesに単純な行ごとにループして出力みたいなコード例があると嬉しかったが見つからなかった
技巧的なcat
抽象度が低過ぎるIO
SEP,SEP_PATTERNが見つからない
この辺はもしかしたらjsrの移動とnodeのpolyfillの利用がごっちゃになっているかもしれない。
名前が SEPARATOR
などに変わってる?
polyfillに移動していた(これの使い方が実はわかっていない)
jsrの方は名前が変わっていた
この辺りでdeno.lockの更新方法がわからなかった。
jsrの方のパッケージ名がわからない
deno jsr migration
みたいな感じで検索しても良い情報が見つからなかった。
欲しい情報は、https://deno.land/std@0.132.0/<path>
などから jsr:@std/<path>
への変換だった。基本的には機械的に置き換えれば良いがないものもある(それこそreadLines()などが良い例)
一応denoのv2のアナウンスの記事から
@std
の一覧に飛ぶことはできるのだけれどどこに何があるかはわからない
追記
しっかり書いてあった
the Deno team has created a utility to automate the most common steps
deno upgrade --canary
deno run -Ar jsr:@deno/x-to-jsr
importの記述方法がはっきりしていない
@std/io/<version>
とかの記述をどう書くか?があんまりわかっていない。
Deno v2では、Deno本体にパッケージマネージャーが組み込まれています。まずは、このパッケージマネージャーが想定している依存管理手法である deno.jsonでImport mapsを定義する 方法をDeno v2においては採用すると良いと思います。
deno.lockで固定されてるのでとりあえず書かなくても良いかなと思ったりしてしまった。
ここがぼんやりとしていた感じだった。
困った時のfresh
困った時のfresh。deno.jsonを覗いてみる。
基本的に知りたいのは @std/*
の管理方法だった。基本的にはsemverっぽい感じにしておいて更新させたいものは "@std/cli": "jsr:@std/cli@1",
などにしておくと良いようだ。
deno.lock
ファイル単位でimportをするべき?
テキトーに覗いてみる
ファイル単位でimportをするべき? import { parseArgs } from "@std/cli/parse-args";
フロントエンドでbundleするならtree shakingのためにファイル単位でimportしたほうが良い気がする?denoのパッケージも同様なんだろうか?
しかし @std.cli
の mod.ts で exportされている parseArgs()
でさえも
ドキュメントの冒頭では https://jsr.io/@std/cli@1.0.6 こうやって使えと parseArgs.ts 込みでimportしている
import { parseArgs } from "@std/cli/parse-args";
import { assertEquals } from "@std/assert";
// Same as running `deno run example.ts --foo --bar=baz ./quux.txt`
const args = parseArgs(["--foo", "--bar=baz", "./quux.txt"]);
assertEquals(args, { foo: true, bar: "baz", _: ["./quux.txt"] });
実際 parse_args.tsが存在する
標準ライブラリなどのimportのときには .ts
の末尾をつけないのかな?import map経由だからつけないのかな?
"jsr:" や "npm:" や "https://" などのprefixをつけない場合は物理的な相対パスを探しに行ってそう。こういうときには基本的にファイル名を直接記述しているみたい?
mod.tsって何者?という気持ちになった。
(おそらく複数のモジュールをまとめてimportしてそれを再exportしているのだろうけれど std/cli/mod.tsの存在意義がわからない)
ちなみにexamplesの方でもファイル単位でjsr:@std/cliparse-args
を指定してimportしている
nodeのpolyfillの使い方
そもそも Node API, Web API, Deno APIがあるらしい
その中のNode API
おそらく node:<path>
などで取り出せる?
しかしpath.SEPではなくpath.sepらしい。
$ deno repl
Deno 2.0.2
exit using ctrl+d, ctrl+c, or close()
> import {SEP} from "node:path"
undefined
> SEP
undefined
> SEP
undefined
> import {sep} from "node:path"
undefined
> sep
deno examples
🐾 examplesに単純な行ごとにループして出力みたいなコード例があると嬉しかったが見つからなかった
この話は例を追加してみても良いのかも?
jsrをCDNのようにして使う方法あるんだろうか?
(CDNのようにして使うのは流石に無理そう)
もしかしたらこの辺をいい感じにやって使える?
jsxをちょっとしたテンプレートエンジンとして使うことは可能なんだろうか?
わざわざテンプレートエンジンとして使う分にはreactとか不要な気がする。以下あたりを使ってみることにする。
- hono/jsx
- preact
💭 最終的には、github pagesあたりで配信するのが楽になってくれると嬉しい。
(deno deployの例は結構見つかるが便利なだろうか?)
hono/jsx
compilerOptionsを調整してあげて deno add で追加してあげると deno serve
で呼ぶことはできた
preact
こちらもcompilerOptionsを調整してあげたらいけた。deno run
で実行するには npm:preact-render-to-string
が必要?
雑に github copilotに聞いてみる
はい、JSXに関わる他のオプションもあります。以下にいくつかの例を示します。
{
"compilerOptions": {
"jsx": "react", // JSXコードをどのようにコンパイルするかを指定します。オプションは "react", "react-jsx", "react-jsxdev", "preserve", "react-native" などがあります。
"jsxFactory": "h", // JSXコードをJavaScriptに変換する際に使用される関数を指定します。
"jsxFragmentFactory": "Fragment", // JSXフラグメントをJavaScriptに変換する際に使用される関数を指定します。
"jsxImportSource": "preact" // JSXファクトリ関数のインポート元を指定します。主に "react-jsx" や "react-jsxdev" モードで使用されます。
}
}
オプションの詳細
-
jsx:
-
"react"
: React.createElementを使用してJSXをコンパイルします。 -
"react-jsx"
: 新しい自動インポートのJSX変換を使用します。 -
"react-jsxdev"
: 開発モード用のJSX変換を使用します。 -
"preserve"
: JSXをそのまま残します(変換しません)。 -
"react-native"
: React Native用にJSXをコンパイルします。 -
"precompile"
は、JSXコードを事前にコンパイルすることを指定します。これは、JSXをJavaScriptに変換する際に、特定のツールやライブラリを使用して事前にコンパイルすることを意味します。
-
-
jsxFactory:
- JSXコードをJavaScriptに変換する際に使用される関数を指定します。例えば、Preactを使用する場合は
h
を指定します。
- JSXコードをJavaScriptに変換する際に使用される関数を指定します。例えば、Preactを使用する場合は
-
jsxFragmentFactory:
- JSXフラグメントをJavaScriptに変換する際に使用される関数を指定します。例えば、Preactを使用する場合は
Fragment
を指定します。
- JSXフラグメントをJavaScriptに変換する際に使用される関数を指定します。例えば、Preactを使用する場合は
-
jsxImportSource:
- JSXファクトリ関数のインポート元を指定します。主に
"react-jsx"
や"react-jsxdev"
モードで使用されます。例えば、Preactを使用する場合はpreact
を指定します。
- JSXファクトリ関数のインポート元を指定します。主に
これらのオプションを適切に設定することで、JSXコードを好みの方法でコンパイルすることができます。
import {<Factory>, <FragmentFactory>} from "<ImportSource>"
みたいなイメージか。雑にいうと。
jsxのpreserveは変換しないものか。
precompileはdenoで追加されたもの?
実際のdenoのリファレンスはこの辺なんだろうか?
precompileのことも書かれていた
Deno ships with a new JSX transform that is optimized for server-side rendering. It can be up to 7-20x faster than the other JSX transform options. The difference is that the precompile transform analyses your JSX statically and stores precompiled HTML strings if possible. That way a lot of time creating JSX objects can be avoided.
💭tsxをjsに変換した結果を取得するにはどうすれば良いんだろう?
おそらく @deno/emit
viteで始める方法が載っている(同じページにhonoで始める方法も載っていた)
📝CMSはlumeなんだろうか?
deploy方法もあった
探せばテンプレートエンジンは見つかるが欲しいものはこれではない気がした。
このようなhtmlから始めてcssやjsなどの例を作れれば十分ではある