本文へ移動
バージョン: 9.x

.npmrc

pnpm は、コマンドライン、環境変数、および `.npmrc` ファイルから設定を取得します。

ユーザーおよびグローバルの `.npmrc` ファイルの内容を更新および編集するには、`pnpm config` コマンドを使用します。

関連する4つのファイルは以下のとおりです。

  • プロジェクトごとの設定ファイル ( `/path/to/my/project/.npmrc` )
  • ワークスペースごとの設定ファイル ( `pnpm-workspace.yaml` ファイルを含むディレクトリ)
  • ユーザーごとの設定ファイル ( `~/.npmrc` )
  • グローバル設定ファイル ( `/etc/npmrc` )

すべての `.npmrc` ファイルは、INI 形式の `key = value` パラメーターのリストです。

`.npmrc` ファイルの値には、`${NAME}`構文を使用して環境変数を指定できます。 環境変数は、デフォルト値を指定して指定することもできます。`${NAME-fallback}`を使用すると、`NAME`が設定されていない場合に`fallback`が返されます。`${NAME:-fallback}`は、`NAME`が設定されていない場合、または空文字列の場合に`fallback`を返します。

依存関係ホイスティングの設定​

hoist​

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

trueの場合、すべての依存関係は`node_modules/.pnpm/node_modules`にホイスティングされます。これにより、リストされていない依存関係を`node_modules`内のすべてのパッケージからアクセスできるようになります。

hoist-workspace-packages​

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

trueの場合、ワークスペースのパッケージは、他のホイスティング設定（`hoist-pattern`と`public-hoist-pattern`）に応じて、`/node_modules/.pnpm/node_modules`または`/node_modules`にシンボリックリンクされます。

hoist-pattern​

  • デフォルト: ['*']
  • タイプ: string[]

どのパッケージを`node_modules/.pnpm/node_modules`にホイスティングするべきかをpnpmに指示します。デフォルトでは、すべてのパッケージがホイスティングされますが、一部の欠陥のあるパッケージにファントム依存関係しかないことがわかっている場合は、このオプションを使用してファントム依存関係のみを排他的にホイスティングできます（推奨）。

例えば

hoist-pattern[]=*eslint*
hoist-pattern[]=*babel*

`!`を使用して、ホイスティングからパターンを除外することもできます。

例えば

hoist-pattern[]=*types*
hoist-pattern[]=!@types/react

public-hoist-pattern​

  • デフォルト: ['*eslint*', '*prettier*']
  • タイプ: string[]

仮想ストア内の非表示のモジュールディレクトリに依存関係をホイスティングする`hoist-pattern`とは異なり、`public-hoist-pattern`は、パターンに一致する依存関係をルートモジュールディレクトリにホイスティングします。ルートモジュールディレクトリへのホイスティングは、アプリケーションコードが、解決戦略を不適切に変更する場合でも、ファントム依存関係にアクセスできることを意味します。

この設定は、依存関係を適切に解決しない一部の欠陥のあるプラグイン可能なツールを扱う場合に役立ちます。

例えば

public-hoist-pattern[]=*plugin*

注: `shamefully-hoist`を`true`に設定することは、`public-hoist-pattern`を`*`に設定することと同じです。

`!`を使用して、ホイスティングからパターンを除外することもできます。

例えば

public-hoist-pattern[]=*types*
public-hoist-pattern[]=!@types/react

shamefully-hoist​

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

デフォルトでは、pnpm はセミストリクトな `node_modules` を作成します。つまり、依存関係は宣言されていない依存関係にアクセスできますが、`node_modules`の外側のモジュールはアクセスできません。このレイアウトでは、エコシステムの大部分のパッケージは問題なく動作します。ただし、一部のツールがホイスティングされた依存関係が `node_modules` のルートにある場合にのみ機能する場合、これを `true` に設定してホイスティングできます。

Nodeモジュール設定​

store-dir​

  • デフォルト
    • **$PNPM_HOME** 環境変数が設定されている場合、**$PNPM_HOME/store**
    • **$XDG_DATA_HOME** 環境変数が設定されている場合、**$XDG_DATA_HOME/pnpm/store**
    • Windowsの場合: **~/AppData/Local/pnpm/store**
    • macOSの場合: **~/Library/pnpm/store**
    • Linuxの場合: **~/.local/share/pnpm/store**
  • タイプ: path

すべてのパッケージがディスクに保存される場所。

