皆さんはnpm install
を実施した際のWARN
についてどのように対応していますか?
私はよくわからないから放置
していたのですが、中には脆弱性に関する警告
が含まれていることがあるようです。
そんな時は、使用しているnode_modulesの脆弱性について調べるコマンド(npm audit)
を活用して、脆弱性を塞いでいきましょう。
ココでは解決までの流れをまとめます。
- Step1:発見(npm installを実施)
- Step2:状況確認(npm auditを実施)
- Step3:対応①(npm audit fixを実施)
- Step4:対応②(手動で修正)
- Step4-1:インストールルールの更新(package.jsonを修正)
- Step4-2:インストール済み情報の削除(package-lock.json、node_modulesディレクトリを削除)
- Step4-3:インストール(npm installを実施)
- Step5:確認(npm auditを実施)
Step1:発見(npm install
を実施)
例)しばらく放置していた環境にnpm install
を実施してみた時の画像です。
found 4548 vulnerabilities (4547 low, 1 high) run `npm audit fix` to fix them, or `npm audit` for details
上記の警告は「脆弱性が疑われるライブラリバージョンを使っていること」に対するものです。
ココでは1件のhighレベルの脆弱性と4547件のlowレベルの脆弱性が検出されています。
Step2:状況確認(npm audit
を実施)
Step3:対応①(npm audit fix
を実施)
npm audit fix
はpackage.json
に記載された範囲でnpmモジュール
のバージョンアップを実施します。まずはpackage.json
の内容を変更しない範囲で対応してみましょう。
Step3-1:自動アップデートをキック(npm audit fix
を実行)
package.json
で許容された範囲でモジュールのバージョンアップが実施されます。
Step3-2:結果の確認(npm audit
を実施)
- ココですべて問題が解消されていれば対応終了です。
Step4:対応②(手動で修正)
npm audit fix
でバージョンアップができなかったモジュールは、package.json
で許可された範囲外のアップデートが必要な場合です。- ラフな表現をすると、
npm audit
的には、「モジュールA
について脆弱性がふさがれたVer2.0.3(例)
以降を使用してほしいんだけど、package.json
で、Ver1.**.**
からVer2.**.**
への自動アップデートは禁止されているから勝手にアップデートしないよ~!」って状態です。
package.json
自体はプログラム作成者が責任を持ってい管理するべきものであるので、バージョン更新の影響の範囲を判断したうえで、内容を編集しても構いません。
なぜ自動アップデートが禁止されるのか
- それは、主に以下の場合が多いようです
- ほとんどのNPMモジュールが
セマンティック・バージョニング(Semantic Versioning)
というバージョン管理を採用している。 セマンティック・バージョニング
には「互換性のないAPIを変更した場合のメジャーバージョンを更新する」というルールがある。 ※ 参考文献:Semantic Versioning 2.0.0
- ほとんどのNPMモジュールが
つまり「モジュールをアップデートすることにより、それまでの使い方が出来なくなる可能性があるので、アップデートする前に影響がないことを確認してください。」という状態です。
個人的な対応方法
私は個々のモジュールについて、使用方法を細かく把握しているわけではないので、「試しにメジャーアップデートしてから、アップデートしたモジュールに関連していそうな機能を触ってみて、問題なさそうならそのまま」といった流れを踏んでいます。(元のpackage-lock.json
をバックアップしておけば元の環境に戻せます。)
Step4-1:インストールルールの更新(package.json
を修正)
npm audit
の結果に対象モジュール
と、推奨最低バージョン
の記述があるはずです。
その内容をもとにpackage.json
の内容を変更してみましょう。
package.json
の記述方法
主にバージョン管理に関係するチルダ表記
とキャレット表記
について説明します。
(その他の、細かい解説は「公式リファレンス:semver | npm Docs」を参照してください。)
チルダ表記 ~
Tilde Ranges ~1.2.3 ~1.2 ~1 Allows patch-level changes if a minor version is specified on the comparator. Allows minor-level changes if not. ~1.2.3 := >=1.2.3 <1.(2+1).0 := >=1.2.3 <1.3.0 ~1.2 := >=1.2.0 <1.(2+1).0 := >=1.2.0 <1.3.0 (Same as 1.2.x) ~1 := >=1.0.0 <(1+1).0.0 := >=1.0.0 <2.0.0 (Same as 1.x) ~0.2.3 := >=0.2.3 <0.(2+1).0 := >=0.2.3 <0.3.0 ~0.2 := >=0.2.0 <0.(2+1).0 := >=0.2.0 <0.3.0 (Same as 0.2.x) ~0 := >=0.0.0 <(0+1).0.0 := >=0.0.0 <1.0.0 (Same as 0.x)
Google翻訳+個人的な補完
チルダの範囲 ~1.2.3
~1.2
~1
コンパレータでマイナーバージョンが指定されている場合、パッチレベルの変更を許可します。そうでない場合は、マイナーレベルの変更を許可します。
~1.2.3
:= >=1.2.3 <1.(2+1).0
:=>=1.2.3 <1.3.0
~1.2
:= >=1.2.0 <1.(2+1).0
:= >=1.2.0 <1.3.0
(と同じ1.2.x)
~1
:= >=1.0.0 <(1+1).0.0
:= >=1.0.0 <2.0.0
(と同じ1.x)
~0.2.3
:= >=0.2.3 <0.(2+1).0
:=>=0.2.3 <0.3.0
~0.2
:= >=0.2.0 <0.(2+1).0
:= >=0.2.0 <0.3.0
(と同じ0.2.x)
~0
:= >=0.0.0 <(0+1).0.0
:= >=0.0.0 <1.0.0
(と同じ0.x)
キャレット表記 ^
Allows changes that do not modify the left-most non-zero digit in the [major, minor, patch] tuple. In other words, this allows patch and minor updates for versions 1.0.0 and above, patch updates for versions 0.X >=0.1.0, and no updates for versions 0.0.X. Many authors treat a 0.x version as if the x were the major "breaking-change" indicator. Caret ranges are ideal when an author may make breaking changes between 0.2.4 and 0.3.0 releases, which is a common practice. However, it presumes that there will not be breaking changes between 0.2.4 and 0.2.5. It allows for changes that are presumed to be additive (but non-breaking), according to commonly observed practices. ^1.2.3 := >=1.2.3 <2.0.0 ^0.2.3 := >=0.2.3 <0.3.0 ^0.0.3 := >=0.0.3 <0.0.4
Google翻訳+個人的な補完
キャレット範囲 ^1.2.3
^0.2.5
^0.0.4
[major, minor, patch]タプルの左端のゼロ以外の数字を変更しない変更を許可します 。言い換えれば、これはバージョン1.0.0
に対するパッチやマイナーアップデート可能にし、上記の、バージョンのパッチアップデート0.X >=0.1.0
、および0.0.X
の更新を可能にします。
多くの作者は、0.x
バージョンのx
を主要な「重大な変更」の指標であるかのように扱います。
キャレット範囲は、作成者がリリース間0.2.4
で0.3.0
重大な変更を加える可能性がある場合に理想的です。
これは一般的な方法です。
しかし、それは0.2.4
と0.2.5
の間に破壊的な変更が含まれないことを前提としています。
よく見られる慣例に従い、付加的な(ただし、破損しない)変更であるとみなされ変更が許容されます。
^1.2.3
:= >=1.2.3 <2.0.0
^0.2.3
:= >=0.2.3 <0.3.0
^0.0.3
:= >=0.0.3 <0.0.4
Step4-2:インストール済み情報の削除(package-lock.json
、node_modules
ディレクトリを削除)
package-lock.json
は環境を再現するためのファイルです。- 環境を復元する可能性がある場合はバックアップを別ディレクトリで管理してください。
- いらない人は削除してOKです。
Step4-3:インストール(npm install
を実施)
Step5:確認(npm audit
を実施)
以上で対応完了です。