@ledsun blog

Hのキーがhellで、Sのキーがslaveだ、と彼は思った。そしてYのキーがyouだ。

npm auditは有益なのか?

体感として、npm auditが出してくる警告は、利益より手間の方が多いように感じてはいます。 とはいえセキュリティに関わることなので、手間でも対応しなきゃなあと、頑張って対応しています。 僕自身は、主にアプリケーションのメンテナンスだけなので、それほど大変ではないのですが、chokidarのような色々な開発ツールで使っているパッケージの脆弱性が報告されると、対応が面倒です。

  1. chokidarを使っている複数のパッケージを更新しないといけない
  2. パッケージによってすぐに更新されたり、しばらく時間が掛かったりする

ので、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: Broken by Design — Overreacted

読んだ感想は、漠然とした不満が具体的になってて良かったです。 僕の意見は次です。

  1. 引数なしのnpm installで表示されるのはやり過ぎ。npm install hogeで特定のパッケージをインストールするときは表示されると嬉しそう
  2. devDependenciesのパッケージは外してほしい。前述のchokidarも開発ツールのファイル監視に使われているだけど、アプリケーションコードに入りようがない。これに対応しないといけないのは理不尽

あるリポジトリgit cloneしてnpm installしたときに脆弱性が表示されても「知るかよ」って感じじゃないですか。 まあ、わかりますよ。そのコードを開発するためじゃなくて、いきなり本番として使う為にチェックアウトした人には、脆弱性の有無を知る権利があるというのは。 ならnpm startに入れれば良いじゃんと思うけど、すべてのパッケージがnpm startで実行される訳じゃないですし・・・。

devDependenciesの方も「npm auditの警告がでたら該当するnpm パッケージをdependenciesからdevDependenciesに移動する」奇習が生まれるのが想像できます。

とはいえ、警告が多すぎても無視される奇習が生まれる気がするので、うーんなんともゲームのバランス調整のような難しさがあります。 npmのエコシステムとしては、パッケージメンテナとユーザーの間に軋轢を生む感じが嫌だなあ、と思います。 Nodeのnpmパッケージを作るハードルを下げて、実現した「みんなnpmパッケージのユーザーでありメンテナだ」の思想と乖離している感じがします。 まあ、いまはもうそんな牧歌的な時代ではないのかもしれません。