最も完全なpackage.json分析

1. 概要

フロントエンドの作業を開始して以来、各プロジェクトのルート ディレクトリには通常、package.json ファイルがあります。このファイルは、現在のプロジェクトに必要なさまざまなモジュールと、プロジェクトの構成情報 (名前、バージョン、ライセンスなど) を定義します。

npm install コマンドを実行すると、package.json ファイル内の構成、つまり構成プロジェクトに必要な実行環境と開発環境に応じて、必要なモジュールが自動的にダウンロードされます。

たとえば、以下のファイルには単純なプロジェクト名とバージョン番号のみが含まれています。

{
  「名前」:「インドン」、
  "バージョン" : "1.0.0",
}

package.json ファイルは、サフィックス .json からわかるように、JSON オブジェクトです。オブジェクトの各メンバーは、現在のプロジェクトの設定です。たとえば、name はプロジェクト名、version はバージョン番号です。

もちろん、多くの人は package.json 構成をあまり気にせず、より多くの依存関係や devDependencies 構成を使用します。

以下は、各フィールドが実際に何を意味するかを詳しく説明した、より完全な package.json ファイルです。

{
    "名前": "インドン",
    "バージョン":"0.0.1",
    「説明」: 「antd-テーマ」、
    "キーワード":["node.js","antd", "テーマ"],
    「ホームページ」: 「https://zhiqianduan.com」、
    「バグ」:{"url":"http://path/to/bug","email":"[email protected]"},
    「ライセンス」: 「ISC」、
    「著者」: 「yindong」、
    「貢献者」:[{"名前":"yindong","メールアドレス":"[email protected]"}],
    "ファイル": "",
    "メイン": "./dist/default.js",
    "ビン": "",
    "男"： ""、
    "ディレクトリ": "",
    「リポジトリ」: {
  「タイプ」: 「git」、
  "url": "https://path/to/url"
 },
    「スクリプト」: {
      "開始": "webpack サーブ --config webpack.config.dev.js --progress"
    },
    "config": { "ポート": "8080" },
    「依存関係」: {},
    「devDependencies」: {
        "@babel/core": "^7.14.3",
        "@babel/プリセット環境": "^7.14.4",
        "@babel/preset-react": "^7.13.13",
        "バベルローダー": "^8.2.2",
        "babel-プラグインインポート": "^1.13.3",
        "グロブ": "^7.1.7",
        "以下": "^3.9.0",
        "レスローダー": "^9.0.0",
        "スタイルローダー": "^2.0.0",
        "webpack": "^5.38.1",
        "webpack-cli": "^4.7.0",
        "webpack-dev-server": "^3.11.2"
    },
    「ピア依存関係」: {
        "お茶": "2.x"
    },
    「バンドルされた依存関係」: [
        「レンダリングされた」、「スーパーストリーム」
    ]、
    "エンジン": {"ノード": "0.10.x"},
   "os" : [ "win32", "darwin", "linux" ],
    "CPU" : [ "x64", "ia32" ],
    「プライベート」：偽、
    「公開構成」: {}
  }

2. 名前フィールド

package.json ファイルで最も重要なフィールドは、必須の name と version です。名前とバージョンを組み合わせることで、完全に一意であると見なされる識別子が形成されます。パッケージの変更はバージョンの変更と同時に行う必要があります。
名前は 214 文字以下でなければなりません。また、先頭に . または _ は使用できません。また、大文字は使用できません。名前は最終的に URL の一部となるため、URL で使用できない文字を含めることはできません。
npm では、コア ノード モジュールと同じ名前を使用しないことを公式に推奨しています。名前に js または node を追加しないでください。必要に応じて、エンジンを使用して動作環境を指定できます。
名前は require への引数として渡されるため、短くても適切な説明となる必要があります。

3. バージョンフィールド

バージョンの一般的な形式は xxx であり、このルールに従う必要があります。
package.json ファイルで最も重要なフィールドは、必須の name と version です。名前とバージョンを組み合わせることで、完全に一意であると見なされる識別子が形成されます。バージョンをリリースするたびに、既存のバージョンと同じにすることはできません。

4. 説明フィールド

description は説明情報を記述するために使用される文字列です。これにより、npm リポジトリを検索するときに、ユーザーがモジュールを見つけやすくなります。

5. キーワードフィールド

キーワードは、npm リポジトリで検索するときにモジュールを見つけるのに役立つ文字列の配列です。

6. ホームページフィールド

ホームページ プロジェクトのホームページ アドレス。

7. バグズフィールド

bugs は、問題アドレスまたは電子メール アドレスを使用してプロジェクトの問題を報告するために使用されます。

「バグ」: { 
  「URL」:「https://github.com/owner/project/issues」、
  「メール」: 「[email protected]」
}

8. ライセンスフィールド

ライセンスは現在のプロジェクトの契約であり、これによりユーザーはモジュールを使用するための権利と、モジュールの使用に関する制限を知ることができます。
「ライセンス」: 「BSD-3条項」

9. 著者フィールド 寄稿者フィールド

