メインコンテンツまでスキップ
Version: Next

package.json

パッケージに関する情報を記述したファイルです。 タイトル、作者、依存パッケージなどのメタ情報を含んでいます。 このセクションで説明しているのは、pnpmを含む全ての主要なNode.jsのパッケージマネージャに共通する標準的な内容です。

engines

ソフトウェアが(パッケージが)動作するNode.jsとpnpmのバージョンを指定できます。

{
"engines": {
"node": ">=10",
"pnpm": ">=3"
}
}

開発時に使用しているpnpmのバージョンがenginesフィールドに指定したバージョンと一致しない場合、常に失敗し、エラーメッセージを出力するでしょう。

ユーザがengine-strict設定フラグ (.npmrcを参照) を指定しなければ、このフィールドの役割は助言を与えるだけですし、あなたのパッケージを依存パッケージとしてインストールするときに警告を出力するだけでしょう。

dependenciesMeta

dependencies, optionalDependencies, devDependencies内で宣言された依存関係のために使用される追加のメタ情報です。

dependenciesMeta.*.injected

ローカルな依存パッケージについてこの設定項目をtrueに設定すると、モジュールディレクトリに対象のパッケージのハードリンク(シンボリックリンクではありません)を作成します。

例えば、ワークスペースに次のようなpackage.jsonがあるなら、cardディレクトリのnode_modulesに、buttonのシンボリックリンクを作成します。

{
"name": "card",
"dependencies": {
"button": "workspace:1.0.0"
}
}

ところで、buttonのピア依存関係にreactがあるとどうなるでしょうか。 モノリポに含まれる全てのプロジェクトが、同じバージョンのreactを使用しているなら何も問題はありません。 しかし、cardの要求するbuttonreact@16を要求し、formreact@17を要求しているとしたらどうなるでしょうか。 injectedフィールドを使用しないなら、任意のバージョンのreactを選択し、buttonのdev依存関係としてインストールしなければなりません。 injectedフィールドを使用すれば、パッケージにbuttonを注入しつつ、buttonをそれ自体が要求するバージョンのreactと共にインストールできるようになります。

従って、cardpackage.jsonは次のようになります。

{
"name": "card",
"dependencies": {
"button": "workspace:1.0.0",
"react": "16"
},
"dependenciesMeta": {
"button": {
"injected": true
}
}
}

cardの依存パッケージとしてbuttonのハードリンクを作成します。そして、card/node_modules/buttonの依存パッケージとしてreact@16のシンボリックリンクを作成します。

こちらはformpackage.jsonです。

{
"name": "form",
"dependencies": {
"button": "workspace:1.0.0",
"react": "17"
},
"dependenciesMeta": {
"button": {
"injected": true
}
}
}

formの依存パッケージとしてbuttonのハードリンクを作成します。そして、form/node_modules/buttonの依存パッケージとしてreact@17のシンボリックリンクを作成します。

peerDependenciesMeta

このフィールドには、peerDependenciesフィールドに記述した依存パッケージに関連する、追加の情報を記述します。

peerDependenciesMeta.*.optional

この設定項目をtrueに設定すると、パッケージマネージャーは指定したピア依存関係を任意の(必須ではない)依存パッケージだと認識します。 そのため、利用者が(コンシューマーが)除外したとしても、エラーとして報告することはありません。

例:

{
"peerDependencies": {
"foo": "1"
},
"peerDependenciesMeta": {
"foo": {
"optional": true
},
"bar": {
"optional": true
}
}
}

barpeerDependenciesに指定されていなかったとしても、任意の(必須ではない)依存パッケージとして認識することになるので注意してください。 その場合、pnpmはどのバージョンのbarでも問題ないと仮定します。 fooも任意(必須ではない)ですが、バージョンを指定するために必要です。

publishConfig

パッケージを梱包する(パックする)とき、マニフェストに登場するいくつかのフィールドを上書きできます。 上書きできるフィールドは次のとおりです。

フィールドを上書きするには、publishConfig に公開するときのフィールド値を設定します。

例えばpackage.jsonを次のように記述します。

{
"name": "foo",
"version": "1.0.0",
"main": "src/index.ts",
"publishConfig": {
"main": "lib/index.js",
"typings": "lib/index.d.ts"
}
}

そうすると、公開するマニフェストは次のようになります。

