Denoの公式ブログで、Deno v1.31でpackage.jsonサポートが実装された背景に関する解説が公開されました。
このページでは、こちらの記事を参考に内容を要約していきます。
背景について
Denoにnpmパッケージやpackage.jsonのサポートが導入されたのは、以下における各課題の解決や既存のNode.jsプロジェクトを直接Denoで動作させられるようにすることが目的のようです。
依存関係の重複問題
例えば、アプリケーションが依存しているモジュールAとモジュールBがそれぞれ以下のモジュールに依存していたとします。
もし仮にstd/async/deferred.tsの内容が0.180.0と0.181.0で同一であったとしても、URL importの性質上、これらの両方のバージョンがモジュールグラフの中に含まれてしまうという課題があります。
既存のリモートモジュール管理における課題
Denoではdeps.tsやImport mapsなどによってリモートモジュールを管理する方法がありますが、これらには以下のような課題があります。
- deps.ts
package.jsonなどと比較すると冗長になってしまいがち- ただし、Module DeclarationsやModule Source Importsなどの仕組みにより、ある程度改善の余地はある模様です
- Import Maps
- 合成可能ではないという欠点があること (プロセスにつき1つしかImport Mapsを使用できない)
CDNに関する課題
Denoではesm.shなどを活用することで一部のnpmパッケージを利用することはできるものの、性質上、どうしてもサポートができないnpmパッケージがでてきてしまうという課題があります。
対象のnpmパッケージがtarアーカイブ中に特定のテキストファイルなどが含まれていることを前提としている場合などは、動作させることが困難になってしまいます。
例としては、bullmqなどのように、パッケージ内でテキスト形式でLuaスクリプトを管理しているパッケージなども存在し、こういったパッケージをサポートすることが難しくなります。
今後について
npmパッケージやpackage.jsonなどのサポートがDenoに入ったとしても、URL importなどの既存のDenoの仕組みは将来に渡ってもサポートが予定されているということが説明されています。
また、新しいメジャーバージョン (Deno v2)を数カ月後にリリースすることを目標に開発が進められているようです。
Deno v2では、上記の依存関係の重複問題などの解消を目的に、deno:URLのサポートなどが検討されているようです。
import $ from "deno:dax@24.0/mod.ts";
await $`echo foobar`;
Deno本体でsemverの解決をできるようにすることで、依存関係の重複問題などを緩和することなどが計画されているようです。