npmパッケージがインストールされるバージョンをできるだけ固定したい

[KentaHizume]

概要

同じpackage.jsonを使用していても、インストールされる npm パッケージのバージョンが異なる場合があり、
これにうまく対処する方法を探しています。現在の論点は下記の2点です。

1. 直接依存するパッケージについてはチルダ~、キャレット^を使用した幅のあるバージョン指定は避けたほうがよいのではないかと思っているのですが、こちらの是非を伺いたいです。
2. 推移的に依存するパッケージについては管理が現実的ではないので、バージョンが異なるリスクを受け入れたほうがよいと思っているのですが、こちらの是非を伺いたいです。

現状整理

npm では、package.json を用いてパッケージとバージョンを指定する。
また、パッケージのバージョンと依存関係はpackage-lock.jsonに記録される。

現在、package.json では、下記のように幅のあるバージョン指定をしている。
チルダ~：パッチバージョンのアップデートを許容する
キャレット^：マイナーバージョンのアップデートを許容する

たとえば、viteの最新版が@6.0.5の状態で、

1. クローン
2. npm ci を実行
3. package.json で"vite": "^6.0.0"を指定
4. npm install を実行
5. npm ls viteで実際にインストールされたバージョンを確認
   すると、[email protected]がインストールされる。

問題点1

パッケージが semantic versioning に従っていれば影響はないはずだが、
従っていない場合、あるいは想定外の影響があった場合に、不具合の要因となる。

また、maia/maris固有の問題として、
フロントエンドのnpmパッケージの更新を時間差で行うので、
フロントエンドのコードは共通だが、
使用しているパッケージが異なる（package-lock.jsonに差分がある）という事象が発生する。

解決策

package.json でのバージョン指定では、固定のバージョンを指定する。
このことにより、直接依存するパッケージについてはバージョンが固定される。

問題点2

直接依存するパッケージについて、固定のバージョンを指定したとしても、
推移的に依存するパッケージのバージョンについて同様の問題が発生する。
というのも、依存先のパッケージのpackage.jsonで幅のあるバージョン指定をしていた場合は、
この設定に基づいて依存関係が解決されるからである。

解決策

公式ドキュメントの下記の箇所によると、
overrides フィールドを使用することで、深い階層のパッケージについてもバージョンを固定できる。
そのため依存パッケージをすべて列挙すればすべてのパッケージのバージョンを固定できるはずである。

https://docs.npmjs.com/cli/v11/configuring-npm/package-json#overrides
完全なオブジェクト形式を使用すると、パッケージ自体とその子パッケージをオーバーライドすることができます。これにより、fooは常に1.0.0となり、foo以降の任意の深さにあるbarも1.0.0に設定されます。

{
  "overrides": {
    "foo": {
      ".": "1.0.0",
      "bar": "1.0.0"
    }
  }
}

懸念点

overridesフィールドをメンテナンスし続けることが必要になるが、
複数の階層にわたって推移的に依存していることも多くあるので、列挙・管理するには複雑すぎて、
逆に問題を引き起こす恐れがある。具体的には、overridesフィールドのメンテ忘れによる不具合や、セキュリティアップデートへの対応漏れを引き起こす可能性がある。

暫定案

package.json でのバージョン指定では、固定のバージョンを指定する。
一方で、overridesフィールドの使用は避ける。

[KentaHizume]

正しい運用かどうかは議論の余地があるが、推移的に依存しているものでバージョンを固定したい場合は、1段目に書いてしまうことも可能ではある。

[KentaHizume]

幅のある指定はライブラリを公開する場合に壊れにくくするために可能になっているはずなので、
Webアプリケーションのpackage.jsonに関してはバージョンを固定しても特に不都合はないはず。