ストアは、インストールが行われているのと同じディスク上に常に存在する必要があるため、ディスクごとに1つのストアがあります。現在のディスクにホームディレクトリがある場合は、その中にストアが作成されます。ディスクにホームがない場合は、ファイルシステムのルートにストアが作成されます。たとえば、`/mnt`にマウントされたファイルシステムでインストールが行われている場合、ストアは`/mnt/.pnpm-store`に作成されます。Windowsシステムでも同様です。

別のディスクからストアを設定することは可能ですが、その場合、ハードリンクは同じファイルシステムでのみ可能なため、pnpm はハードリンクする代わりにストアからパッケージをコピーします。

modules-dir​

  • デフォルト: node_modules
  • タイプ: path

依存関係がインストールされるディレクトリ（`node_modules`の代わりに）。

node-linker​

  • デフォルト: isolated
  • タイプ: isolated、hoisted、pnp

Nodeパッケージのインストールに使用されるリンカーを定義します。

  • isolated - 依存関係は、`node_modules/.pnpm`にある仮想ストアからシンボリックリンクされます。
  • hoisted - シンボリックリンクのないフラットな`node_modules`が作成されます。npmやYarn Classicによって作成された`node_modules`と同じです。この設定が使用されている場合、Yarnのライブラリの1つがホイスティングに使用されます。この設定を使用する正当な理由
    1. ツールがシンボリックリンクと適切に動作しません。React Nativeプロジェクトは、ホイスティングされた`node_modules`を使用する場合にのみ機能する可能性が高いです。
    2. プロジェクトがサーバーレスホスティングプロバイダーにデプロイされています。一部のサーバーレスプロバイダー（AWS Lambdaなど）はシンボリックリンクをサポートしていません。この問題に対する代替ソリューションは、デプロイ前にアプリケーションをバンドルすることです。
    3. "bundledDependencies"を使用してパッケージを公開する場合。
    4. --preserve-symlinksフラグを使用してNode.jsを実行する場合。
  • pnp - `node_modules`なし。Plug'n'Playは、Yarn Berryで使用されているNodeの革新的な戦略です。リンカーとして`pnp`を使用する場合は、`symlink`設定も`false`に設定することをお勧めします。

symlink​

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

`symlink`が`false`に設定されている場合、pnpmはシンボリックリンクのない仮想ストアディレクトリを作成します。これは、`node-linker=pnp`と一緒に使用するのに役立つ設定です。

enable-modules-dir​

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

`false`の場合、pnpmはモジュールディレクトリ（`node_modules`）にファイルを書き込みません。これは、モジュールディレクトリがユーザー空間（FUSE）のファイルシステムでマウントされている場合に便利です。FUSEを使用してモジュールディレクトリをマウントできる実験的なCLIがあります。@pnpm/mount-modules。

virtual-store-dir​

  • デフォルト: node_modules/.pnpm
  • タイプ: path

ストアへのリンクを含むディレクトリ。プロジェクトの直接および間接の依存関係はすべてこのディレクトリにリンクされます。

これは、Windowsで長いパスに関する問題を解決できる便利な設定です。非常に長いパスを持つ依存関係がある場合は、ドライブのルートに仮想ストアを選択できます（たとえば、`C:\my-project-store`）。

または、仮想ストアを`.pnpm`に設定し、`.gitignore`に追加できます。これにより、依存関係へのパスが1ディレクトリ上位になるため、スタックトレースがより明確になります。

注記: 仮想ストアは複数のプロジェクト間で共有できません。各プロジェクトは独自の仮想ストアを持つ必要があります（ルートが共有されているワークスペースを除く）。

package-import-method​

  • デフォルト: auto
  • タイプ: auto、hardlink、copy、clone、clone-or-copy

ストアからパッケージをインポートする方法を制御します（node_modules内のシンボリックリンクを無効にする場合は、この設定ではなくnode-linker設定を変更する必要があります）。

  • auto - ストアからパッケージのクローンを作成しようとします。クローン作成がサポートされていない場合は、ストアからパッケージをハードリンクします。クローン作成とリンクのどちらも不可能な場合は、コピーにフォールバックします。
  • hardlink - ストアからパッケージをハードリンクします。
  • clone-or-copy - ストアからパッケージのクローンを作成しようとします。クローン作成がサポートされていない場合は、コピーにフォールバックします。
  • copy - ストアからパッケージをコピーします。
  • clone - ストアからパッケージをクローンします（コピーオンライトまたは参照リンク）。

