nodejs npm package.json 中国語 document_node.js

はじめに

このドキュメントには、package.json に必要な設定がすべて含まれています。 js オブジェクトではなく、実際の json である必要があります。

このドキュメントで説明されている動作の多くは、npm-config(7) の影響を受けます。

デフォルト値

npm はパッケージの内容に基づいていくつかのデフォルト値を設定します。

名前

package.json の最も重要なフィールドは、名前フィールドとバージョン フィールドです。これらはすべて必須であり、それなしではインストールできません。名前とバージョンを組み合わせて形成される識別子は一意であるとみなされます。パッケージを変更するとバージョンも変更されるはずです。

name はこのものの名前です。注:

1. 名前にnodeやjsを入れないでください。 package.json を記述したため、js であると想定されますが、「engine」フィールドを使用してエンジンを指定できます (下記を参照)。
2. この名前は、URL、コマンドラインパラメータ、またはフォルダ名の一部として使用されます。 URL セーフでない文字は使用できません。
3. この名前はパラメータとして require() に渡されるため、短くても意味が明確である必要があります。
4. 自分の名前に夢中になる前に、npm レジストリをチェックして、その名前がす​​でに使用されているかどうかを確認するとよいでしょう。 http://registry.npmjs.org/

バージョン

package.json の最も重要なフィールドは、名前フィールドとバージョン フィールドです。これらはすべて必須であり、それなしではインストールできません。名前とバージョンを組み合わせて形成される識別子は一意であるとみなされます。パッケージを変更するとバージョンも変更されるはずです。

バージョンは、npm の依存関係に含まれるノード semver によって解析可能である必要があります。 (自分で使いたい場合は、npm install semver を実行してください)

使用可能な「数値」または「範囲」については、semver(7) を参照してください。

説明

紹介文、文字列を入れます。負けた人はnpm searchで検索すると便利です。

キーワード

キーワード、配列、文​​字列。負けた人はnpm searchで検索するのも便利です。

ホームページ

プロジェクト公式ウェブサイトのURL。

注: これは「url」とは異なります。 「url」フィールドを入力すると、レジストリは他の場所で公開したアドレスへのジャンプであると判断し、迷子になるように指示します。

ええ、クソ、冗談じゃない。

バグ

プロジェクトの提出問題の URL および/または電子メール アドレス。これは問題を抱えているdiaosiにとって役立ちます。

次のようになります:

1 つまたは 2 つ指定できます。 URL を指定するだけの場合は、オブジェクトは必要なく、文字列だけが必要です。

URL が指定されている場合、それは npm bugs コマンドによって使用されます。

ライセンス

人々が使用の権利と制限を理解できるように、ライセンスを指定する必要があります。

最も簡単な方法は、BSD や MIT などの一般的なライセンスを使用する場合、次のようにライセンス名を指定するだけです:

より複雑なライセンス条件がある場合、またはより詳細を提供したい場合は、次のようにすることができます:

ライセンス ファイルをルート ディレクトリに提供することもお勧めします。

人物フィールド: 著者、寄稿者

著者は人間です。寄稿者はさまざまな人々です。 person は、次のような名前フィールド、オプションの URL、および電子メール フィールドを持つオブジェクトです:

または、すべてを文字列に入力すると、npm がそれを解析します:

どちらの形式でも、電子メールと URL はオプションです。

npm ユーザー情報にトップレベルのメンテナフィールドを設定することもできます。

ファイル

files は、プロジェクト内のファイルを含む配列です。フォルダーに名前が付けられている場合は、フォルダー内のファイルも含まれます。 (他の条件によって無視されない限り)

.npmignore ファイルを指定して、ファイルがファイル フィールドに含まれている場合でもファイルが保持されるようにすることもできます。実際、これは .gitignore に似ています。

メイン

メイン フィールドはモジュール ID で、プログラムのメイン プロジェクトへのポインタです。つまり、パッケージの名前が foo で、ユーザーがそれをインストールしてから require("foo") を実行すると、メイン モジュールのエクスポート オブジェクトが返されます。

これは、ルート ディレクトリに相対的なモジュール ID である必要があります。

ほとんどのモジュールにとって、これは完全に意味があり、それ以外は何もありません。

ビン

多くのパッケージには、PATH に配置する必要がある 1 つ以上の実行可能ファイルがあります。 npm を使用すると、お母さんはもう心配する必要がなくなります (実際、npm を実行可能にするのはこの機能です)。

この機能を使用するには、package.json の bin フィールドにコマンド名からファイルの場所へのマップを指定します。初期化中に、npm はそれを prefix/bin (グローバル初期化) または ./node_modules/.bin/ (ローカル初期化) にリンクします。

たとえば、npm には次のものがあります:

そのため、npm を初期化すると、cli.js スクリプトへのシンボリックリンクが /usr/local/bin/npm に作成されます。

パッケージ名と同じ名前の実行可能ファイルが 1 つだけある場合。その後、次のような文字列を使用するだけです:

結果は次と同じです:

