core.jsの作者が大変らしいけど、js業界も気軽に npm i し過ぎ
忘れちゃいけない。オープンソースの公開は、好意であり、矜持である。断じて義務ではない。
2023 core.js
正直、この流れ何回目だ？と思ってる。
ダウンロード数を確認できるらしい。グラフを見ると、凄まじい量の増加だ。
2019
この件は、2019年時点ですでに一旦根を上げてる。これが原作者からのコメントらしい。
babel/polyfillとやらでも、import "core-js/stable" は deprecated だよと言ってるので、何らかの対応をしたのだろう。
小生としては、この件については、githubをpublic archive にして放棄しちゃえば？と思ってる。 必要なら必要な人がforkして修正すればいい。それがgithubの「存在意義」だろう。
2022.1 color.js faker.js
ちょっと前にも似て非なる事件があった。
正直、これらの発言および行為に文句をいう連中がいるのが判らない。 オープンソースを何だと思ってるのだろう。
2019 left-pad
なかなかややこしい事情なので詳しくはリンク先を読んでいただくとして。
問題の本質は、たったの38行のライブラリを524ものパッケージから参照されてることだ。これのお陰で事態が深刻化している。
ちなみに、機能自体は現状では jsの標準関数でできるらしい。
紹介した3例はどっちもMITライセンス
前述、いずれもMITライセンスである。MITライセンスとは何か？手っ取り早く日本語 wikipediaを引用させていただく。
このソフトウェアを誰でも無償で無制限に扱って良い。ただし、著作権表示および本許諾表示をソフトウェアのすべての複製または重要な部分に記載しなければならない。 作者または著作権者は、ソフトウェアに関してなんら責任を負わない。
「作者または、ソフトウェアに関してなんら責任を負わない」と断言してる。 アナタはそれを承知で使ってるのではないのか？
js業界は気軽に npm install しすぎ
小生、基本的にはサーバサイドの人だった。いや厳密にはperlで5年ぐらい。PHPで15年ぐらいやってる。泣きそうだった。いやその話はおいておこう。
故に、nodejs業界のことは知らない。そこに取引先から救援要請があり、この案件ですと見せられたソース。 node_modules の中を見た時に血の気が引いたことがある。得体の知れない大量のパッケージがあるからだ。
js業界では「環境が汚れる」と平気で口走る人がいるが、話の順番が違う。あまりにも気軽に require しすぎるのがまず問題なのだ。
フロントエンジニアを自認する諸兄には、まずはご自分のプロジェクトの node_modules を精査してみることをお勧めする。例えば次のようなことが発生してる。
なんの話か？ スレ主が貼ってるスクリーンショットを見ればよく見て欲しいのだが、わかりやすい例で言えば、「例えば”bytes@3.0.0"のコピーがいくつも入っています。なんとかなりませんでしょうか」だ。 気づいてない人は非常に多いと思われる。次の記事は「気づいた方の人」だが3桁イイねしかない。
考えてもみてほしい。気軽に npm i したパッケージにも、packages.jsonがあり、dependencies が存在するかもしれないのだ。それを 0 dependencie のパッケージに到達するまで繰り返す。
問題がもう一つ、package.jsonにはバージョン固定の機能がある。 依存の途中で、同じパッケージの別バージョンを要求されたらどうすればいいのか？ 別コピーを作るしかない。
結果的に、node_modules の深淵が誕生することになる。
これで良いのか？良い訳がない。 nodejsの作者も後悔している。その反省からdenoを作ったが定着はまだまだ遠いようだ。
例えば express-js
node_modules の中身の具体例があったほうが良いだろう。 例えばググると 約 17,300,000 件引っかかる。人気の express-js。( core.js とも直接関係ないのだが、今思いつくのがこれぐらいしかないのでご容赦願いたい）
npm のサイトによれば Dependencies (31) とある。
問題はここからだ。このなかのひとつ accepts は Dependencies (2) とある。
31+2になったのがお分かりいただけるだろうか。以降これらを繰り返していけば最終的に一体幾つになるのか？
とはいえ非常に手間なので、素晴らしいWEBサービスがあるから使わせてもらおう。
使ってみよう。依存関係をツリーで確認 （ webpackの場合 ）
他にも類似したサービスはあると思われるが、小生が見つけたのは次の2つのサイトである。
ちなみに何故検索したかというと、その前に自分で作ろうとしたからだ。理由は前述のとおり。 node_modules もうちょっとなんとかしたいと思ったため。
初稿では前章からそのままexpressを使ってたが、インパクトが足りないと思われるので、ここから先はjs業界でかなりのひとがお世話になってると思われる webpackに差し替えることにした。
npmgraph
入力したパッケージ名に対してツリーを構築し尽くしてから完成したものを描画するタイプ。
例えばこんな感じになる。依存が深くなるごとに横に、同依存は縦に伸びていくが、大抵の場合はメチャクチャ縦長いグラフになると思われる。
色付け機能でなかなか面白いものが増えてる。 Maintainer Count==メンテナの人数。掲題のcore.jsみたいなことになる可能性があるか否か？をある程度予想できる。
残念ながら真っ赤、つまり一人班が非常に多いことがわかるだろう。
メンテナが居なくなったら引き継げばそれで済む話だ。 お世話になってるのだろう？何度も言ってるが、ほとんどMITライセンスでありgithubにソースがある。
Visualization of npm dependencies
パッケージ名の入力の淡白な画面から始まる。 一部入力で補完が掛かる。選択すればスター型のグラフで、依存性を確認できる。
こっちはツリーを作りながら依存探索するので、まだあるの？感が引き立つかも知れない。
こっちはライセンス統計もある。
あとスター型のほうが、依存をドバッと増やしてる印象が強くなる。気がする。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？