クローン作成は、パッケージをnode_modulesに書き込むための最良の方法です。最も高速で安全な方法です。クローン作成を使用すると、node_modules内のファイルを編集しても、中央のコンテンツアドレス指定可能なストア内のファイルは変更されません。

残念ながら、すべてのファイルシステムがクローン作成をサポートしているわけではありません。pnpmでの最適なエクスペリエンスを得るには、コピーオンライト（CoW）ファイルシステム（たとえば、LinuxではExt4ではなくBtrfs）を使用することをお勧めします。

modules-cache-max-age​

  • デフォルト: 10080（7日間、分単位）
  • タイプ: number

modulesディレクトリから孤立したパッケージを削除するまでの時間（分単位）。pnpmはmodulesディレクトリにパッケージのキャッシュを保持します。これにより、ブランチを切り替えたり、依存関係をダウングレードする場合のインストール速度が向上します。

Lockfile設定​

lockfile​

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

falseに設定すると、pnpmはpnpm-lock.yamlファイルを読み込んだり生成したりしません。

prefer-frozen-lockfile​

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

trueに設定され、使用可能なpnpm-lock.yamlがpackage.jsonのdependenciesディレクティブを満たしている場合、ヘッドレスインストールが実行されます。ヘッドレスインストールは、lockfileを変更する必要がないため、すべての依存関係の解決をスキップします。

lockfile-include-tarball-url​

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

pnpm-lock.yamlのすべてのエントリに、パッケージのtarballへのフルURLを追加します。

git-branch-lockfile​

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

trueに設定すると、インストール後の生成されるlockfile名は、現在のブランチ名に基づいて命名され、マージ競合が完全に回避されます。たとえば、現在のブランチ名がfeature-fooの場合、対応するlockfile名はpnpm-lock.yamlではなくpnpm-lock.feature-foo.yamlになります。これは通常、コマンドライン引数--merge-git-branch-lockfilesと組み合わせて使用するか、.npmrcファイルでmerge-git-branch-lockfiles-branch-patternを設定して使用します。

merge-git-branch-lockfiles-branch-pattern​

  • デフォルト: null
  • タイプ: 配列またはnull

この設定は、現在のブランチ名と一致して、すべてのgitブランチlockfileファイルをマージするかどうかを決定します。デフォルトでは、--merge-git-branch-lockfilesコマンドラインパラメータを手動で渡す必要があります。この設定により、このプロセスを自動的に完了できます。

例えば

merge-git-branch-lockfiles-branch-pattern[]=main
merge-git-branch-lockfiles-branch-pattern[]=release*

!を使用してパターンを除外することもできます。

レジストリと認証設定​

registry​

npmパッケージレジストリの基本URL（末尾のスラッシュを含む）。

<スコープ>:registry​

指定されたスコープのパッケージに使用されるnpmレジストリ。たとえば、@babel:registry=https://example.com/packages/npm/を設定すると、pnpm add @babel/coreまたは任意の@babelスコープ付きパッケージを使用する場合、パッケージはデフォルトのレジストリではなくhttps://example.com/packages/npmからフェッチされます。

<URL>:_authToken​

指定されたレジストリへのアクセス時に使用する認証ベアラートークンを定義します。例：

//registry.npmjs.org/:_authToken=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

環境変数を使用することもできます。例：

//registry.npmjs.org/:_authToken=${NPM_TOKEN}

または、.npmrcをまったく変更せずに、環境変数を直接使用することもできます。

npm_config_//registry.npmjs.org/:_authToken=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

<URL>:tokenHelper​

トークンヘルパーは、認証トークンを出力する実行可能ファイルです。これは、authTokenが一定の値ではなく、定期的に更新されるもの、スクリプトまたはその他のツールが既存のリフレッシュトークンを使用して新しいアクセストークンを取得できる状況で使用できます。

ヘルパーへのパスの設定は、絶対パスで、引数は指定できません。安全のために、この値はユーザーの.npmrcでのみ設定することを許可しています。そうでなければ、プロジェクトはプロジェクトのローカル.npmrcに値を配置し、任意の実行可能ファイルを実行する可能性があります。

デフォルトレジストリへのトークンヘルパーの設定

tokenHelper=/home/ivan/token-generator

指定されたレジストリへのトークンヘルパーの設定

//registry.corp.com:tokenHelper=/home/ivan/token-generator

リクエスト設定​

ca​

  • デフォルト: npm CA証明書
  • タイプ: 文字列、配列、またはnull

