EOL対応を通して学んだpackage.jsonの役割①

Posted at 2026-03-08

はじめに

Node.jsのEOL対応のため、NodeやNuxt、各種packageのアップグレードを行うことになりました。

これまでpackage.jsonについては「依存関係を書くファイル」程度の理解でしたが、実際にアップグレード対応を進める中で、その仕組みやlockファイルの重要性を改めて理解しました。

本記事では、自分自身の振り返りも兼ねて学んだことを整理します。
同じようにEOL対応を行う方、package.jsonについて知りたい方の参考になれば幸いです。

EOL（End Of Life）とは、そのバージョンのサポートが終了することを指します。
Node.jsの場合、EOLを迎えると以下のようなリスクが考えられます。

つまり「動いてはいるけれど、安全ではない」状態になります。
そのため、EOLを迎える前にNodeや関連パッケージのアップグレード対応が必要になります。

package.jsonは、Nodeプロジェクトの「設計図」のようなファイルです。

プロジェクトの依存関係を記録しておくことで、

でも、npm installや yarn install を実行するだけで、同じように必要なパッケージをインストールすることができます。

また、依存関係を記述することで、同じプロジェクトに臨むメンバーと環境を合わせることができます。

この中には、

などが記述されています。

それでは、package.jsonでできることをEOL対応での経験をもとにアウトプットします。

package.jsonには、プロジェクトで使用しているライブラリとそのバージョンを記録することができます。
プロジェクトでどのライブラリを使用しているのかを一目で確認することができます。

package.jsonに記載されているバージョンを元にインストールされるため、メンバー間でライブラリのバージョンに差異がでることを防ぐことができます。
もし使用するパッケージのバージョンが人によって違ってしまうと、

といった問題が発生し、リポジトリが荒れてしまう原因になります。

package.jsonには依存関係だけでなく、プロジェクトに関するさまざまな設定を記録することができます。
代表的なものとして以下があります。

下記のように用途によって依存関係を分けて管理することができます。

// 例）
"scripts": {
  "dev": "nuxt dev",
  "build": "nuxt build"
}

scriptsにコマンドを記述しておくことで、npm run devのように簡単なコマンドで開発サーバーを起動することができます。
プロジェクトによっては、

などがまとめられていることが多いです。

"engines": {
  "node": ">=24"
}

enginesでは、プロジェクトで使用するNode.jsのバージョンを指定することができます。
EOL対応を行う際には、Nodeのバージョンを更新する必要があるため、この設定が重要になるケースもあります。

今回はpackage.jsonの基礎についてまとめました。
次回以降では、実際の経験を元に、下記について書いていけたらと考えています！