Node.jsのパッケージ管理システム「npm」を使うとpackage.jsonというファイルが生成されます。
この中には「dependencies」と「devDependencies」というよく似た２つの記述があります。
ここでは、「dependencies」と「devDependencies」の違いや、それぞれに記載されている情報の見方についてまとめています。
▼以下のような表示です。
"dependencies": {
"core-js": "^3.6.5",
"vue": "^2.6.11"
},
"devDependencies": {
"@vue/cli-plugin-babel": "~4.5.0",
"@vue/cli-plugin-eslint": "~4.5.0",
"@vue/cli-service": "~4.5.0",
"babel-eslint": "^10.1.0",
"eslint": "^6.7.2",
"eslint-plugin-vue": "^6.2.2",
"vue-template-compiler": "^2.6.11"dependenciesとdevDependenciesの違い
最初に結論から言うと、dependenciesとdevDependenciesの違いは、本番環境と開発環境でインストールするパッケージを管理するものです。
「devDependencies」の「dev」とはdevelopment(開発)という意味です。このため「devDependencies」が開発時にインストールするパッケージです。
「dev」がついていない「dependencies」が本番用にインストールするパッケージです。
開発用と本番用をなぜ切り分ける必要があるのか？
開発用と本番用をなぜ切り分けるのは、開発環境と本番環境で必要になる処理が異なるためです。
開発環境ではコードの変更内容をリアルタイムで変更して変更内容をブラウザで即座に確認したり、コードの自動確認機能でエラーがないかを確認できる方が圧倒的に便利です。
一方、本番環境では、ユーザーのリクエストに対する反応速度を上げる必要があるため余計なパッケージは除外します。
また、WEBページにアクセスしてきたユーザーにとって、エラーメッセージやエラーの詳細などはどうでもいい不要な情報です。
このため、開発環境と本番環境でパッケージを切り分けられるようになっています。
なお、余計なパッケージが不要なdependenciesの方が記述はシンプルです。
"dependencies": { //本番環境の依存パッケージ
"core-js": "^3.6.5",
"vue": "^2.6.11"
},
"devDependencies": { //開発環境での依存パッケージ
"@vue/cli-plugin-babel": "~4.5.0",
"@vue/cli-plugin-eslint": "~4.5.0",
"@vue/cli-service": "~4.5.0",
"babel-eslint": "^10.1.0",
"eslint": "^6.7.2",
"eslint-plugin-vue": "^6.2.2",
"vue-template-compiler": "^2.6.11"本番環境と開発環境の切り分け方法
package.jsonのdependenciesとdevDependenciesを使って、開発環境と本番環境を切り替えるときは、どのパッケージをインストールするかをコマンド「npm install」のオプションの有無で指定します。
開発環境の場合
開発環境ではオプション無しの「npm install」を実行します。すると「dependencies」と「devDependencies」に記載されているパッケージを両方ともインストールします。
npm install本番環境の場合
本番環境ではオプションに「–production」を付けて実行します。
すると、「dependencies」に記載されたパッケージのみがインストールされます。
npm install --production補足：installの省略形
npm installの「install」は「i」として省略することもできます。
開発環境の場合
npm install↑↓ 同じ
npm i本番環境の場合
npm install↑↓ 同じ
npm i --production各パッケージのチルダ「~」とキャレット「^」の意味
「dependencies」と「devDependencies」には各パッケージ名と、チルダ「~」とキャレット「^」があります。
"devDependencies": {
"@vue/cli-plugin-babel": "~4.5.0",
"@vue/cli-plugin-eslint": "~4.5.0",
"@vue/cli-service": "~4.5.0",
"@vue/compiler-sfc": "^3.0.0",
"babel-eslint": "^10.1.0",
"eslint": "^6.7.2",
"eslint-plugin-vue": "^7.0.0"
},これらの記述によってインストールされるパッケージのバージョンが異なります。
バージョンの見方
「~」とキャレット「^」について説明する前に、まずパッケージのバージョンの表示方法について理解しておく必要があります。
バージョンは以下の３つに分かれています。
- メジャーバージョン（major）
- マイナーバージョン（minor）
- パッチ
上から順に変更内容が大きくなります。一番下のパッチはコードを少し修正しましたという内容です。
バージョンは以下のように表示されます。
メジャー.マイナー.パッチ例えば、「4.6.3」という記述の場合、
- メジャーバージョンは「4」
- マイナーバージョンは「6」
- パッチのバージョンは「3」
となります。
チルダ「~」の意味
チルダ「~」は一番末尾のバージョンに変更があるパッケージがあった場合のみ更新するという意味です。
このため、次の２つの状態で、どこまで更新するかが変わります。
- マイナーバージョンが記載されている場合。
- マイナーバージョンが記載されていない場合（メジャーバージョンの指定しかない場合）
マイナーバージョンが記載されている場合
マイナーバージョンが記載されている場合のチルダ「~」はパッチのバージョンで新しいバージョンをがあれば更新するという内容です。
例えば、「~1.2.3」という記述があれば、もしバージョン「1.2.5」「1.2.7」というバージョンがあれば更新します。
一方、「2.0」「2.1.3」「3.2」というようにメジャーバージョンが違うものや、「1.3.0」「1.5.2」というようにマイナーバージョンが異なる場合はパッケージを更新しません。
つまり「~1.1.2」 は「 1.1.2 <= version < 1.2.0 」ということです。1.1.2以上のバージョンで1.2.0未満のバージョンなら更新するという意味になります。
マイナーバージョンが記載されていない場合
マイナーバージョンが記載されていない場合のチルダ「~」はマイナーとパッチので新しいバージョンをがあれば更新するという内容です。
例えば、「~1」という記述があれば、もしバージョン「1.2」「1.3.7」というバージョンがあれば更新します。
一方、「2.0」「2.1」「2.3.5」「3.2」というようにメジャーバージョンが異なる場合はパッケージを更新しません。
つまり「~2」 は「 2.0 <= version < 3.0 」ということです。2.0以上のバージョンで3.0未満のバージョンなら更新するという意味になります。
Allows patch-level changes if a minor version is specified on the comparator. Allows minor-level changes if not.
マイナーバージョンが指定されている場合、パッチレベルの変更を許可します。そうでない場合は、マイナーレベルの変更を許可します。
（参考）npm公式ページ：https://www.npmjs.com/package/semver/v/4.3.6
キャレット（^）
キャレット（^）はゼロを除く、一番左端のバージョンは固定して、それ以外のバージョンで新しいものがあれば更新します。
メジャーバージョンがゼロ以外の場合
「^2」「^3.2」「^4.0.0」などメジャーバージョンが0以外の場合は、メジャーバージョンを固定して、マイナーとパッチのバージョンのみ更新します。
例えば、「^2」なら、2.0.0以上、3.0.0未満のバージョンを許容します（3.0.0は許容しません）
「^2.1」も同じく2.0.0以上、3.0.0未満のバージョンを許容します（3.0.0は許容しません）
「^2.1.3」も同じく2.0.0以上、3.0.0未満のバージョンを許容します（3.0.0は許容しません）
メジャーバージョンがゼロの場合
「^0.2.3」や「^0.3」などメジャーバージョンがゼロの場合は、マイナーバージョンの値を固定し、パッチのバージョンのみを更新します。
例えば「^0.2.3」であれば、「0.2.0」以上、「0.3.0」未満となります。
例えば「^0.3」であれば、「0.3.0」以上、「0.4.0」未満となります。
Allows changes that do not modify the left-most non-zero digit in the [major, minor, patch] tuple.
[メジャー.マイナー.パッチ]の指定において、ゼロを除く一番左端の数字の変更を許可します。
（参考）npm公式ページ：https://www.npmjs.com/package/semver/v/4.3.6
全てのバージョンを許可する（*アスタリスク）
メジャーやマイナー、パッチなどを指定せず、新しいバージョンが出たらそれに変更するようにしたい場合は、「*」アスタリスクを使います。
1.2.*
*実例
"vue": *上記の場合、npm installを実行したときにパッケージに新しいものがあれば、メジャーバージョンが変わっていたとしても更新します。
なお、空文字を指定した場合も「*」と同じ処理になります。
"vue": ""メジャーバージョンが変わると、処理や記述が大きく変更になり、これまでのコードで動かなくなる可能性が高いので、「*」のみや「空文字」で指定することはめったにありません。
xを使って指定する
マイナー、メジャー、パッチの特定の部分が変わった場合に更新を許可したい場合は「x」を使って指定することができます。
ｘは大文字でも小文字でもどちらでも使えます。
メジャーバージョンの更新を許可することはほとんどないので、マイナーとパッチのバージョンのどちらかに指定します。
マイナーとパッチのバージョン更新を許可する
マイナーとパッチのバージョン更新を許可する場合は、「1.x」や「2.x」というように記述します。
例えば「2.x」であれば「2.0.0」以上、「3.0.0」未満のバージョンがあれば更新するという処理になります。
パッチのバージョン更新を許可する
パッチのバージョン更新を許可する場合は、「1.2.x」や「2.4.x」というように記述します。
例えば「2.4.x」であれば「2.4.0」以上、「2.5.0」未満のバージョンがあれば更新するという処理になります。
更新可能な範囲を数値で指定する
なお、「^」「~」「x」などの記号を使わずに、バージョンを数値で指定することもできます。
X.Y.Z - A.B.C実例
1.2.3 - 2.3.4これは、バージョンが「1.2.3」以上、「2.3.4」以下の範囲なら更新すると言う意味です。
1.2 - 2.3.4これは、バージョンが「1.2.0」以上、「2.3.4」以下の範囲なら更新すると言う意味です。
1.2 - 3これは、バージョンが「1.2.0」以上、「4.0.0」以下の範囲なら更新すると言う意味です。
右側のバージョンの指定がメジャーのみの場合、そのメジャーバージョンは全て更新対象となります。
例「4」なら、「4.x.x」は全て含む。5.0.0以上は含まない。
参考リンク
バージョンの指定方法の詳細はnpmの公式ページで確認できます。
