体感として、npm auditが出してくる警告は、利益より手間の方が多いように感じてはいます。
とはいえセキュリティに関わることなので、手間でも対応しなきゃなあと、頑張って対応しています。
僕自身は、主にアプリケーションのメンテナンスだけなので、それほど大変ではないのですが、chokidarのような色々な開発ツールで使っているパッケージの脆弱性が報告されると、対応が面倒です。
- chokidarを使っている複数のパッケージを更新しないといけない
- パッケージによってすぐに更新されたり、しばらく時間が掛かったりする
ので、in progressなタスクが居座るのが面倒です。 パッケージメンテナーの人は、加えて、ユーザーから早く直せという要望が来て大変なのだろうなあ・・・と思います。
これに関わる話が、DHHのコメント/bin/importmap outdated · Issue #19 · rails/importmap-rails · GitHubに入っていました。
I think there's a very fair critique that "npm audit" in its current form isn't actually all that great: https://twitter.com/dan_abramov/status/1412376404738686984
↑のURLのツイートが↓です。
"npm audit" is harmful. It was carelessly rolled out with no consideration for build tooling. When your audit system produces 99.9% false positives in a certain context, you need to ramp it down and think again. What a stain on the whole ecosystem. https://t.co/jELUdg75Fx
— Dan (@dan_abramov) July 6, 2021
たどって行くと次のブログ記事にまとまっています。
npm audit: Broken by Design — Overreacted
読んだ感想は、漠然とした不満が具体的になってて良かったです。 僕の意見は次です。
- 引数なしの
npm installで表示されるのはやり過ぎ。npm install hogeで特定のパッケージをインストールするときは表示されると嬉しそう devDependenciesのパッケージは外してほしい。前述のchokidarも開発ツールのファイル監視に使われているだけど、アプリケーションコードに入りようがない。これに対応しないといけないのは理不尽
あるリポジトリをgit cloneしてnpm installしたときに脆弱性が表示されても「知るかよ」って感じじゃないですか。
まあ、わかりますよ。そのコードを開発するためじゃなくて、いきなり本番として使う為にチェックアウトした人には、脆弱性の有無を知る権利があるというのは。
ならnpm startに入れれば良いじゃんと思うけど、すべてのパッケージがnpm startで実行される訳じゃないですし・・・。
devDependenciesの方も「npm auditの警告がでたら該当するnpm パッケージをdependenciesからdevDependenciesに移動する」奇習が生まれるのが想像できます。またWebPackのようなバンドラーが乗っ取られた場合、バンドラー経由でプロダクションコードに脆弱性を埋め込まれる可能性もあります。npm auditの対象外とするのは一手かもしれませんが、いまさらかなあ？
とはいえ、警告が多すぎても無視される奇習が生まれる気がするので、うーんなんともゲームのバランス調整のような難しさがあります。 npmのエコシステムとしては、パッケージメンテナとユーザーの間に軋轢を生む感じが嫌だなあ、と思います。 Nodeのnpmパッケージを作るハードルを下げて、実現した「みんなnpmパッケージのユーザーでありメンテナだ」の思想と乖離している感じがします。 まあ、いまはもうそんな牧歌的な時代ではないのかもしれません。