レジストリへのSSL接続で信頼される認証局署名証明書。値はPEM形式（別名「Base-64でエンコードされたX.509（.CER）」）である必要があります。例：

ca="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"

既知のレジストラーのみを許可する場合、または特定のCA証明書のみを信頼する場合にnullに設定します。

複数のCAを信頼するには、証明書の配列を指定します。

ca[]="..."
ca[]="..."

strict-ssl設定も参照してください。

cafile​

  • デフォルト: null
  • タイプ: path

1つ以上の認証局署名証明書を含むファイルへのパス。ca設定に似ていますが、複数のCA、およびCA情報をCLIで指定する代わりにファイルに保存することを許可します。

<URL>:cafile​

指定されたレジストリへのアクセス時に使用する認証局ファイルへのパスを定義します。例：

//registry.npmjs.org/:keyfile=client-cert.pem

cert​

  • デフォルト: null
  • タイプ: 文字列

レジストリへのアクセス時に渡すクライアント証明書。値はPEM形式（別名「Base-64でエンコードされたX.509（.CER）」）である必要があります。例：

cert="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"

証明書ファイルへのパスではありません。

<URL>:certfile​

指定されたレジストリへのアクセス時に使用する証明書ファイルへのパスを定義します。例：

//registry.npmjs.org/:certfile=server-cert.pem

key​

  • デフォルト: null
  • タイプ: 文字列

レジストリへのアクセス時に渡すクライアントキー。値はPEM形式（別名「Base-64でエンコードされたX.509（.CER）」）である必要があります。例：

key="-----BEGIN PRIVATE KEY-----\nXXXX\nXXXX\n-----END PRIVATE KEY-----"

キーファイルへのパスではありません（そしてkeyfileオプションはありません）。

この設定には機密情報が含まれています。リポジトリにコミットされたローカルの.npmrcファイルに書き込まないでください。

<URL>:keyfile​

指定されたレジストリへのアクセス時に使用するクライアントキーファイルへのパスを定義します。例：

//registry.npmjs.org/:keyfile=server-key.pem

git-shallow-hosts​

  • デフォルト: ['github.com', 'gist.github.com', 'gitlab.com', 'bitbucket.com', 'bitbucket.org']
  • タイプ: string[]

Gitリポジトリである依存関係を取得する場合、ホストがこの設定にリストされている場合、pnpmは浅いクローンを使用して必要なコミットのみを取得し、すべての履歴を取得しません。

https-proxy​

  • デフォルト: null
  • タイプ: url

発信HTTPSリクエストに使用するプロキシ。HTTPS_PROXY、https_proxy、HTTP_PROXY、またはhttp_proxy環境変数が設定されている場合、その値が代わりに使用されます。

プロキシURLにユーザー名とパスワードが含まれている場合は、URLエンコードしてください。例：

https-proxy=https://use%21r:pas%2As@my.proxy:1234/foo

ユーザー名とパスワードの間のコロン（:）はエンコードしないでください。

http-proxy​

proxy​

  • デフォルト: null
  • タイプ: url

発信HTTPリクエストに使用するプロキシ。HTTP_PROXYまたはhttp_proxy環境変数が設定されている場合、基になるリクエストライブラリによってプロキシ設定が尊重されます。

local-address​

  • デフォルト: undefined
  • タイプ: IPアドレス

npmレジストリへの接続時に使用するローカルインターフェースのIPアドレス。

maxsockets​

  • デフォルト: network-concurrency x 3
  • タイプ: 数値

オリジン（プロトコル/ホスト/ポートの組み合わせ）ごとに使用する接続の最大数。

noproxy​

  • デフォルト: null
  • タイプ: 文字列

プロキシを使用しないドメイン拡張子のコンマ区切りの文字列。

strict-ssl​

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

HTTPS経由でレジストリへのリクエストを行う際にSSLキー検証を行うかどうか。

caオプションも参照してください。

network-concurrency​

  • デフォルト: 16
  • タイプ: 数値

同時に処理するHTTP（S）リクエストの最大数を制御します。

fetch-retries​

  • デフォルト: 2
  • タイプ: 数値

pnpmがレジストリからフェッチに失敗した場合の再試行回数。

fetch-retry-factor​

  • デフォルト: 10
  • タイプ: 数値

再試行バックオフの指数関数的係数。

fetch-retry-mintimeout​

  • デフォルト: 10000 (10秒)
  • タイプ: 数値

