JavaScript Registryの今後
さて、前回は tink と yarn v2 における CLI 戦略の話でした。次は JavaScript Registry についてです。
ちなみにこの内容が今回 JSConf.EU 2019 で一番盛り上がったトピックです。
JavaScript Registry とは
JavaScript Package をバックエンドで管理しているサービスです。 npm が管理しているものがいちばん有名です。他にも GitHub が管理する Registry が公開される予定です。
The economics of Package Management
slide:
video:
「Package Managementの経済」というタイトルです。 聴講者からすると、何話すのか不明でしたが、惹きつけられるものがありました。終わったあとはこれぞ「Tech Talk」という発表でした。是非時間があれば全ての動画を見てみるとよいかと思います。
筆者はここで語られていた内容を基に entropic について紹介し、最後にこの Registry で何がやりたいのかを話します。
Successful JavaScript Registry is hard
npm のパッケージは大きくなりました。いまや100万パッケージを超えるほどです。
一方で、 npm inc は営利を目的にした団体です。これだけ多くのpackageがあると管理コストも高くなります。 npm inc の経営状況がどうこうは色々な話がありますが、実際に公開されてる情報があるわけではないので、特に何かをここで言うつもりはありません。
ただ、 Registry の管理をビジネス的に成功させるのは難しい、ということです。
npm inc の Registry は基本的に無料で使えます。無料で使う場合、すべてのライブラリは public として公開されます。 private や enterprise でグループを作るなど、特別なアクセスコントロールをするライブラリを作る時には有料版を契約するというビジネスモデルです。
npm の public のOSSのライブラリが増えれば増えるほど、 運用コストがかかります。その運用コストを private ライブラリや enterprise Registry の売上で賄います。小さいサイズの Registry は運用コストがあっても寄付金で調整するのはそこまで難しくありませんが、大きなサイズになってくると寄付金だけで運用するのはやはり難しくなってきます。これをなんとかするために、 npm inc は Venture Capital からも出資を受けています。
Venture Capital の意向が変わったら方針も変わりますし、結果としてコミュニティにとって最適な運営が行われるとは限らないわけです。
この話は npm に限りません。 RubyGems でも Perl CPAN でも運営コストの話はあります。ただ、 npm が管理している package の数は膨大で、他の Registry よりも遥かに難しい状況になっています。
じゃあどうするか
Registry を分散して管理できるようにしていこう、というのがこの発表の内容でした。
一つの団体が一つの Registry を集中管理している状況をやめて、分散管理するシステムを作れるようにして、みんなでちょっとずつ運用コストを分散できるようにしていこうという話です。
これの構想の基になっているのが、JSConf EU のトークの中にある、 Entropic です。
Entropic: a federated package registry for anything but mostly JavaScript
Entropic は 新しい Package Registry です。 npm や yarn ではなく、新しい CLI である ds も持っています。
entropic/cli at master · entropic-dev/entropic · GitHub
ds は entropic の registry につながることはもちろん、 npm の Registry も read only でつながります。read onlyなので、publishはできませんが、 npm に登録されている package もダウンロードできるようになります。
ちなみにまだ experimental なので変更される可能性も大いにあります。
どうやってpackageを指定するか
ds は domain , namespace , package name すべてを指定して、ダウンロードします。
namespace@example.com/pkg-name
こういう指定方法で Package.toml に記述があると、 package がダウンロードされます。例えば、 ds 本体をdownload したい場合は chris@entropic.dev/ds と指定します。
ドメインを指定するので、別サーバで別DomainのRegistryであっても package の指定ができます。 (逆に言うと Domain を失効したらダウンロードができなくなるということですね。)
もしも npm に接続したい場合は、 legacy@entropic.dev/<pkgname> で legacy ネームスペースを指定し、 entropic.dev ドメインで pkgname にアクセス先の package を指定すれば npm からダウンロードできるようになります。
（おそらく entropic.dev の legacy ネームスペースは npm への alias になってるんでしょう）
Docker の実行環境さえあれば、 Registry を構築することは簡単にできます。
https://github.com/entropic-dev/entropic/tree/master/services/registry#running-your-own-registry
Entropic は自分たちの手元で起動し、対象となる package ダウンロード先のhost を指定してダウンロードします。その host に自分たちが使う package のキャッシュが構築され、初回は Package.toml に記述したドメインのホストからダウンロードされますが、 2回目以降は自ホストのキャッシュを利用します。
アクセス権
すべての package は public となり、誰からでも install し、誰からでも閲覧できる形になります。 private のアクセスをしたい場合は GitHub の Registry を併用する形になると思います。
また、一緒にライブラリを編集したい場合は publish 権限を他のユーザーに付与することも可能です。
https://github.com/entropic-dev/entropic#overview
Entropic のゴール
ここからまた少しエモい話ですが、 Entropic は全ての JavaScript package を Entropic 上で扱おうとしてはいません。つまり、これで npm を倒すという話ではありません。
じゃあ何がゴールになるかというと、
1. 「何もしないでnpmが倒れるか、有効策が出るまで待つ」以外の選択肢を用意したい
2. 「分散管理するRegistryの運用知見」を広めたい
3. 「中央集権から分散管理」に振り子を戻したい
という話です。 npm を倒すのではなく、 npm 以外の選択肢を用意し、その運用知見を全体に広げ、分散管理していくという話は非常に分かる話で、特別な専門知識がなくても管理できるように 共通理解をみんなで深めていこうという深い話でした。
まとめ
1年前、 JSConf EU 2018 で、 Ryan Dahl は module や package について、深く色々な反省をしていました。
yosuke-furukawa.hatenablog.com
その中でもあったのが、「Nodeのモジュールの管理運営自体を private controlled にしてしまったこと」があげられていました。
1年後、 JSConf EU 2019 は節目の年です。コミュニティを代表するようなカンファレンスで Entropic のような発表があったことは一つの epoch making な話だったと思います。来年は一旦 JSConf EUはありませんが、数年後にどうなっているか確認する、というバトンを渡されたような思いでした。
今年 JSConf JP をやる予定ですが、この辺の話もできれば幸いです。
