2023/07/24〜2023/07/30の最新情報
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_modules directory (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という新しいディレクトリを導入することが検討されているようです。...