リクエストの再試行における最小（基本）タイムアウトです。

fetch-retry-maxtimeout​

  • デフォルト: 60000 (1分)
  • タイプ: 数値

再試行回数によってリクエスト時間が長くなりすぎるのを防ぐための、最大フォールバックタイムアウトです。

fetch-timeout​

  • デフォルト: 60000 (1分)
  • タイプ: 数値

HTTPリクエストの完了を待つ最大時間です。

ピア依存関係の設定​

auto-install-peers​

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

trueの場合、不足している必須ではないピア依存関係が自動的にインストールされます。

バージョン競合​

異なるパッケージからピア依存関係に競合するバージョン要件がある場合、pnpmは競合するピア依存関係のいずれのバージョンも自動的にインストールしません。代わりに、警告が表示されます。たとえば、ある依存関係がreact@^16.0.0を、別の依存関係がreact@^17.0.0を要求する場合、これらの要件は競合し、自動インストールは行われません。

競合の解決​

バージョン競合が発生した場合、インストールするピア依存関係のバージョンを自分で評価するか、依存関係を更新してピア依存関係の要件を一致させる必要があります。

dedupe-peer-dependents​

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

この設定がtrueに設定されている場合、ピア依存関係を持つパッケージは、ピア解決後に重複排除されます。

たとえば、2つのプロジェクトを含むワークスペースがあり、両方のプロジェクトに依存関係としてwebpackが含まれているとします。webpackはオプションのピア依存関係としてesbuildを持ち、プロジェクトの1つに依存関係としてesbuildが含まれています。この場合、pnpmはnode_modules/.pnpmディレクトリに2つのwebpackのインスタンスをリンクします。1つはesbuildを含むもの、もう1つは含まないものです。

node_modules
  .pnpm
    webpack@1.0.0_esbuild@1.0.0
    webpack@1.0.0
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
    esbuild

これは、webpackが2つのプロジェクトで使用されており、一方のプロジェクトにはesbuildが含まれていないため、2つのプロジェクトが同じwebpackインスタンスを共有できないため、理にかなっています。しかし、これは特にホイスティングされたnode_modulesではwebpackのインスタンスが1つしかないため、多くの開発者が期待するものではありません。そのため、dedupe-peer-dependents設定を使用して、競合するピア依存関係がない場合にwebpackを重複排除できるようになりました（説明は最後）。この場合、dedupe-peer-dependentsをtrueに設定すると、両方のプロジェクトがesbuildが解決された同じwebpackインスタンスを使用します。

node_modules
  .pnpm
    webpack@1.0.0_esbuild@1.0.0
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
    esbuild

競合するピア依存関係とは？ 競合するピア依存関係とは、次のようなシナリオを意味します。

node_modules
  .pnpm
    webpack@1.0.0_react@16.0.0_esbuild@1.0.0
    webpack@1.0.0_react@17.0.0
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack
    react (v17)
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
    esbuild
    react (v16)

この場合、webpackはピア依存関係にreactを持ち、reactが2つのプロジェクトのコンテキストで2つの異なるバージョンから解決されるため、webpackを重複排除できません。

strict-peer-dependencies​

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

これが有効になっている場合、ツリーに欠落しているか無効なピア依存関係があると、コマンドは失敗します。

resolve-peers-from-workspace-root​

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

有効にすると、ルートワークスペースプロジェクトの依存関係を使用して、ワークスペース内の任意のプロジェクトのピア依存関係が解決されます。これは、ピア依存関係をワークスペースのルートのみにインストールでき、ワークスペース内のすべてのプロジェクトが同じバージョンのピア依存関係を使用することを確認できるため、便利な機能です。

CLI設定​

[no-]color​

  • デフォルト: auto
  • タイプ: auto、always、never

出力の色を制御します。

  • auto - 標準出力がターミナルまたはTTYの場合、出力は色を使用します。
  • always - ターミナルとパイプの違いを無視します。これはめったに必要ありません。リダイレクトされた出力にカラーコードが必要なほとんどのシナリオでは、代わりにpnpmコマンドに--colorフラグを渡して、カラーコードを使用するように強制できます。デフォルト設定はほとんどの場合、必要な設定です。
  • never - 色をオフにします。これは--no-colorで使用される設定です。

loglevel​

  • デフォルト: info
  • タイプ: debug、info、warn、error

指定されたレベル以上のログが表示されます。代わりに--silentを渡して、すべての出力ログをオフにすることができます。