男

man プログラムで使用する単一のファイルまたはファイルの配列を指定します。

ファイルが 1 つだけ指定されている場合は、実際のファイル名に関係なく、初期化後の man の結果が返されます。

このようにして、man foo は ./man/doc.1 ファイルを使用できるようになります。

ファイル名がパッケージ名で始まらない場合は、次の接頭辞が付加されます:

man foo および man foo-bar のファイルが作成されます。

man ファイルは数字で終わる必要があり、オプションで .gz 接尾辞を付けて圧縮する必要があります。この番号は、ファイルがどの man セクションにインストールされるかを示します。

は man foo と man 2 foo に対して作成されます。

ディレクトリ

CommonJS パッケージ仕様では、ディレクトリハッシュを使用してパッケージの構造を示すいくつかの方法が説明されています。 npm の package.json を見ると、doc、lib、man というラベルの付いたディレクトリがあることがわかります。

この情報は将来使用される可能性があります。

ディレクトリ.lib

敗者にライブラリフォルダーの場所を教えてください。現時点では lib フォルダーを使用することに特別なことはありませんが、重要なメタ情報です。

ディレクトリ.bin

「bin」ディレクトリを指定すると、そのフォルダー内のすべてのファイルが「bin」フィールドとして使用されます。

「bin」フィールドを指定した場合、これは効果がありません。

ディレクトリ.man

マニュアルページが詰まったフォルダー。 「男性」フィールドを慎重に作成します。

によって「man」配列を生成する man ページが詰まったフォルダー。 フォルダーを歩き回ります。

ディレクトリ.doc

ここにマークダウン ファイルを置きます。最終的に、おそらくいつか、これらはうまく表示されるでしょう。
ここにマークダウンファイルを入れてください。最終的にはうまく表示されます。
たぶん、いつか。

ディレクトリ.例

サンプルスクリプトをここに置きます。ある日、それは巧妙な方法で現れるかもしれません。

リポジトリ

コードを保存する場所を指定します。これは貢献したい人にとって役立ちます。 git リポジトリが github 上にある場合は、npm docs コマンドで見つけることができます。

これを実行します:

URL は、変更されていないバージョン管理プログラムで直接処理できるパブリック (読み取り専用でも) URL である必要があります。 HTML プロジェクト ページであってはなりません。コンピューターが見るものだから。

スクリプト

「スクリプト」は、パッケージのさまざまなライフサイクル中に実行されるスクリプト コマンドで構成されるハッシュ オブジェクトです。キーはライフサイクル イベントで、値は実行するコマンドです。

npm-scripts(7) を参照

構成

「config」ハッシュを使用して、パッケージ スクリプトで使用されるバージョン間パラメータを構成できます。この例では、パッケージに次の構成があるとします:

次に、npm_package_config_port 環境変数を参照する「start」コマンドがあり、ユーザーは npm config set foo:port 8001 を介してこれをオーバーライドできます。

npm-config(7) および npm-scripts(7) を参照してください。

依存関係

依存関係は、パッケージ名のセットのバージョン範囲を指定するハッシュです。バージョン範囲は、1 つ以上のスペースで区切られた文字列です。依存関係には tarball または git URL を使用することもできます。

テスト依存関係や移行依存関係を依存関係ハッシュに入れないでください。以下の devDependency を参照してください。

詳細については、semver(7) を参照してください。

1.version は version と完全に一致している必要があります
2.>バージョンはバージョン
より大きくなければなりません 3.>=バージョン 上記と同じ
4.<バージョン 同上
5.<=version 上記と同じ
6.~バージョンはほぼ同じです。semver(7)
を参照してください。 7.1.2.x 1.2.0、1.2.1 など、ただし 1.3.0 は含まれません
8.http://... 以下の「URL に応じて」を参照
9.* すべて
10."" 空、*
と同じ 11.バージョン 1 - バージョン 2 は >=version1 <=version2 と同じです。
12.range1 || range2 2 つのうちの 1 つを選択します。
13.git... 以下の「Git URL に依存します」を参照してください
14.user/repo 以下の「GitHub URL」を参照してください
15. たとえば、以下は合法です:

依存関係 URL

パッケージの初期化時にダウンロードされて初期化される tarball URL を指定できます。

Git URL に依存します

Git URL は次の形式にすることができます:

commit-ish は、git によってチェックアウトできる任意のタグ、sha、またはブランチです。デフォルトはマスターです。

GitHub URL

バージョン 1.1.65 以降では、「user/foo-project」を使用して、次のような GitHub URL を参照できます。

devDependency

誰かがあなたのモジュールをダウンロードして自分のプログラムで使用することを計画している場合、その人はあなたが使用する外部のテスト フレームワークやドキュメント フレームワークをダウンロードして構築することを望んでいない、またはその必要がない可能性があります。

この場合、これらの依存プロジェクトを devDependency ハッシュにリストすることをお勧めします。

