DenoユーザーはHTTPSインポートのみを使うべき

こちらの記事を見かけました: 『Deno ユーザーは https import と jsr import のどちらを使うべきか?』。JSRインポートを使うべき理由として以下の二つが挙げられています。

1. 依存の dedupe (重複排除) が出来るのは jsr import だけなので
2. deno.land/x は今後レジストリとしては開発されなくなる

2.はただ1個のレジストリーが腐っていくというだけの話なのであまり重要ではありません^[1]。1.が今回の問題です。筆者としては、人類のソフトウェアビルドの技術を少しでも進展させるためにはHTTPSインポートを使うようにしていったほうが良いと考えています。

すでに筆者が別記事（『SemVerキャンセル界隈』）で書いたように、SemVerに基づく重複除去システムには重大な欠陥があります。それは人間同士の「自分や相手がバージョニングに失敗しない」という信頼の上に成り立っているという点です。このような脆弱な基礎の上に自動で何かをするようなシステムを組んではいけません。この前提はあまりに見過ごされています。

ほとんどの場合、「重複除去」という言葉で開発者がやりたいことというのは、不要なコードの除去です。本当の意味で重複除去が必要なケースはほぼなく、あっても避けて通る方法があるはずです^[2]。不要なコードの除去のためには、パッケージマネージャーないしはコンパイラー側でUnisonのような構文木単位でのコンテントアドレッシングを実装するべきです。その意味で、ユーザー側としてもHTTPSインポートを使っていったほうが長期的に見て良いエコシステムを醸成するでしょう。

ここまで読んでいただいた方ならお分かりかと思いますが、筆者が本当に言いたいのは、「DenoユーザーはHTTPSインポートのみを使うべき」というよりも「世界中のプログラミング言語はパッケージ単位での重複除去をやめるべき」、ということです。とはいえ、その中でもDenoのHTTPSインポートは比較的その理想に近いところにいるので、言及我慢失敗しました。

DenoチームがDenoとJSRを今の形に推し進めてしまったのは、プログラミングの世界における一つの間違いだと思います^[3]。もちろん、そんな間違いは世界中で行われていますし^[4]、引き返すこともできます^[5]。ただ、上記のような問題意識はすべての開発者が持っておくべきだと筆者は考えます。

---

脚注

1. そもそもHTTPSインポートを使っていればレジストリーなど用意する必要はなくraw.githubusercontent.comを参照すれば済む話です。force pushなどで勝手に破壊されないようフォークしておく必要はありますが。

2. 単一のバージョンのみがプロジェクトに存在することを前提とするようなプログラミングは避けなければなりません。instanceofを使わないとか。

3. このような現状で短期的・局所的に見ればJSRインポートを使ったほうが良いという考えは理解できます。

4. 現代新たに作られるプログラミング言語やパッケージマネージャーで「SemVerに基づいてパッケージ単位で重複除去」というアイデアを採用しないことがあるでしょうか？ おそらくみんな「みんなやっているから」という理由で説明なく採用するでしょう。本当はそこには、「すべての開発者のバージョニング能力を信頼するかどうか」という問題が隠れていて、諸々のトレードオフを考慮し慎重に判断する必要があることなのに。

5. JSRではパッケージごとに対応ランタイムを設定することができるので、DenoやWebブラウザーにしか対応しないパッケージにはHTTPSインポートを開放してもよいはずです。