{
"name": "foo",
"version": "1.0.0",
"main": "lib/index.js",
"typings": "lib/index.d.ts"
}

publishConfig.executableFiles

初期設定では、パッケージのアーカイブに含まれるファイルのうち、binフィールドに列挙されていないファイルには、実行可能ファイルとしてのフラグを設定しません。移植性を考慮しているからです。 executableFilesフィールドには、実行可能ファイルとしてのフラグ (+x) を設定するべきファイルを指定できます。binフィールドに指定したファイルから直接アクセスできないファイルも指定できます。

{
"publishConfig": {
"executableFiles": [
"./dist/shim.js"
]
}
}

publishConfig.directory

publishConfig.directoryフィールドには、実際に公開するサブディレクトリをpackage.jsonからの相対パスで指定できます。

サードパーティのビルドツールを使用する場合など、現在のパッケージを改変した結果を特定のディレクトリに出力する場合を想定しています。

次の例では"dist"フォルダーにpackage.jsonを配置しなければなりません。

{
"name": "foo",
"version": "1.0.0",
"publishConfig": {
"directory": "dist"
}
}

publishConfig.linkDirectory

  • デフォルト: true
  • タイプ: Boolean

When set to true, the project will be symlinked from the publishConfig.directory location during local development.

例:

{
"name": "foo",
"version": "1.0.0",
"publishConfig": {
"directory": "dist"
"linkDirectory": true
}
}

pnpm.overrides

このフィールドを指定すると、依存関係グラフにおける任意の依存関係を上書きするようpnpmに指示できるようになります。 全てのパッケージが同じバージョンの依存パッケージを使うように強制したり、バグ修正をバックポートしたり、フォークした依存パッケージへ置き換えるときに役立ちます。

overridesフィールドは、最上位のプロジェクトでしか設定できないので注意してください。

"pnpm"."overdides"フィールドは次のように設定します。

{
"pnpm": {
"overrides": {
"foo": "^1.0.0",
"quux": "npm:@myorg/quux@^1.0.0",
"bar@^2.1.0": "3.0.0",
"qar@1>zoo": "2"
}
}
}

上書きするように指定した依存関係が所属するパッケージは、">" を区切り文字として、パッケージセレクタと依存関係セレクタにより指定できます。例えば、qar@1>zooと指定すると、zooの依存関係qar@1だけを上書きすることになり、他の依存関係には影響しません。

An override may be defined as a reference to a direct dependency's spec. This is achieved by prefixing the name of the dependency with a $:

{
"dependencies": {
"foo": "^1.0.0"
},
"overrides": {
"foo": "$foo"
}
}

The referenced package does not need to match the overridden one:

{
"dependencies": {
"foo": "^1.0.0"
},
"overrides": {
"bar": "$foo"
}
}

pnpm.packageExtensions

packageExtensionsフィールドは、追加の情報と共に既存のパッケージ定義を拡張する方法を提供します。 例えば、react-reduxpeerDependenciesに存在するべきreact-domがなかった場合、packageExtensionsフィールドで次のように追加(パッチ)できます。

{
"pnpm": {
"packageExtensions": {
"react-redux": {
"peerDependencies": {
"react-dom": "*"
}
}
}
}
}

packageExtensionsフィールドのキーはパッケージ名、あるいは、パッケージ名とsemver形式のバージョン範囲を組み合わせたものです。つまり、あるパッケージの特定のバージョンだけをパッチできるのです。

{
"pnpm": {
"packageExtensions": {
"react-redux@1": {
"peerDependencies": {
"react-dom": "*"
}
}
}
}
}

packageExtensionsフィールドは、dependenciesoptionalDependenciespeerDependenciespeerDependenciesMetaを拡張できます。

より長い例は次のとおりです。

{
"pnpm": {
"packageExtensions": {
"express@1": {
"optionalDependencies": {
"typescript": "2"
}
},
"fork-ts-checker-webpack-plugin": {
"dependencies": {
"@babel/core": "1"
},
"peerDependencies": {
"eslint": ">= 6"
},
"peerDependenciesMeta": {
"eslint": {
"optional": true
}
}
}
}
}
}
tip

Together with Yarn, we maintain a database of packageExtensions to patch broken packages in the ecosystem. If you use packageExtensions, consider sending a PR upstream and contributing your extension to the @yarnpkg/extensions database.

pnpm.peerDependencyRules

pnpm.peerDependencyRules.ignoreMissing