著者は特定の人物であり、貢献者は現在のプロジェクトに貢献する人々のグループを指します。同時に、誰もが物体です。名前フィールドとオプションの URL および電子メール フィールドがあります。

"著者"： {
  「名前」:「インドン」、
  「メール」：「[email protected]」、
  「URL」:「https://zhiqianduan.com/」
}

文字列として記述することもできます

「著者」: 「yindong [email protected] (https://zhiqianduan.com/)」

10. ファイルフィールド

ファイル属性の値は配列で、モジュール下のファイル名またはフォルダ名が含まれます。フォルダ名の場合は、フォルダ内のすべてのファイルも含まれます（ファイルが他の構成によって除外されていない限り）。
モジュールのルートディレクトリに .npmignore ファイルを作成できます。このファイルに記述されたファイルは、files 属性に記述されていても除外されます。このファイルの記述方法は .gitignore と同様です。

11. メインフィールド

main フィールドはロードするエントリ ファイルを指定し、このファイルは require がインポートされるときにロードされます。このフィールドのデフォルト値は、モジュールのルート ディレクトリにある index.js です。

12. ビンフィールド

bin 項目は、各内部コマンドに対応する実行可能ファイルの場所を指定するために使用されます。ノード ツールを作成する場合は、必ず bin フィールドを使用します。
CLI ツールを作成するときは、ツールの実行コマンドを指定する必要があります。たとえば、よく使用される webpack モジュールの場合、実行コマンドは webpack です。

「ビン」: {
  "webpack": "bin/index.js",
}

webpack コマンドを実行すると、bin/index.js ファイル内のコードが実行されます。
bin オプションが存在する場合、モジュールは依存関係としてインストールされます。 node_modules/.bin/ に対応するファイルを生成します。
Npm はこのファイルを探し、node_modules/.bin/ ディレクトリにシンボリック リンクを作成します。実行時に node_modules/.bin/ ディレクトリがシステムの PATH 変数に追加されるため、npm を実行するときに、パスなしでコマンドを通じてこれらのスクリプトを直接呼び出すことができます。
node_modules/.bin/ ディレクトリ内のすべてのコマンドは、npm run [command] 形式を使用して実行できます。コマンドラインで「npm run」と入力し、Tab キーを押すと、使用可能なすべてのコマンドが表示されます。

13. マンフィールド

man は、現在のモジュールの man ドキュメントの場所を指定するために使用されます。

"男" :[ "./doc/calc.1" ]

14. ディレクトリフィールド

ディレクトリは、モジュールの構造を記述するいくつかのメソッドを作成し、各ディレクトリの場所をユーザーに伝えます。

15. リポジトリフィールド

コード リポジトリ アドレスを指定します。これは、プロジェクトにコードを投稿したい人にとって役立ちます。

「リポジトリ」: {
  「タイプ」:「git」、 
  「URL」: 「https://github.com/npm/npm.git」
}

16. スクリプトフィールド

scripts は、スクリプト コマンドを実行するための npm コマンドラインの省略形を指定します。たとえば、start は、npm run start を実行するときに実行されるコマンドを指定します。

「スクリプト」: {
  「開始」: 「ノード ./start.js」
}

スクリプト フィールドを使用すると、エイリアスとして理解できるシェル コマンドをすばやく実行できます。
スクリプトは node_modules にインストールされたモジュールを直接使用できます。これは、npx コマンドを使用して直接実行する場合とは異なります。

「スクリプト」: {
  「ビルド」: 「webpack」
}

// npm 実行ビルド
// npxウェブパック

17. 設定フィールド

config フィールドは、コマンド ラインに環境変数を追加するために使用されます。

{
  「名前」:「インドン」、
  「設定」: { 「ポート」: 「8080」 },
  「スクリプト」: {「開始」:「node server.js」}
}

次に、server.js スクリプトの config フィールドの値を参照できます。

console.log(process.env.npm_package_config_port); // 8080

ユーザーは npm config set を介してこの値を変更できます。

npm config yindong:port 8000 を設定します

18. 依存関係フィールド、devDependencies フィールド

依存関係フィールドはプロジェクトの実行に依存するモジュールを指定し、devDependencies はプロジェクト開発に必要なモジュールを指定します。

それらの値はオブジェクトです。このオブジェクトの各メンバーは、モジュール名と対応するバージョン要件で構成され、依存モジュールとそのバージョン範囲を示します。

依存関係をインストールするときは、--save パラメータを使用してモジュールをdependencies プロパティに書き込み、--save-dev を使用してモジュールをdevDependencies プロパティに書き込みます。

「devDependencies」: {
        "webpack": "^5.38.1",
}

オブジェクト内の各項目はキーと値のペアで表され、先頭にモジュール名、末尾に対応するモジュールのバージョン番号が続きます。バージョン番号は、「メジャー バージョン.マイナー バージョン.スモール バージョン」という形式になります。

バージョンノート

• 固定バージョン: たとえば、5.38.1 の場合、インストール時には指定されたバージョンのみがインストールされます。
• チルダ: たとえば、~5.38.1 は、5.38.x の最新バージョン (5.38.1 以上) をインストールすることを意味しますが、5.39.x はインストールしません。つまり、インストール中にメジャー バージョン番号とマイナー バージョン番号は変更されません。
• 番号を挿入: たとえば、ˆ5.38.1 は、5.xx の最新バージョン (5.38.1 以上) をインストールすることを意味しますが、6.xx はインストールしません。つまり、インストール中にメジャー バージョン番号は変更されません。メジャーバージョン番号が 0 の場合、キャレットの動作はチルダと同じであることに注意してください。これは、開発段階にあり、マイナーバージョン番号の変更でもプログラムの非互換性が発生する可能性があるためです。
• 最新: 最新バージョンをインストールします。

19. peerDependencies フィールド

モジュールを開発する際に、現在のモジュールと依存モジュールの両方がサードパーティのモジュールに依存し、互換性のない 2 つのバージョンに依存している場合は、問題が発生します。

たとえば、プロジェクトはモジュール A とモジュール B のバージョン 1.0 に依存しており、モジュール A 自体はモジュール B のバージョン 2.0 に依存しています。
ほとんどの場合、これは問題にはならず、モジュール B の両方のバージョンが共存して同時に実行できます。ただし、この依存関係がユーザーに公開されると問題が発生します。

最も一般的なシナリオはプラグインです。たとえば、モジュール A はモジュール B のプラグインです。ユーザーがインストールした B モジュールはバージョン 1.0 ですが、A プラグインは B モジュールのバージョン 2.0 でのみ使用できます。このとき、ユーザーが B のバージョン 1.0 のインスタンスを A に渡すと、問題が発生します。したがって、テンプレートをインストールするときに、A と B が一緒にインストールされる場合、B は 2.0 モジュールである必要があることをユーザーに通知するメカニズムが必要です。

peerDependencies フィールドは、プラグインが必要とするメイン ツールのバージョンを指定するために使用されます。 peerDependencies フィールドを通じて制限できます。myless モジュールの使用は、less モジュールの 3.9.x バージョンに依存する必要があります。

{
  "名前": "マイレス",
  「ピア依存関係」: {
    "以下": "3.9.x"
  }
}

npm バージョン 3.0 以降では、peerDependencies はデフォルトでインストールされなくなったことに注意してください。初期化時にデフォルトでは表示されません。

20. bundledDependencies フィールド

bundledDependencies は、公開時に一緒にパッケージ化されるモジュールを指定します。

21. オプションの依存関係フィールド

依存モジュールを使用でき、モジュールが見つからないか取得できない場合でも npm の実行を継続したい場合は、このモジュール依存関係を optionsDependencies 構成に含めることができます。この構成は依存関係と同じ方法で記述されますが、ここでモジュールのインストールが失敗しても npm install が失敗することはありません。

22. エンジン分野

engines フィールドは、Node や npm のバージョン、ブラウザなど、モジュールが実行されるプラットフォームを指定します。

{ "エンジン" : { "ノード" : ">=0.10.3 <0.12", "npm" : "~1.0.20" } }

23. OSフィールド

モジュールが実行できるオペレーティングシステムを指定できます

"os" : [ "darwin", "linux", "win32" ]

24. CPUフィールド

モジュールを特定のCPUアーキテクチャでのみ実行するように制限する

"CPU" : [ "x64", "ia32" ]

25. プライベートフィールド

このプロパティが true に設定されている場合、npm は公開を拒否します。これは、プライベート モジュールが誤って公開されるのを防ぐためです。

"プライベート": true

26. publishConfig フィールド

この構成はモジュールが公開されたときに有効になり、公開に使用される一連の値を設定するために使用されます。モジュールをデフォルトで最新としてマークしたり、デフォルトでパブリック リポジトリに公開したりしたくない場合は、ここでタグまたはリポジトリ アドレスを設定できます。

通常、モジュールを内部リポジトリなどの特定の npm リポジトリにのみ公開する場合は、publishConfig は private とともに使用されます。

「プライベート」：true、
「公開構成」: {
  "タグ": "1.0.0",
  「レジストリ」: 「https://registry.npmjs.org/」、
  「アクセス」：「公開」
}

27. preferGlobalフィールド

preferGlobal の値は、ユーザーがモジュールをグローバル モジュールとしてインストールしない場合 (つまり、-global パラメータを指定しない場合) に警告を表示するかどうかを示すブール値であり、モジュールがグローバル モジュールとしてインストールされることが意図されていることを示します。

「preferGlobal」: false

28. ブラウザフィールド

ブラウザは、ブラウザで使用されるテンプレートのバージョンを指定します。 Browserify などのブラウザ パッケージング ツールを使用すると、どのファイルをパッケージ化するかを知ることができます。

「ブラウザ」: {
  "tipso": "./node_modules/tipso/src/tipso.js"
},

参考文献

[1] npmパッケージ.json
[2] JavaScript標準リファレンスチュートリアル

最も包括的な package.json 解析に関するこの記事はこれで終わりです。より関連性の高い package.json 解析コンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM を応援していただければ幸いです。