これらは、npm link または npm install がルート ディレクトリで実行されるときに初期化され、他の npm 設定パラメーターと同様に管理できます。詳細については、npm-config(7) を参照してください。

CoffeeScript や他の言語を Javascript にコンパイルするなど、プラットフォーム固有ではないビルド ステップの場合は、事前公開スクリプトを使用して実装し、devDependency に配置します。

例:

事前公開スクリプトは公開前に実行されるため、ユーザーは使用する前に自分でスクリプトをコンパイルする必要はありません。また、開発モード (npm install をローカルで実行するなど) では、このスクリプトはより適切なテストのために実行されます。

ピア依存関係

ホスト上で require が必要ない場合など、一部のシナリオでは、ホスト ツールまたはライブラリを使用してパッケージの互換性キーを表示する必要があります。これは通常、プラグインを参照するために使用されます。特に、モジュールは、ホスト ドキュメントによって予期され指定されている特定のインターフェイスを公開する場合があります。

例:

これにより、パッケージは 2.x バージョンの tea でのみ初期化できるようになります。 npm install tea-latte は次の依存関係を生成する可能性があります

競合する依存関係がある別のプラグインを初期化しようとすると、エラーが発生します。したがって、プラグインの要件は、特定のバージョンに固定することなく、可能な限り弱く制約されるようにしてください。

このホストがサーバー仕様に準拠していると仮定すると、このパッケージのメジャー バージョンを変更するだけでプラグインが破損します。したがって、パッケージ内のすべての 1.x バージョンを使用している場合は、それを表すために「^1.0」または「1.x」を使用します。機能紹介 1.5.2 に依存する場合は、「>= 1.5.2 < 2」を使用します。

バンドルされた依存関係

リリース時に含まれるパッケージ名のセット。

「bundleDependency」(d が欠落) と綴ることもできます。

オプションの依存関係

依存関係が利用可能で、インストールに失敗した場合でも npm に初期化を継続させたい場合は、それをOptionalDependency ハッシュに入れることができます。これは、依存関係のハッシュと同様に、パッケージ名とバージョンまたは URL のマップです。それはただ間違って実行されます。

依存関係の欠如を処理することもプログラムの責任です。たとえば、次のようになります:

OptionalDependency は依存関係内の同じ名前の項目をオーバーライドするため、通常はそれらを 1 か所に置くよりも優れています。

エンジン

作業ノードのバージョンを指定できます:

また、依存関係と同様に、バージョンを指定しない場合、またはバージョンとして「*」を指定した場合は、ノードのすべてのバージョンが機能します。

「engines」フィールドを指定した場合、npm はそのフィールドにノードが存在することを要求します。「engines」が省略された場合、npm はノード上で動作するとみなします。

次のように、「engines」フィールドを使用して、どの npm バージョンがプログラムをより適切に初期化できるかを指定することもできます。

ユーザーが Engine-strict フラグを設定しない限り、このフィールドは推奨値にすぎないことに注意してください。

エンジン厳格

指定したバージョン以外のノードまたは npm でモジュールが実行されないことが確実な場合は、package.json ファイルで "engineStrict": true を設定できます。ユーザーのエンジン厳密な設定をオーバーライドします。

よほどの確信がない限り、これを行わないでください。エンジンのハッシュが過度に制限されていると、簡単に問題が発生する可能性があります。この選択は慎重に検討してください。悪用した場合は、将来の npm バージョンで削除される予定です。

OS

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

ホワイトリストの代わりにブラックリストを使用することもできます。名前の前に「!」を追加します:

オペレーティング システムは process.platform を使用して検出します。

特別な理由はありませんが、ブラックリストとホワイトリストの両方をサポートしています。

CPU

コードが特定の CPU アーキテクチャでのみ実行できる場合は、次のいずれかを指定できます:

OS オプションと同様に、アーキテクチャをハッキングすることもできます:

CPU アーキテクチャは process.arch を使用して検出されます。

グローバルを好む

パッケージが主にグローバルにインストールする必要があるコマンドライン プログラムである場合は、これを true に設定して、ローカルにのみインストールするユーザーに警告を表示します。

ユーザーがローカルにインストールすることを実際に妨げるわけではありませんが、期待どおりに動作しない場合の誤解を防ぐのに役立ちます。

プライベート

「private」: true に設定すると、npm は公開しません。

これは、プライベート ライブラリの誤ったリリースを防ぐ方法です。特定のパッケージが特定のレジストリ (内部レジストリなど) でのみ公開されるようにしたい場合は、レジストリの公開時構成パラメータをpublishConfighash の説明でオーバーライドします。

publishConfig

これは公開時に使用される構成コレクションです。これは、タグまたはレジストリを設定する場合に便利です。そのため、特定のパッケージに「lastest」のタグが付けられていないこと、またはデフォルトでグローバル パブリック レジストリに公開されていることを確認できます。

どの設定もオーバーライドできますが、公開目的に関連するのはもちろん「タグ」と「レジストリ」のみです。

オーバーライドできるもののリストについては、npm-config(7) を参照してください。