use-beta-cli​

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

CLIのベータ機能を有効にする実験的なオプションです。つまり、破壊的な変更や潜在的なバグである可能性のあるCLI機能の変更が発生する可能性があります。

recursive-install​

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

これが有効になっている場合、pnpm installの主要な動作はpnpm install -rと同じになり、すべてのワークスペースまたはサブディレクトリのパッケージでインストールが実行されます。

それ以外の場合は、pnpm installは現在のディレクトリのパッケージのみをビルドします。

engine-strict​

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

これが有効になっている場合、pnpmは現在のNodeバージョンと互換性がないと主張するパッケージをインストールしません。

この設定に関係なく、プロジェクト（依存関係ではない）がそのenginesフィールドに非互換バージョンを指定している場合、インストールは常に失敗します。

npm-path​

  • タイプ: path

pnpmが公開などのアクションに使用できるnpmバイナリの場所です。

ビルド設定​

ignore-scripts​

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

プロジェクトのpackage.jsonとその依存関係で定義されているスクリプトを実行しません。

注記

このフラグは、.pnpmfile.cjsの実行を防ぎません。

ignore-dep-scripts​

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

インストールされたパッケージのスクリプトを実行しません。プロジェクトのスクリプトは実行されます。

child-concurrency​

  • デフォルト: 5
  • タイプ: 数値

node_modulesの構築に同時に割り当てる子プロセスの最大数です。

side-effects-cache​

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

(pre/post)installフックの結果を使用およびキャッシュします。

side-effects-cache-readonly​

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

存在する場合のみ副作用キャッシュを使用し、新しいパッケージに対しては作成しません。

unsafe-perm​

  • デフォルト: rootユーザーとして実行している場合false、それ以外の場合はtrue
  • タイプ: Boolean

パッケージスクリプトを実行するときにUID/GIDの切り替えを有効にするには、trueに設定します。明示的にfalseに設定すると、root以外のユーザーとしてインストールに失敗します。

node-options​

  • デフォルト: NULL
  • タイプ: 文字列

NODE_OPTIONS環境変数を使用してNode.jsに渡すオプションです。これはpnpm自体の実行方法には影響しませんが、ライフサイクルスクリプトの呼び出し方法には影響します。

Node.js設定​

use-node-version​

  • デフォルト: undefined
  • タイプ: semver

プロジェクトのランタイムに使用する正確なNode.jsバージョンを指定します。pnpmは指定されたバージョンのNode.jsを自動的にインストールし、pnpm runコマンドまたはpnpm nodeコマンドの実行に使用します。

これは.nvmrcとnvmの代わりに使用できます。次の.nvmrcファイルの代わりに

16.16.0

この.npmrcファイルを使用します

use-node-version=16.16.0

node-version​

  • デフォルト: node -vによって返される値（vプレフィックスなし）
  • タイプ: semver

パッケージのengines設定をチェックするときに使用するNode.jsバージョンです。

プロジェクトの貢献者が新しい非互換な依存関係を追加するのを防ぎたい場合は、プロジェクトのルートにある.npmrcファイルでnode-versionとengine-strictを使用します。

node-version=12.22.0
engine-strict=true

このようにして、Node.js v16を使用している場合でも、Node.js v12.22.0をサポートしていない新しい依存関係をインストールすることはできません。

node-mirror:​

  • デフォルト: https://node.dokyumento.jp/download//
  • タイプ: URL

Node.jsのダウンロードの基本URLを設定します。この設定の部分は、https://node.dokyumento.jp/downloadの任意のディレクトリ（release、rc、nightly、v8-canaryなど）にすることができます。

中国のNode.jsミラーからNode.jsをダウンロードするようにpnpmを構成する方法を次に示します。

node-mirror:release=https://npmmirror.com/mirrors/node/
node-mirror:rc=https://npmmirror.com/mirrors/node-rc/
node-mirror:nightly=https://npmmirror.com/mirrors/node-nightly/

ワークスペース設定​

link-workspace-packages​

  • デフォルト: false
  • タイプ: true、false、deep

これが有効になっている場合、レジストリからダウンロードする代わりに、ローカルで使用可能なパッケージがnode_modulesにリンクされます。これはモノレポで非常に便利です。ローカルパッケージをサブ依存関係にもリンクする必要がある場合は、deep設定を使用できます。

それ以外の場合は、パッケージがレジストリからダウンロードされ、インストールされます。ただし、workspace:範囲プロトコルを使用して、ワークスペースパッケージをリンクできます。

