package.jsonファイルの構造
ここ数年、JavaScriptやNode.jsプロジェクトに何らかの形で取り組んできた場合は、確かにいくつかのプロジェクトに出くわしたことがあります。 package.json
ファイル、プロジェクトおよびモジュール用のnpmの構成ファイル。 この投稿では、典型的なpackage.jsonファイルにある最も重要なキーと値のいくつかを探ります。
プロジェクトの開始
npmパッケージマネージャーを使用してプロジェクトを開始する最も簡単で最速の方法は、 init
コマンドと -y
フラグ。すべての質問にはいと答えます。
$ npm init -y
プロジェクトの名前は、現在のフォルダーの名前と同じになります。
The init
コマンドは書き込みます package.json
次のようなJSONコンテンツを含む現在のディレクトリへのファイル:
{
"name": "hello-alligator",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC"
}
最初のpackage.jsonファイルの各キーを調べてみましょう。
- name :プロジェクトの名前。すべて小文字でURLセーフである必要があります。 名前の前にスコープ(例: @ angle / angle-cli )を付けることができ、プロジェクトが非公開の場合はオプションですが、プロジェクトを公開する場合は名前が必須であり、一意である必要がありますnpmリポジトリにあります。
- version :node-semverが理解できるバージョン番号。 これは、プライベートモジュールではオプションであり、パブリックモジュールでは必須であり、非常に重要です。
- description :プロジェクトの説明。 これはオプションであり、プロジェクトをリポジトリで簡単に見つけることができる場合に役立ちます。
- main :プロジェクトのエントリファイル。
- スクリプト:
scripts
keyは、スクリプト名をキーとして、コマンドを値として持つオブジェクトを想定しています。 これは、コマンドラインから直接実行でき、ローカルサーバーでプロジェクトを開始したり、本番用にビルドしたり、テストを実行したりするなど、あらゆる種類のスクリプトを指定する場合に便利です。 チャンスはそれですscripts
ここで、一般的なpackage.jsonファイルで最も手動で変更を加えます。 - keywords :npmリポジトリでモジュールを見つけるのに役立つキーワードの配列。
- author :作成者フィールドには、次のキーを持つオブジェクトが必要です
name
,email
とurl
. これにより、人々はプロジェクトの所有者と簡単に連絡を取ることができます。 - license :SPDX識別子を使用したライセンス名が必要です。 デフォルトはISCライセンスであり、
MIT
もう1つの人気のあるライセンスの選択肢になります。 使用することもできますUNLICENSED
プライベートでクローズドソースのプロジェクトの場合。
依存関係の管理
npmの主な強みは、プロジェクトの依存関係を簡単に管理できることです。 したがって、プロジェクトのpackage.jsonファイルが主にプロジェクトの依存関係の指定に集中しているのは当然のことです。 通常の依存関係がありますが、 devDependencies 、 peerDependencies 、 optionalDependencies 、およびbundledDependenciesもあります。 それらを調べてみましょう:
- 依存関係:通常のプロジェクト依存関係。 これは、依存関係の大部分が存在する可能性が最も高い場所です。 を使用して、このような依存関係をプロジェクトに追加します
$ npm install my-dependency
. - devDependencies :プロジェクトで作業しているときにのみ役立つ依存関係。 たとえば、テストライブラリとトランスパイラーはほとんどの場合devDependenciesとして追加する必要があります。 npmを使用してdevDependencyを追加します
--save-dev
installコマンドでフラグを立てます。 - optionalDependencies :npmによってオプションとして扱われるべき依存関係。 つまり、オプションの依存関係を満たせない場合でも、npmが文句を言ったり、インストールに失敗したりすることはありません。 を使用してオプションの依存関係をインストールします
--save-optional
installコマンドを使用します。 - bundledDependencies :プロジェクトにバンドルされるパッケージ名の配列が必要です。 使用
--save-bundle
バンドルされた依存関係のリストにも依存関係を追加するには、installコマンドでフラグを立てます。 - peerDependencies :ピア依存関係は、プロジェクトが依存するモジュールを指定するのに役立ちます。 このように、一部のピア依存関係が欠落している場合、npmは警告を発行します。
おそらく前に見たように、依存関係はさまざまな形式を受け入れて、依存関係に使用できるバージョンまたはバージョンの範囲を指定できます。 例えば:
- 2.4.2:正確にバージョン2.4.2
- ^ 2.4.2:バージョン2.4.2と互換性のある最新バージョン
- 〜2.4.2:2.4.2、2.4.3、2.4.4、…などのバージョンで動作します
- 〜2.4:これは2.4、2.5、2.6などのバージョンで機能します…
- 2.4.x:パッケージの2.4バージョンの任意のパッチバージョンで動作します
- 2.x:パッケージの2バージョンのマイナーバージョンで動作します
- > = 2.4:2.4以上のバージョン。 <、<=または>を使用することもできます
- 2.4.2 3.1.1:バージョン2.4.2とバージョン3.1.1の間のすべてのバージョン
各範囲をで区切ることにより、複数の可能なバージョン範囲を指定することもできます。 ||
.
より便利な構成キー
オプションでプロジェクトのpackage.jsonファイルに入れることができる構成は他にもあるので、最も便利な構成のいくつかに簡単に触れてみましょう。
- ブラウザ:代わりにブラウザキーを使用してください
main
サーバーではなくブラウザで使用することを目的としたプロジェクトの場合。 - private :このキーがに設定されている場合
true
、プロジェクトをnpmリポジトリに公開することはできません。 これは、プロジェクトを誤って世界に公開するのを防ぎたい場合に役立ちます。 - エンジン:使用
engines
プロジェクトが動作するNode.jsやnpmの特定のバージョンを指定します。 のキーを持つオブジェクトを取りますnode
および/またはnpm
そして、バージョンの範囲を指定する依存関係の値として持っているもののように見える値。 - ホームページ:プロジェクトのホームページのURL。
- bugs :問題とバグを報告できるURL。 これは多くの場合、プロジェクトのGithub問題ページへのURLになります。
- files :このオプションのキーは、プロジェクトに別のプロジェクトへの依存関係が追加されたときに含まれるファイルの配列を想定しています。 ファイル名/パスはグロブパターンを使用できます。
files
キーのデフォルト値は提供されていません["*"]
が使用されます。これは、すべてのファイルが含まれることを意味します。 でも心配しないでください、のような特定のファイル/フォルダ.git
とnome_modules
常に無視されます。
これにより、package.json構成に何を入れることができるかについてのかなり良い一般的なアイデアが得られるはずです。 可能なすべての構成キーの詳細については、公式ドキュメントを参照することもできます。