pnpm は、このリストで指定された peerDependencies が存在しなくても警告を出力しません。

たとえば、次の構成では、依存関係が react を要求しているが、 react がインストールされていない場合でも、pnpmは警告を出力しません。

{
"pnpm": {
"peerDependencyRules": {
"ignoreMissing": ["react"]
}
}
}

Package name patterns may also be used:

{
"pnpm": {
"peerDependencyRules": {
"ignoreMissing": ["@babel/*", "@eslint/*"]
}
}
}

pnpm.peerDependencyRules.allowedVersions

指定された範囲については peerDependencies が満たされていなくても警告が表示されなくなります。

例えば、react@16 を必要とする依存関係があったとして、それが react@17 でも正常に動くことをあなたが知っている場合、次のような構成を使用できます。

{
"pnpm": {
"peerDependencyRules": {
"allowedVersions": {
"react": "17"
}
}
}
}

これは pnpm に、peerDependencies に react を持っているすべての依存関係について、 react v17 をインストールすることを許可するように指示します。

It is also possible to suppress the warnings only for peer dependencies of specific packages. For instance, with the following configuration react v17 will be only allowed when it is in the peer dependencies of the button v2 package or in the dependencies of any card package:

{
"pnpm": {
"peerDependencyRules": {
"allowedVersions": {
"button@2>react": "17",
"card>react": "17"
}
}
}
}

pnpm.peerDependencyRules.allowAny

allowAny is an array of package name patterns, any peer dependency matching the pattern will be resolved from any version, regardless of the range specified in peerDependencies. 例:

{
"pnpm": {
"peerDependencyRules": {
"allowAny": ["@babel/*", "eslint"]
}
}
}

The above setting will mute any warnings about peer dependency version mismatches related to @babel/ packages or eslint.

pnpm.neverBuiltDependencies

This field allows to ignore the builds of specific dependencies. The "preinstall", "install", and "postinstall" scripts of the listed packages will not be executed during installation.

An example of the "pnpm"."neverBuiltDependencies" field:

{
"pnpm": {
"neverBuiltDependencies": ["fsevents", "level"]
}
}

pnpm.onlyBuiltDependencies

A list of package names that are allowed to be executed during installation. If this field exists, only the listed packages will be able to run install scripts.

例:

{
"pnpm": {
"onlyBuiltDependencies": ["fsevents"]
}
}

pnpm.allowedDeprecatedVersions

This setting allows muting deprecation warnings of specific packages.

例:

{
"pnpm": {
"allowedDeprecatedVersions": {
"express": "1",
"request": "*"
}
}
}

With the above configuration pnpm will not print deprecation warnings about any version of request and about v1 of express.

pnpm.patchedDependencies

This field is added/updated automatically when you run pnpm patch-commit. It is a dictionary where the key should be the package name and exact version. The value should be a relative path to a patch file.

例:

{
"pnpm": {
"patchedDependencies": {
"express@4.18.1": "patches/express@4.18.1.patch"
}
}
}

pnpm.allowNonAppliedPatches

When true, installation won't fail if some of the patches from the patchedDependencies field were not applied.

{
"pnpm": {
"patchedDependencies": {
"express@4.18.1": "patches/express@4.18.1.patch"
}
"allowNonAppliedPatches": true
}

pnpm.updateConfig

pnpm.updateConfig.ignoreDependencies

Sometimes you can't update a dependency. For instance, the latest version of the dependency started to use ESM but your project is not yet in ESM. Annoyingly, such a package will be always printed out by the pnpm outdated command and updated, when running pnpm update --latest. However, you may list packages that you don't want to upgrade in the ignoreDependencies field:

{
"pnpm": {
"updateConfig": {
"ignoreDependencies": ["load-json-file"]
}
}
}

Patterns are also supported, so you may ignore any packages from a scope: @babel/*.

pnpm.auditConfig

pnpm.auditConfig.ignoreCves

A list of CVE IDs that will be ignored by the pnpm audit command.

{
"pnpm": {
"auditConfig": {
"ignoreCves": [
"CVE-2022-36313"
]
}
}
}

pnpm.requiredScripts

Scripts listed in this array will be required in each project of the workspace. Otherwise, pnpm -r run <script name> will fail.

{
"pnpm": {
"requiredScripts": ["build"]
}
}

resolutions

Same as pnpm.overrides. We read it for easier migration from Yarn.