Zenn
Open48

denoの備忘録 2024/10~

Deno
JSR
podhmopodhmo

ちょっとしたdenoのスクリプトをv1からv2にmigrationしたりjsrを使うように書き換えるなどしてみてdenoをしてみたくなった。

podhmopodhmo

気になったことを書いていく

v1 -> v2 migration + jsr

https://zenn.dev/link/comments/19ad22000540f5

  • deno.lockの更新方法がわからなかった
  • denoのimportの書き方がわからなかった (with deno.json)
  • https://deno.land/std@<version>/* @std/*@<version> への変更方法がわからなかった
  • nodeのpolyfillの使い方がわからなかった (今もわかっていない)

💭 あと、github copilotがほとんど役に立たなかった
一番わかりづらかったのが @std/* のどこに何があるかという移行先の部分かも？

podhmopodhmo

jsrの検索が微妙な気がする。。

どうやらarchivedされたパッケージは検索の対象に載らないがそのページは存在するみたいな感じらしい。混乱した。

  • @std/flags がdeprecatedらしい
  • deprecatedなパッケージを一覧で表示して確認したい
  • jsrの検索結果の一覧に deprecated みたいなラベルがついていると嬉しい
  • @std/flags というクエリーで検索しても @std/flags が先頭に来ないし /flags だけのものとか絞れない？
podhmopodhmo

jsrをCDNのようにして使う方法あるんだろうか？

とりあえず、jsxをちょっとしたテンプレートエンジンとして使うことから始めて色々考えてみる。
サーバー側で動くコードはあまり欲しくない気がする。今のところはhtmlに変換されるような何かが欲しい。

https://zenn.dev/link/comments/6c0968b0dfdb5e

  • denoでtsxを実行はできる
  • hono/jsxを使ってみる
    • hono/jsxを文字列を返す方法で使う方法はわかっていない
  • preactを使ってみる
podhmopodhmo

denoの逆引き

denoのちょっとした作業を忘れてしまうのでメモ

podhmopodhmo

deno.lockの更新

以下のような形で更新する --lock は省略するとdeno.lockを更新する

$ deno cache --lock deno.lock <file>
podhmopodhmo

lint

$ deno lint <file>

型チェックは (deno run の際には行われない)

$ deno check <file>
podhmopodhmo

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が効く。しかし雑な管理方法ではあるかもしれない。

https://docs.deno.com/runtime/getting_started/installation/

podhmopodhmo

ファイルサーバー

pythonでいうhttp.serverのような形でhtmlを手軽にローカルで確認したい。

$ deno run --allow-net --allow-read jsr:@std/http/file-server
Listening on:
- Local: http://localhost:8000

https://jsr.io/@std/http

podhmopodhmo

v1 -> v2 migration

jsrへの移行とv1 -> v2のmigrationを同時にやってしまったのでどちらの作業がどちらに関係しているのかあんまり切り分けられていない。

migration guiede

https://docs.deno.com/runtime/reference/migration_guide/

雰囲気を感じるやつ

https://zenn.dev/uki00a/articles/deno-v2-what-has-changed-from-v1

podhmopodhmo

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

以下の記事がヘルプメッセージにお勧めされる

https://lint.deno.land/rules/no-deprecated-deno-api

podhmopodhmo

readLines()を治す

消えたらしい。そのものずばりなdiscussionがあって便利だった。

https://github.com/denoland/deno/discussions/23495

@std/streams に慣れようみたいな感じっぽい。ところで何をimportするべきかとかがあまりわからない。

https://jsr.io/@std/streams@1.0.7

(out of context)

🐾 examplesに単純な行ごとにループして出力みたいなコード例があると嬉しかったが見つからなかった

技巧的なcat

https://docs.deno.com/examples/unix-cat/

抽象度が低過ぎるIO

https://docs.deno.com/examples/reading-files/

podhmopodhmo

この辺りでdeno.lockの更新方法がわからなかった。

podhmopodhmo

jsrの方のパッケージ名がわからない

deno jsr migration みたいな感じで検索しても良い情報が見つからなかった。

欲しい情報は、https://deno.land/std@0.132.0/<path> などから jsr:@std/<path> への変換だった。基本的には機械的に置き換えれば良いがないものもある（それこそreadLines()などが良い例）

一応denoのv2のアナウンスの記事から

https://deno.com/blog/v2.0#the-standard-library-is-now-stable

@stdの一覧に飛ぶことはできるのだけれどどこに何があるかはわからない

https://jsr.io/@std

追記

しっかり書いてあった
https://jsr.io/docs/migrate-x-to-jsr#try-using-the-x-to-jsr-migration-tool

the Deno team has created a utility to automate the most common steps

deno upgrade --canary
deno run -Ar jsr:@deno/x-to-jsr
podhmopodhmo

importの記述方法がはっきりしていない

@std/io/<version> とかの記述をどう書くか？があんまりわかっていない。

podhmopodhmo

https://zenn.dev/uki00a/articles/deno-v2-what-has-changed-from-v1#deno-v2における依存管理

Deno v2では、Deno本体にパッケージマネージャーが組み込まれています。まずは、このパッケージマネージャーが想定している依存管理手法である deno.jsonでImport mapsを定義する 方法をDeno v2においては採用すると良いと思います。

deno.lockで固定されてるのでとりあえず書かなくても良いかなと思ったりしてしまった。
ここがぼんやりとしていた感じだった。

podhmopodhmo

困った時のfresh

困った時のfresh。deno.jsonを覗いてみる。

基本的に知りたいのは @std/* の管理方法だった。基本的にはsemverっぽい感じにしておいて更新させたいものは "@std/cli": "jsr:@std/cli@1", などにしておくと良いようだ。

https://github.com/denoland/fresh/blob/bf45e8652a3a2a792da667b6fdaad459bd4953ec/deno.json#L35-L76

deno.lock

https://github.com/denoland/fresh/blob/bf45e8652a3a2a792da667b6fdaad459bd4953ec/deno.lock#L14

https://github.com/denoland/fresh/blob/bf45e8652a3a2a792da667b6fdaad459bd4953ec/deno.lock#L113-L115

podhmopodhmo

フロントエンドでbundleするならtree shakingのためにファイル単位でimportしたほうが良い気がする？denoのパッケージも同様なんだろうか？

しかし @std.cli の mod.ts で exportされている parseArgs() でさえも

https://jsr.io/@std/cli/1.0.6/mod.ts

ドキュメントの冒頭では 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が存在する

podhmopodhmo

標準ライブラリなどのimportのときには .ts の末尾をつけないのかな？import map経由だからつけないのかな？

"jsr:" や "npm:" や "https://" などのprefixをつけない場合は物理的な相対パスを探しに行ってそう。こういうときには基本的にファイル名を直接記述しているみたい？

podhmopodhmo

mod.tsって何者？という気持ちになった。
(おそらく複数のモジュールをまとめてimportしてそれを再exportしているのだろうけれど std/cli/mod.tsの存在意義がわからない)

podhmopodhmo

nodeのpolyfillの使い方

そもそも Node API, Web API, Deno APIがあるらしい

その中のNode API

https://docs.deno.com/api/node/

おそらく node:<path> などで取り出せる？

https://docs.deno.com/api/node/path/~/default.PlatformPath#property_sep

しかし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
podhmopodhmo

jsrをCDNのようにして使う方法あるんだろうか？

(CDNのようにして使うのは流石に無理そう)

もしかしたらこの辺をいい感じにやって使える？

https://jsr.io/docs/api

jsxをちょっとしたテンプレートエンジンとして使うことは可能なんだろうか？

わざわざテンプレートエンジンとして使う分にはreactとか不要な気がする。以下あたりを使ってみることにする。

  • hono/jsx
  • preact

💭 最終的には、github pagesあたりで配信するのが楽になってくれると嬉しい。
(deno deployの例は結構見つかるが便利なだろうか？)

podhmopodhmo

雑に 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" モードで使用されます。
  }
}

オプションの詳細

  1. jsx:

    • "react": React.createElementを使用してJSXをコンパイルします。
    • "react-jsx": 新しい自動インポートのJSX変換を使用します。
    • "react-jsxdev": 開発モード用のJSX変換を使用します。
    • "preserve": JSXをそのまま残します（変換しません）。
    • "react-native": React Native用にJSXをコンパイルします。
    • "precompile" は、JSXコードを事前にコンパイルすることを指定します。これは、JSXをJavaScriptに変換する際に、特定のツールやライブラリを使用して事前にコンパイルすることを意味します。

  2. jsxFactory:

    • JSXコードをJavaScriptに変換する際に使用される関数を指定します。例えば、Preactを使用する場合は h を指定します。

  3. jsxFragmentFactory:

    • JSXフラグメントをJavaScriptに変換する際に使用される関数を指定します。例えば、Preactを使用する場合は Fragment を指定します。

  4. jsxImportSource:

    • JSXファクトリ関数のインポート元を指定します。主に "react-jsx" や "react-jsxdev" モードで使用されます。例えば、Preactを使用する場合は preact を指定します。

これらのオプションを適切に設定することで、JSXコードを好みの方法でコンパイルすることができます。

podhmopodhmo

import {<Factory>, <FragmentFactory>} from "<ImportSource>" みたいなイメージか。雑にいうと。

jsxのpreserveは変換しないものか。
precompileはdenoで追加されたもの？

podhmopodhmo

実際のdenoのリファレンスはこの辺なんだろうか？

https://docs.deno.com/runtime/reference/jsx/#jsx-automatic-runtime-(recommended)

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.