とあるプロジェクトでyarn upgradeを行ったところ、こんなメッセージが出てきました。
warning （略） > chokidar@2.1.8: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
そもそも、Chokidarって何？
Node.jsには、ファイル更新を管理する手法がいくつかありますが、OSなど環境によって挙動が異なってしまいます。
Chokidarは、それらの手法を一貫して管理できるようなラッパーです。
直接使っている人は多くないかも知れませんが、sassコンパイラやwebpack-dev-serverなど、ビルドツール系のライブラリでは「ファイル監視」機能があると便利なので、よく使われています。
依存性の削減
「Chokidar 3にすると依存パッケージが15分の1になる」という話について、作者が詳細を書いていました。
簡単にまとめますと、
- 第三者のパッケージを参照していると、不意に差し替えられたりする危険がある
- ネイティブエクステンションは不安定な
node-gypを捨てて、Node.jsネイティブに実装されたN-APIに乗り換え - パースに必要なサブライブラリも、依存性の多い別ライブラリを参照するのはやめて書き直し
- 結果、依存ライブラリ数は201個から15個に、ディスク容量は8MB超から500kB未満まで削減
Chokidar特有の事情
ただし、JavaScript界隈の状況を考えると、一般に敷衍するのが難しいことが考えられます。Chokidarの好条件としては、
- 関連するパッケージの開発支援を行うだけのパワーがある
- Node.js専用（ブラウザで動かすことは、そもそも不可能）
ということがあります。資金的、プログラミングリソース的に手が回らなければ、「全く第三者のパッケージを排除する」という選択は行なえません。
そして、Node.js専用の場合、ブラウザで使えるライブラリを書くのと比べて以下のようなメリットがあります。
- 動くランタイムのバージョン範囲を決めることが可能
- ブラウザバンドルほどにはコード容量への制約が厳しくない
ブラウザの場合、処理系は閲覧者のものなので、ある程度古いバージョンを考慮せざるを得ず、最新版のJavaScriptにある機能を積極的に使う、というわけにもいかなくなります。
そして、HTMLに適用するJavaScriptはネットワーク経由で送信されますので、容量を減らす方向への圧力も強いです。依存性を回避するためとはいえ、同じコードを何度も書いて容量を消費するようなことは、ブラウザバンドルだと嫌われてしまいます。