tl; dr:
- はい、にカスタムエントリを追加できます
package.json
。
- キー名を選択してください:
- まだ定義されていません(詳細は以下)
- 将来の使用のために予約されていません(詳細は以下を参照)
- プレフィックスを避け
_
、$
- できれば、カスタムエントリをネストするための単一のトップレベルキーを使用してください。
たとえば、ドメインを所有している場合は、次のようにカスタムキーをexample.org
格納できます。これは、逆ドメイン名表記の最上位キー内に、置換された、および該当する場合は(コメントを参照)(例):random
_
.
-
org_example
{
"name": "application-name"
, "version": "0.0.1"
, "private": true
, "dependencies": {
"express": "2.4.7"
, "jade": ">= 0.0.1"
}
, "org_example": {
"random": true
}
}
このようなカスタムプロパティを読み取るには、次の手法を使用します。
require("./package.json").org_example.random // -> true
npm
のファイル形式は、ほとんどがCommonJSパッケージ仕様package.json
に準拠しています。
カスタムキーの選択に関して:CommonJSパッケージ仕様は次のように述べています(私の強調):
次のフィールドは、将来の拡張用に予約されています:、、、、、、、、、、、、、、、、、、。_build
default
email
external
files
imports
maintainer
paths
platform
require
summary
test
using
downloads
uid
パッケージ記述子仕様の拡張は、一般的なパッケージ管理に関連する意味を持たない無害な名前でプロパティを名前間隔で指定することにより、将来の標準名の衝突を回避するように努める必要があります。
次のフィールドは、パッケージレジストリが独自の裁量で使用するために予約されています:id
、type
。またはで始まる_
$
すべてのプロパティは、パッケージレジストリが独自に使用するために予約されています。