prefer-workspace-packages​

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

これが有効になっている場合、レジストリに新しいバージョンのパッケージがある場合でも、レジストリのパッケージよりもワークスペースのローカルパッケージが優先されます。

この設定は、ワークスペースがsave-workspace-protocolを使用していない場合にのみ役立ちます。

shared-workspace-lockfile​

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

この設定を有効にすると、pnpmはワークスペースのルートに単一のpnpm-lock.yamlファイルを作成します。これは、ワークスペースパッケージのすべての依存関係が単一のnode_modulesフォルダに配置され（そしてNodeのモジュール解決のためにそれぞれのパッケージのnode_modulesフォルダにシンボリックリンクされます）、という意味でもあります。

このオプションの利点

  • すべての依存関係がシングルトンになる
  • モノレポでのインストールが高速化する
  • すべての変更が1つのファイルにあるため、コードレビューにおける変更が少なくなる
注記

すべての依存関係がルートnode_modulesにハードリンクされる場合でも、パッケージはそれぞれのpackage.jsonで宣言されている依存関係のみにアクセスできるため、pnpmの厳密性は維持されます。これは前述のシンボリックリンクの結果です。

save-workspace-protocol​

  • デフォルト: rolling
  • タイプ: true, false, rolling

この設定は、ワークスペースからリンクされた依存関係がpackage.jsonに追加される方法を制御します。

foo@1.0.0がワークスペースにあり、ワークスペース内の別のプロジェクトでpnpm add fooを実行した場合、fooは依存関係フィールドに以下のようになります。save-prefix設定も、仕様の作成に影響を与えます。

save-workspace-protocolsave-prefixspec
false''1.0.0
false'~'~1.0.0
false'^'^1.0.0
true''workspace:1.0.0
true'~'workspace:~1.0.0
true'^'workspace:^1.0.0
rolling''workspace:*
rolling'~'workspace:~
rolling'^'workspace:^

include-workspace-root​

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

ワークスペースでコマンドを再帰的に実行する場合、ルートワークスペースプロジェクトでも実行します。

ignore-workspace-cycles​

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

trueに設定すると、ワークスペースサイクルの警告は表示されません。

disallow-workspace-cycles​

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

trueに設定すると、ワークスペースにサイクルがある場合、インストールは失敗します。

その他の設定​

use-running-store-server​

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

ストアサーバーでのみインストールを許可します。ストアサーバーが実行されていない場合、インストールは失敗します。

save-prefix​

  • デフォルト: '^'
  • タイプ: '^', '~', ''

package.jsonファイルにインストールされたパッケージのバージョンのプレフィックスを設定します。

例えば、パッケージのバージョンが1.2.3の場合、デフォルトではバージョンは^1.2.3に設定され、そのパッケージのマイナーアップグレードが許可されますが、pnpm config set save-prefix='~' の後では~1.2.3に設定され、パッチアップグレードのみが許可されます。

追加されたパッケージに範囲が指定されている場合、この設定は無視されます。例えば、pnpm add foo@2は、save-prefixの値に関係なく、package.jsonのfooのバージョンを2に設定します。

tag​

  • デフォルト: latest
  • タイプ: 文字列

特定のバージョンを指定せずにパッケージをpnpm addする場合、この設定のタグに登録されているバージョンでパッケージがインストールされます。

明示的なタグが指定されていない場合、これはpnpm tagコマンドで指定されたpackage@versionに追加されるタグも設定します。

global-dir​

  • デフォルト
    • $XDG_DATA_HOME環境変数が設定されている場合、$XDG_DATA_HOME/pnpm/global
    • Windowsの場合: ~/AppData/Local/pnpm/global
    • macOSの場合: ~/Library/pnpm/global
    • Linuxの場合: ~/.local/share/pnpm/global
  • タイプ: path

グローバルパッケージを保存するカスタムディレクトリを指定します。

global-bin-dir​

  • デフォルト
    • $XDG_DATA_HOME環境変数が設定されている場合、$XDG_DATA_HOME/pnpm
    • Windowsの場合: ~/AppData/Local/pnpm
    • macOSの場合: ~/Library/pnpm
    • Linuxの場合: ~/.local/share/pnpm
  • タイプ: path

グローバルにインストールされたパッケージのbinファイルのターゲットディレクトリを設定できます。

