Deno v1.35.3
Deno v1.35.3がリリースされました。
deno lint
deno lintコマンドで--rulesと--rules-tagsの併用がサポートされました。
指定されたタグを持つルールの一覧を表示できます。
# `fresh`タグを持つルールを一覧表示する
$ deno lint --rules --rules-tags=fresh
deno lsp
deno lspが以下のケースでもdeno.jsonを検出するように改善されました。
deno.jsonを新しく作成したときdeno.jsonでシンタックスエラーが発生したとき
deno info
deno infoコマンドでImport Mapsで定義されたspecifierがサポートされました。
$ deno info --import-map=import_map.json preact
deno_std v0.196.0
deno_std v0.196.0がリリースされました。
std/http/server.tsでserveとserveTlsが非推奨化されました。 (破壊的変更)
Deno v1.35でDeno.serve()が安定化されているため、今後はそちらの使用が推奨されます。
remote_modulesのサポートについて
Deno本体でremote_modulesというディレクトリをサポートすることが検討されているようです。
feat: optional
remote_modulesdirectory (without lsp support) #19977
今のところ、以下のような振る舞いが想定されているようです。
deno.jsonでremoteModulesDir: trueを設定すると、remote_modulesというディレクトリにサードパーティモジュールが保存されるようになります。(実質的にremote_modulesディレクトリが$DENO_DIR/depsとして扱われます)remote_modulesディレクトリには、deno vendorコマンドによって作成されるvendorディレクトリと同様に、リーダブルなフォーマットで依存モジュールが保存されます。deno vendorやremote_modulesを使わない場合、Denoはリモートからダウンロードしたサードパーティモジュールをファイル名をハッシュ化した状態で$DENO_DIR/depsにキャッシュします。(そのため、サードパーティモジュールに関するデバッグが難しくなります。)
背景
このremote_modulesディレクトリの導入の目的として、deno vendorコマンドに関する以下の課題の解消などが背景としてあるようです。
deno vendorコマンドで作成されたvendorディレクトリをグローバルキャッシュ(DENO_DIR)として利用したい。deno vendorコマンドは独自に生成したImport Mapsの使用を前提としているため、ユーザが自身で作成したImport Mapsと併用することが難しいこと。(Import Mapsはプロセスごとに一つしか指定できないため)- 依存パッケージのバージョンを変更するたびに
deno vendorを実行する手間を軽減すること。
これらの課題を解消するために、remote_modulesという新しいディレクトリを導入することが検討されているようです。
詳しくは以下のissueで解説されています。