00:10
はい、みなさんこんにちは。kkeethことクワハラです。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネル。この番組では、ウェブ業界やエンジニアリング、いろんな技術についての情報を、
雑談形式で発信していきたいと思います。
で、今日ですけど、何喋るかっていうのを悩んだんですけど、
ちょっと前にですね、読んだ記事に面白いのがあって、タイトルにあります通り、
npmというエコシステムを管理するパッケージがあるじゃないですか。
あそこにですね、全ライブラリに依存をするパッケージを作って公開した人がいるらしくて、
一度は思ったことありますよ。npmに公開されまくったやつの依存関係をどこまで増やしても動くのかとか、
どこまで増やせるのかみたいな思ったことはあるんですけど、やったことはもちろんなくてですね。
ただそれをやった人がいるらしいです。いやもう笑いましたね。笑ったけど中の人は笑えない話だと思うんですけど。
それのわざわざしかも記事が出てました。そういうの作ってあるライブラリがあって、
この人が苦労したよみたいな話の記事が出てて、それを読んだんですね。めちゃめちゃ面白かったです。
面白いけど怖いなとも思いましたね。一応記事のタイトルは、
When everything becomes too much, the npm package chaos of 2024ですね。
その名の通り、everythingっていうライブラリーが、名前の通り、全依存関係に依存するんですね。
公開されているnpmパッケージ全てに依存をしていて、何百万もの相互依存関係を作り出したというので、いやー感動しましたね。
思ってもどうやって作るみたいなところもあって、これはこれで一つの技術力と思いますけど。
npm上のユーザーが、パトリック・ジェイスというユーザー名でやられている方で、その方が作ったそうです。
他のハンドルネームではgdi2290っていう名前らしいですけど、作られましたと。
記事のタイトルのサブタイトルに解き放たれたカオスって書いてあって、めっちゃ笑いました。そりゃそうやろって感じですけどね。
everythingパッケージはですね、3000以上のサブパッケージに分けられていて、それをインストールした人に、いわゆるドスを引き起こしたらしいですね。
ストレージ容量の枯渇やシステムリソースの枯渇の話が生まれたと。
まあそれはそうでしょうね、本当に。
npmって依存に依存が重なっているので、それを全部インストールしたら多分死ぬんじゃないかっていう感じがしますね。
マシンパワーが低い端末でやったら、そりゃ死んだろみたいなところはあります。
で、それだけならまだ良かったんですけど、作戦者はですね、everything.npm.lolみたいなドメインがあるんですけど、
自分たちがやったカオスを紹介したらしいですね。
で、自分たちのいたずらを次のレベルに引き上げてしまったというので、
まあいろんなミームまで盛り込んで、この状況にユーモアを一応加えてみたらしいです。
いやー、なかなかね、すごいですね。
03:00
で、一応ですね、パッケージ自体のライブラリはもちろん公開されているので、
ソースコードを見ていくと、パッケージ.jsonファイルが公開されていて、それも記事内に紹介されていました。
で、それを見るとですね、依存関係どんな風に書かれているかというと、
dependencies5個しかないんですね。
で、それは、ateverything-registryっていう、オーガニゼーションに分けているのかな?
っていうところの中に、chunk01234で分けられて、それぞれがさらに依存をしていくような感じの構成になっています。
で、versionは0.1.0で、そのまま何も更新されてないっぽいですね。
いろいろそういう分け方をしているっぽいんですけど。
で、NPMの歴史上、今回みたいな演出っていうのは、実は初めてではないらしいですね。
他にも今まであったらしくて、いろんな方が作ったものが一応あります。
ただまあ、今までの試みも基本的には削除されていたりはしたんですけど、
まあ、その33,000以上のサブパッケージとともに、別のスコープで登場したりもしていると。
で、要はNPMパッケージのモグラ叩きしてる感覚だよみたいなのが書かれてて、そうだよねって感じです。
叩いても叩いても、まあ同じように全ライブラリに依存するものを作る人たちは出てくるというので。
これだけならばぶっちゃけると、netmemeとかyumaとかジョークなんですよね。
ジョークライブラリなんで、それはそれで、まあまあ、使った人がやられたなっていう感じで、笑いで済ませれば良いんですけど、
問題はそれだけで終わらなかったんですね。
どういう問題を引き起こしたかというとですね、削除できない問題に確かにぶち当たったはずなんですよ。
で、そのeverythingってさっき言うとパッケージですけど、
こちらその5つのサブパッケージと何千もの依存関係を持って、まあそれらが相互に依存し合うカオスな状況を作ったんですね。
で、これらはですね、作者がパッケージをunpublishする能力を本質的に封じ込めたっていうことを意味してるんですね。
本体だけ閉じればunpublishにしてしまえば良いと思ったんですけど、そうはならなかったと。
で、なんでかっていうと2016年に、僕ら知らなかったんですけど悪名高いleftpadっていう事件があったらしいです。
left-padっていう事件がnpmの世界にあったらしいですね。
で、これのせいでnpmっていうのは方針を転換したらしいです。
で、その人気のあるそのパッケージleftpadっていうのが削除されてしまって、
開発者の世界の多くで開発が停止したみたいな事件があったらしいですね。
これを受けてnpmは公開解除に関するルールっていうのを強化して、
特に他のパッケージによって使用されているパッケージの公開解除っていうのを禁止にしたらしいです。
つまり本体を止めたとしても依存しているものが公開されている場合は、
本体を公開停止っていうのをできなくしたんですよね。
なのでeverythingは削除ができなくなってしまったっていうのが今回の状況ですと。
で、この状況が方針転換がeverythingを作ったパトリック・ジェイスっていうのを罠にはめてしまいましたよというので、
自分のいたずらの影響に気付いて彼はすべてのパッケージを削除しようとしたんですけど、できなくなったんですね。
つまりeverythingがすべてのライブラリーに依存しているので、
他のライブラリーの人たちがこれもういいやって削除しようとか、
06:00
誤って作ったので削除しようとしたとしても、
everythingが全部に依存してしまっているので削除できないんですよね。
っていう状況を作り上げてしまってですね。
これがもう本当にひどいなってことですね。
で、もちろん本人はNPMのサポートチームに助けを求めたんですけど、
この業界的にダメージを負わせたってのは結構デカいよねっていうので、
一応彼はですねGitHubの移習でちゃんと謝罪をしてます。
で、彼自身ではやれることは全部やったんですけど、
あとはもうNPMとかGitHubとかその辺の人たちに頼るしかない。
あとはもう任せたっていうのでちょっと投げやり感もあるんですけど、
一応彼なりには行動を取ったということを表明しつつ、
ちゃんと謝罪はしてます。
これは一連の騒動っていうのは単なるデジタルな悪戯だけじゃなくて、
やっぱりNPMのエコシステム内のパッケージ管理っていうものですね。
それに関する継続的な課題っていうのも一つ見えたよねって感じです。
もともと見えてたんですけど、
それが浮き彫りになったって言ってもいいかもしれないですね。
開発者にとってその依存関係のいわゆる連鎖的な影響があるんですよね、
NPMは特に。
あとパッケージの作成、もちろんメンテナンスもそうですね。
それをどう使うかみたいな、
消費にも気を配ることの重要性っていうのが思い起こされます。
誰かがこんな感じで罠とかジョーク的なものを仕込んでしまって、
知らず知らずのうちに影響を受ける可能性があるよねっていうのはあるので、
でもそれは今のエコシステムに依存するような開発の流れっていうところから
逃れることはできないので、
ちゃんと僕らはその辺を意識して使わなきゃいけないよねっていう、
ある意味の恐怖というか、
危機感っていうのを思い起こさせてくれたっていうのはもちろんありますし、
これは果たしてでもそういう環境はどうなのっていう、
ずっとみんなが黙認していた問題をもう一回浮き彫りにするっていう、
そういう意味もあるよねって話でした。
はい、とはいえ、
じゃあ全部自分たちが作っていく、
フルカスタムで作るかってそんなことはもちろんないし、
便利なものをパッケージ化してNPMとかに公開するっていう、
このOSSの流れはとても素晴らしいと思いますので、
これを止めることはもちろんできないと思います。
じゃあでもそういうジョークを作り出すような人たちがいるっていうのも、
これを止めることもできないですね。
これもある種、一つのクリエイティブっちゃクリエイティブですから。
良くないですけどね、もちろん。
なので、僕らエンジニアはちゃんとそういうことを意識しながら使わなきゃいけないですし、
自分たちがもし生み出したものの、
更新するならしっかり更新しましょうとか、
もう使わないなら使わないで、
ちゃんとそれも表明しましょうとか、
いろんな何に依存してますよっていうのを、
ちゃんと表明しなきゃいけないっていうところですね。
はい、などなど。
いろんなそのオープンソフトウェアにおける自由とか、
あと責任の話ですね。
みたいなそのバランスをどう取るかっていうのを、
僕らは結構もう今、
脳死で使っている時も正直にあります。
で、新しくなんか知らなかったライブラリを今回使おうとか、
なんかフレームワーク使いましょうって言ったら、
一旦ギター部見たりとか、
公開されている公式サイトのドキュメント読んだりとか、
他のいろんなユーザーたちの声を聞きながら、
あとはイシューですよね。
どんなイシューがあるとか、
バグの発生率とかっていうのを見て、
使う使わないっていろいろ判断していくんですけど、
とはいえそれは、
ビジネス観点とかセキュアな話も全然出てくると思うんですけど、
忘れたこういう危機感っていうのを、
一回ちゃんと思い起こしながら使っていくっていうのが、
エンジニアの技術戦と意思決定をする話だよな、
09:02
っていうのは思いました、僕も。
というので、そのブログとして、
これはすごくいい記事だったなと思います。
が、改めて怖いなとは思いましたね。
Everything。
NPMにも公開されているものが全部素晴らしいってわけではないですし、
誰でもローカル上でコマンド一発でアップロードできてしまうんですよね。
審査とかチェック、何も入らないまま公開されているので、
Everythingがそれの全部に依存するので、
まあ怖いなっていうのはもちろんあって、
なので、Everythingをローカルにインストールすることは普通しないと思うんですけど、
した人もいるっていうのがそれはアホやなって感じはします。
ちょっと考えれば怖さはわかると思うんですけど、
まあでもそれをやってDOSにかかってしまった人もいるっていうので、
まあまあアホやなと思いながらも、
エンジニアらしいなっていう感じはあります。
はい、というので、
僕らの技術選定はしっかり意識をして、
気をつけながらチェックしつつ使っていきましょう。
使わないものはちゃんと使わないと意思決定をしましょうというので、
さらに意思決定をするのであれば、
使わない理由とかもちゃんとですね、
一緒に開発するメンバーとかチームメンバーへの共有もしていくっていうのはすごく大事かなと思ったりしました。
はい、というところで、
今日は短いですけどね、
まあそういう面白い記事を見つけて紹介してみたくなったって感じですね。
NPMの依存関係のカオスは多分もう治らないというか、
このままずっと走り続けるだろうなって感じはありますね。
まあそれに対するいろんなアプローチだったりアンチテーゼっていうのも生まれてはいますけど、
主流としてはずっとNPMだろうなっていう感じはします。
僕らその特にフロントエンドとかノードJS界隈で仕事をしているメンバーとしては、
このまま流れに乗るんじゃないかなと思ったりしますね。
もちろんDINOとかBANかっていうのも生まれたりして、
いろんなものが解決している可能性ももちろんあるし、
ちょっと僕まだDINOもBANも触ったことなくて、
DINOは触らない気がします。
今年チャレンジする技術としてはBANは触ろうと思っているので、
それがどういうものなのかって見てみたいとはありますけど、
まあでもエコシステムに依存するってところは特に変わりはないと思いますので、
まあなんか解決策が生まれてくれればいいと思いつつ、
まあまだまだ主流に乗っかろうかなと。
で、何かあったらみんなで一緒に死ぬ気がするので。
いうて、使う技術の選定はしっかりね。
技術者のプロとしてやっていきたいなと思ったりしてます。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の収録でお会いしましょう。
バイバイ。