state-dir​

  • デフォルト
    • $XDG_STATE_HOME環境変数が設定されている場合、$XDG_STATE_HOME/pnpm
    • Windowsの場合: ~/AppData/Local/pnpm-state
    • macOSの場合: ~/.pnpm-state
    • Linuxの場合: ~/.local/state/pnpm
  • タイプ: path

pnpmがpnpm-state.jsonファイルを作成するディレクトリで、現在アップデートチェッカーによってのみ使用されています。

cache-dir​

  • デフォルト
    • $XDG_CACHE_HOME環境変数が設定されている場合、$XDG_CACHE_HOME/pnpm
    • Windowsの場合: ~/AppData/Local/pnpm-cache
    • macOSの場合: ~/Library/Caches/pnpm
    • Linuxの場合: ~/.cache/pnpm
  • タイプ: path

パッケージメタデータキャッシュの場所です。

use-stderr​

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

trueの場合、すべての出力がstderrに出力されます。

update-notifier​

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

最新バージョンより古いバージョンのpnpmを使用している場合、アップデート通知を抑制するにはfalseに設定します。

prefer-symlinked-executables​

  • デフォルト: node-linkerがhoistedに設定されていて、システムがPOSIXの場合true
  • タイプ: Boolean

コマンドシムの代わりに、node_modules/.binに実行ファイルへのシンボリックリンクを作成します。この設定は、コマンドシムのみが動作するWindowsでは無視されます。

verify-store-integrity​

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

デフォルトでは、ストア内のファイルが変更されている場合、プロジェクトのnode_modulesにリンクする前に、このファイルの内容がチェックされます。verify-store-integrityがfalseに設定されている場合、コンテンツアドレス可能なストア内のファイルはインストール時にチェックされません。

ignore-compatibility-db​

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

インストール時に、一部のパッケージの依存関係は自動的にパッチされます。これを無効にするには、この設定をfalseに設定します。

パッチはYarnの@yarnpkg/extensionsパッケージから適用されます。

resolution-mode​

  • デフォルト: highest (v8.0.0からv8.6.12まではlowest-directでした)
  • タイプ: highest, time-based, lowest-direct

resolution-modeがtime-basedに設定されている場合、依存関係は次のように解決されます。

  1. 直接依存関係は、それらの最低バージョンに解決されます。そのため、依存関係にfoo@^1.1.0がある場合、1.1.0がインストールされます。
  2. サブ依存関係は、最後の直接依存関係が公開される前に公開されたバージョンから解決されます。

この解決モードでは、ウォームキャッシュを使用したインストールが高速になります。また、サブ依存関係は直接依存関係が更新された場合にのみ更新されるため、サブ依存関係ハイジャックの可能性も低くなります。

この解決モードは、npmの完全なメタデータでのみ機能します。そのため、一部のシナリオでは速度が低下します。ただし、Verdaccio v5.15.1以降を使用している場合は、registry-supports-time-field設定をtrueに設定すると、非常に高速になります。

resolution-modeがlowest-directに設定されている場合、直接依存関係はそれらの最低バージョンに解決されます。

registry-supports-time-field​

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

使用しているレジストリが、短縮されたメタデータで"time"フィールドを返す場合、これをtrueに設定します。現在、これに対応しているのはVerdaccio v5.15.1以降のみです。

extend-node-path​

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

falseの場合、コマンドシムではNODE_PATH環境変数は設定されません。

deploy-all-files​

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

パッケージをデプロイする場合、またはローカルパッケージをインストールする場合、パッケージのすべてのファイルがコピーされます。デフォルトでは、パッケージにpackage.jsonに"files"フィールドがある場合、リストされているファイルとディレクトリのみがコピーされます。

dedupe-direct-deps​

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

trueに設定すると、ワークスペースのルートnode_modulesディレクトリに既にシンボリックリンクされている依存関係は、サブプロジェクトのnode_modulesディレクトリにはシンボリックリンクされません。

dedupe-injected-deps​

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

この設定が有効になっている場合、注入された依存関係は可能な限りワークスペースからシンボリックリンクされます。依存プロジェクトと注入された依存関係が同じピア依存関係を参照する場合、注入された依存関係を依存関係のnode_modulesに物理的にコピーする必要はなく、シンボリックリンクで十分です。

package-manager-strict​

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

この設定が無効になっている場合、pnpmは、そのバージョンがpackage.jsonのpackageManagerフィールドで指定されたバージョンと一致しなくても失敗しません。

または、COREPACK_ENABLE_STRICT環境変数を0に設定することもできます。