Version: 7.x

.npmrc

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

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

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

プロジェクトごとの設定ファイル(/path/to/my/project/.npmrc)
ワークスペースごとの設定ファイル (pnpm-workspace.yaml ファイルが含まれているディレクトリー)
ユーザーごとの設定ファイル(~/.npmrc)
グローバルな設定ファイル (/etc/npmrc)

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

依存の巻き上げ設定

hoist

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

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

hoist-pattern

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

どのパッケージを node_modules/.pnpm に巻き上げるかを指定します。デフォルトでは、全てのパッケージが巻き上げられます。しかし、phantom dependency を持つ、扱いに困るパッケージの存在が分かっている場合には、このオプションにより、それらを除外して巻き上げることができます (推奨)。

例：

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

v7.12.0 以降では、! を使用して巻き上げから除外するパターンを指定することもできます。

例：

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

public-hoist-pattern

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

hoist-pattern が仮想ストア内の隠しモジュールディレクトリに依存を巻き上げるのに対し、public-hoist-pattern はパターンにマッチする依存をルートのモジュールディレクトリへと巻き上げます。ルートのモジュールディレクトリへの巻き上げによって、アプリケーションのコードは phantom dependencies へアクセスできるようになります。たとえ依存関係の解決方法が不適切に変更されたとしてもアクセス可能です。

この設定は、依存関係を適切に解決していなくて扱いに困る、プラグイン可能なツールを利用する場合に便利です。

例：

public-hoist-pattern[]=*plugin*

注意： shamefully-hoist を true に設定するのと public-hoist-pattern を * に設定するのは同じ効果があります。

v7.12.0 以降では、! を使用して巻き上げから除外するパターンを指定することもできます。

例：

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

shamefully-hoist

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

デフォルトでは、pnpm はそれなりに厳格な node_modules を作成します。依存パッケージは定義されていない依存パッケージへアクセスできますが、node_modules の外からはアクセスできません。エコシステム内のほとんどのパッケージは、この方法で問題なく動作します。しかし、ルートの node_modules に依存パッケージが巻き上げられていないと動作しないツールがある場合には、この設定を true にすることで巻き上げることができます。

node_modules に関する設定

store-dir

デフォルト:
- If the $PNPM_HOME env variable is set, then $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

パッケージをディスク上のどこに保存するか指定します。

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

異なるディスク上のストアを指定することも可能ですが、その場合 pnpm はハードリンクをせずにパッケージをコピーします。これは、ハードリンクは同一のファイルシステム上でのみ使用可能なためです。

modules-dir

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

(node_modules の代わりに) 依存パッケージをインストールする場所を指定します。

node-linker

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

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

isolated - 依存関係は node_modules/.pnpm の仮想ストアからシンボリックリンクでインストールされます。
hoisted - シンボリックリンクは作成されず、フラットな node_modules が作成されます。 npm や Yarn Classic によって作成される node_modules と同じです。この設定を使用すると、Yarnのライブラリーの 1 つが巻き上げに使用されます。この設定を使用する合理的な理由は以下のとおりです:
1. 使っているツールはシンボリックリンクではうまく機能しない。 React Native のプロジェクトは、おそらく、巻き上げられた(hoisted) node_modulesを使用する場合にのみ機能します。
2. プロジェクトがサーバーレスホスティングにデプロイされる。一部のサーバーレスサービスの提供者 (AWS Lambdaなど) はシンボリックリンクをサポートしていません。この問題を解決する代替策は、デプロイ前にアプリケーションをバンドルすることです。
3. "bundledDependencies" としてパッケージを公開したい場合
4. --preserve-symlinks フラグを指定して Node.js を実行している場合。
pnp - node_modules なし。 Plug'n'Play は Yarn で使用されている Node のための革新的な方式です。 pnp をリンカーとして使う場合には、 symlink を false に設定することが推奨されます。

symlink

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

symlink を false に設定すると、pnpm は仮想ストアのディレクトリをシンボリックリンクを用いずに構成します。この設定は node-linker=pnp と組み合わせる際に役立ちます。

enable-modules-dir

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

false を設定すると、pnpm はモジュールディレクトリ (node_modules) にファイルを一切書き込みません。この設定はユーザスペース上のファイルシステム (FUSE) にモジュールディレクトリがマウントされている場合に有用です。 node_module ディレクトリを FUSE でマウントするのに使える実験的な CLIツールがあります: @pnpm/mount-modules

virtual-store-dir

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

ストアにリンクするディレクトリを指定する。すべてのプロジェクトの直接および間接的な依存はこのディレクトリへリンクされる。

Windows 上でのパスの長さ上限に関する問題を解決するのに役立ちます。何らかの非常に長いパスを持つ依存がある場合、ドライブ上のルートに仮想ストアを置くことが可能です。 (例: C:\my-project-store)

もしくは、仮想ストアを .pnpm にして .gitignore に追記することもできます。依存のディレクトリをひとつ上にすることで、スタックトレース上での表示がすっきりします。

注意: 仮想ストアは複数のプロジェクト間で共有することはできません。すべてのプロジェクトはそれぞれ固有の仮想ストアを持つ必要があります。 (ルートが共通のワークスペース内のプロジェクトは除く)

package-import-method

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

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

auto - ストアからパッケージをクローンしようとします。クローンがサポートされていない場合、ストアからパッケージをハードリンクします。クローンもリンクもできない場合は、コピーします。
hardlink - ストアからパッケージをハードリンクします。
clone-or-copy - ストアからパッケージをクローンしようとします。クローンがサポートされていない場合、コピーにフォールバックします。
copy - ストアからパッケージをコピーします。
clone - ストアからパッケージをクローンします。 (別名: copy-on-write、参照リンク)

クローンはパッケージを node_modules に書き込む最良の方法です。最速かつ最も安全です。クローンを使用している場合、node_modules 内のファイルを編集可能です(編集しても中央ストア側のファイルは変更されません)。

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

情報

macOSはクローンをサポートしていますが、現在Node.jsのバグにより、pnpmでクローンを使うことができません。修正方法のアイディアをお持ちの場合は、ご協力ください。

modules-cache-max-age

デフォルト: 10080 (単位は分、7 日)
タイプ: number

孤立したパッケージを node_module ディレクトリから削除するまでの時間を分単位で指定します。 pnpm はパッケージのキャッシュを node_module ディレクトリに保持します。これにより、ブランチを切り替えたり、依存のダウングレードを行う際のインストールのスピードを速くします。

ロックファイル設定

lockfile

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

false に設定すると、pnpm は pnpm-lock.yaml を読み込んだり、書き込んだりしません。

prefer-frozen-lockfile

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

true に設定すると、pnpm-lock.yaml が存在して、 package.json の依存指定の条件を満たす場合に、ヘッドレスインストールを行います。ヘッドレスインストールでは、lockfile を変更する必要がないため、すべての依存関係の解決がスキップされます。

lockfile-include-tarball-url

追加されたバージョン：v7.6.0

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

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

use-lockfile-v6

追加されたバージョン：v7.24.0

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

新しい v6 ロックファイル形式を使用します。これは pnpm v8 のデフォルトの形式になります。この新しいフォーマットは、ハッシュを使用して長い依存パスを短縮しないため、これまでより読みやすくなっています。

レジストリ & 認証設定

registry

デフォルト: https://registry.npmjs.org/
タイプ: url

npm パッケージレジストリのベースURL (末尾のスラッシュを含める)。

<scope>:registry

特定のスコープのパッケージに対して使うレジストリを指定する。例えば、 @babel:registry=https://example.com/packages/npm/ を設定すると、pnpm add @babel/core やその他の @babel スコープのパッケージをインストールする際に、デフォルトのレジストリの代わりに https://example.com/packages/npm を使うように強制します。

<URL>:_authToken

レジストリにアクセスするときに使用する認証用の Bearer トークンを指定します。例:

//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

tokenHelper とは、アクセストークンを出力する実行ファイルです。これは、authToken が一定値ではなく定期的に更新されるような場合に使用します。スクリプトやその他のツールが、既存のリフレッシュトークンを使って新しいアクセストークンを取得できるようになります。

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

デフォルトのレジストリに tokenHelper を設定します：

tokenHelper=/home/ivan/token-generator

指定されたレジストリに tokenHelper を設定します：

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

リクエスト設定

ca

デフォルト: npm CA 証明書
タイプ: String, Array or null

レジストリへのSSL接続をするのに信用する署名用CA証明書を指定します。値は PEM フォーマット (Base64エンコードされた X.509 (.CER)) で指定します。例:

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

null に設定すると、既知の登録者のみを許可できます。もしくは、特定の CA 証明書の署名のみを信頼するように設定できます。

証明書の配列を指定することで、複数の信頼する CA を指定することもできます。

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

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

cafile

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

ひとつ、もしくは複数のCA 署名用証明書を持つファイルへのパスを指定します。 ca 設定と同様ですが、複数の CA に関する情報を CLI 経由ではなくファイルに保持しておくことができます。

cert

デフォルト: null
タイプ: String

レジストリにアクセスするときに渡すクライアント証明書。値は PEM フォーマット (Base64エンコードされた X.509 (.CER)) で指定します。例:

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

これは証明書ファイルへのパスではありません (certfile オプションはありません)。

key

デフォルト: null
タイプ: String

レジストリにアクセスするときに渡すクライアントキー。値は PEM フォーマット (Base64エンコードされた X.509 (.CER)) で指定します。例:

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

キーファイルへのパスではありません (keyfile オプションはありません)。

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

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 Address

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

maxsockets

デフォルト: network-concurrency x 3
タイプ: Number

origin (protocol/host/port の組み合わせ) ごとに使用する最大接続数です。

noproxy

デフォルト: null
タイプ: String

プロキシーを使わない TLD をコンマ区切りの文字列で指定します。

strict-ssl

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

HTTPS 経由でレジストリにリクエストを送る際にSSL鍵の検証を行うかどうかを指定します。

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

network-concurrency

デフォルト: 16
タイプ: Number

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

fetch-retries

デフォルト: 2
タイプ: Number

pnpm がレジストリからの取得に失敗した際に何回リトライするかを指定する。

fetch-retry-factor

デフォルト: 10
タイプ: Number

再試行間隔の指数関数バックオフ (Exponential Backoff) に使用する係数。

fetch-retry-mintimeout

デフォルト: 10000 (10 秒)
タイプ: Number

リクエストをリトライする際の最小(最初) のタイムアウト。

fetch-retry-maxtimeout

デフォルト: 60000 (1 分)
タイプ: Number

リクエストが長時間リトライされないということがないようにするためのフォールバック用の最大タイムアウト。(訳注: fetch-retry-factor のExponential Backoffによってリトライ間隔は徐々に長くなっていくため、その上限を設ける設定)

fetch-timeout

デフォルト: 60000 (1 分)
タイプ: Number

HTTP リクエストが完了するまでに待つ最大の時間。

Peer Dependency Settings

auto-install-peers

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

true の場合、不足している Optional ではない peer dependencies が自動的にインストールされます。

dedupe-peer-dependents

Added in: v7.29.0

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

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

例えば、2つのプロジェクトを持つワークスペースがあり、どちらもその依存関係に webpack を持っているとしましょう。 webpack はesbuildをオプションの peer dependencies に持ち、2つのうち片方のプロジェクトは依存関係に esbuild を持っている。この場合、 pnpm は webpack の 2 つのインスタンスを node_modules/.pnpm ディレクトリーにリンクします。 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インスタンスを共有することができませんので。しかし、これはほとんどの開発者が期待しているものではありません。特に巻き上げられた(hoisted) node_modulesの場合は、結局webpack のインスタンスが 1 つのみ存在することになるためです。そのため、競合する peer dependencies がないときは、deduupe-peer-dependents 設定を使用して webpack を重複排除することができます(最後に説明します)。この例の場合、 dedupe-peer-dependents を trueに設定すると、両方のプロジェクトが同じ webpack インスタンスを使用し、これは esbuild が解決されています:

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

What are conflicting peer dependencies? By conflicting peer dependencies we mean a scenario like the following one:

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 の peer dependencies に react があり、 react は 2 つのプロジェクトのコンテキストで 2 つの異なるバージョンから解決されるため、 webpack を重複排除できません。

strict-peer-dependencies

Default: false (was true from v7.0.0 until v7.13.5)
タイプ: Boolean

このオプションを有効にすると、依存関係ツリーに欠落していたり無効な peer dependency が存在すると、コマンドが失敗するようになります。

resolve-peers-from-workspace-root

Added in: v7.23.0

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

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

CLI 設定

[no-]color

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

出力時の色を制御する。

auto - 標準出力がターミナルかTTYの場合は、出力に色を使用します。
always - ターミナルとパイプの違いを無視します。これが必要になることはめったにありません。ほとんどの場合では、リダイレクトされた出力にカラーコードを含めたい場合、pnpm コマンドに --colorフラグを指定し、 pnpmコマンドにカラーコードを使用することを強制させることで代用できます。ほとんどの場合デフォルトの設定があなたの求めているものでしょう。
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.js のバージョンと互換性がないパッケージをインストールしません。

このオプションに関わらず、プロジェクト側 (依存側ではない) が互換性のないバージョン指定をengines フィールドで指定している場合は、常にインストールは失敗します。

npm-path

タイプ: path

publish などのいくつかの処理で pnpm が使用する、npm 実行ファイルの場所を指定します。

ビルド設定

ignore-scripts

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

すべてのパッケージ、および依存パッケージで package.json に定義されているスクリプトを実行しません。

メモ

This flag does not prevent the execution of .pnpmfile.cjs

ignore-dep-scripts

Added in: v7.9.0

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

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

child-concurrency

デフォルト: 5
タイプ: Number

node_modules をビルドする際に同時に実行する子プロセスの最大数。

side-effects-cache

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

インストール前後のフック(preinstall/postinstall)の結果をキャッシュします。

side-effects-cache-readonly

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

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

unsafe-perm

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

このオプションを true にすると、パッケージスクリプト実行時の UID/GID の切り替えを有効にします。明示的に false に設定されている場合は、ルート以外のユーザでインストールしようとした場合は失敗します。

Node.js Settings

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 バージョン。

If you want to prevent contributors of your project from adding new incompatible dependencies, use node-version and engine-strict in a .npmrc file at the root of the project:

node-version=12.22.0
engine-strict=true

This way, even if someone is using Node.js v16, they will not be able to install a new dependency that doesn't support Node.js v12.22.0.

node-mirror:<releaseDir>

デフォルト: https://nodejs.org/download/<releaseDir>/
タイプ: URL

Node.jsをダウンロードするためのベースURLを設定します。この設定の <releaseDir> の部分は https://nodejs.org/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

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

If this is enabled, locally available packages are linked to node_modules instead of being downloaded from the registry. This is very convenient in a monorepo. ローカルパッケージも subependencies にリンクさせる必要がある場合は、deep の設定を使用することができます。

Else, packages are downloaded and installed from the registry. However, workspace packages can still be linked by using the workspace: range protocol.

prefer-workspace-packages

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

If this is enabled, local packages from the workspace are preferred over packages from the registry, even if there is a newer version of the package in the registry.

This setting is only useful if the workspace doesn't use save-workspace-protocol.

shared-workspace-lockfile

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

If this is enabled, pnpm creates a single pnpm-lock.yaml file in the root of the workspace. This also means that all dependencies of workspace packages will be in a single node_modules (and get symlinked to their package node_modules folder for Node's module resolution).

Advantages of this option:

各依存の一箇所への設置
より高速なモノレポでのインストール
一箇所にすべて記述され、より少ないコードレビュー時の変更

メモ

たとえルートの node_modules にすべての依存がハードリンクされていても、各ワークスペースパッケージはその package.json に定義された依存にしかアクセスできません。これにより、 pnpm の厳密性は保持されます。これは前述のシンボリックリンクによるものです。

save-workspace-protocol

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

This setting controls how dependencies that are linked from the workspace are added to package.json.

If foo@1.0.0 is in the workspace and you run pnpm add foo in another project of the workspace, below is how foo will be added to the dependencies field. The save-prefix setting also influences how the spec is created.

save-workspace-protocol	save-prefix	spec
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

追加されたバージョン: v7.4.0

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

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

その他の設定

use-running-store-server

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

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

save-prefix

デフォルト: '^'
タイプ: String

パッケージのバージョンが package.json にインストールされる際に、何を接頭辞に付けるか指定します。

例えば、あるパッケージのバージョンが 1.2.3 である場合、デフォルトでは保存されるバージョン指定は ^1.2.3 となり、マイナーアップグレードを許容します。pnpm config set save-prefix='~' を設定すると、~1.2.3 として保存され、パッチアップグレードのみを許容します。

この設定はパッケージがバージョン範囲指定とともに追加された際には無視されます。例えば、 pnpm add foo@2 は package.json 内の foo のバージョンを 2 に設定し、save-prefix の設定値を考慮しません。

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 に設定すると、すべての出力は標準エラーに書き込まれます。

update-notifier

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

falseに設定すると、最新版より古いバージョンのpnpmを使用している場合に、更新通知を行わないようにします。

prefer-symlinked-executables

追加されたバージョン：v7.6.0

デフォルト: true (node-linker が hoisted に設定され、POSIXシステム上である場合)
タイプ: Boolean

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

verify-store-integrity

Added in: v7.7.0

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

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

ignore-compatibility-db

Added in: v7.9.0

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

インストール中に、いくつかのパッケージの依存関係は自動的にパッチされます。これを無効にしたい場合は、この設定を false に設定してください。

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

resolution-mode

Added in: v7.10.0

Default: highest
Type: highest, time-based, lowest-direct (added in: v7.27.0)

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

直接の依存関係は、最も低いバージョンに解決されます。そのため、依存関係に foo@^ 1.1.0 がある場合は、 1.1.0 がインストールされます。
従属依存関係 (訳注: 依存関係の依存関係) は、最後の直接の依存関係がパブリッシュされる前にパブリッシュされたバージョンから解決されます。

この resolution mode では、ウォームキャッシュを使用したインストールが高速になります。また、直接の依存関係が更新された場合にのみ従属依存関係が更新されるため、従属依存関係のハイジャックの可能性も減少します。

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

When resolution-mode is set to lowest-direct, direct dependencies will be resolved to their lowest versions.

registry-supports-time-field

Added in: v7.10.0

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

使用しているレジストリが省略形メタデータ (訳注: abbreviated metadata) の「時刻」フィールドを返す場合、trueを設定します。今のところ、v5.15.1 以降の Verdaccio のみがこれをサポートしています。

extend-node-path

追加されたバージョン：v7.25.0

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

falseの場合、command shims でNODE_PATH環境変数を設定しないようにします。

依存の巻き上げ設定​

hoist​

hoist-pattern​

public-hoist-pattern​

shamefully-hoist​

node_modules に関する設定​

store-dir​

modules-dir​

node-linker​

symlink​

enable-modules-dir​

virtual-store-dir​

package-import-method​

modules-cache-max-age​

ロックファイル設定​

lockfile​

prefer-frozen-lockfile​

lockfile-include-tarball-url​

use-lockfile-v6​

レジストリ & 認証設定​

registry​

<scope>:registry​

<URL>:_authToken​

<URL>:tokenHelper​

リクエスト設定​

ca​

cafile​

cert​

key​

git-shallow-hosts​

https-proxy​

http-proxy​

proxy​

local-address​

maxsockets​

noproxy​

strict-ssl​

network-concurrency​

fetch-retries​

fetch-retry-factor​

fetch-retry-mintimeout​

fetch-retry-maxtimeout​

fetch-timeout​

Peer Dependency Settings​

auto-install-peers​

dedupe-peer-dependents​

strict-peer-dependencies​

resolve-peers-from-workspace-root​

CLI 設定​

[no-]color​

loglevel​

use-beta-cli​

recursive-install​

engine-strict​

npm-path​

ビルド設定​

ignore-scripts​

ignore-dep-scripts​

child-concurrency​

side-effects-cache​

side-effects-cache-readonly​

unsafe-perm​

Node.js Settings​

use-node-version​

node-version​

node-mirror:<releaseDir>​

ワークスペース設定​

link-workspace-packages​

prefer-workspace-packages​

shared-workspace-lockfile​

save-workspace-protocol​

include-workspace-root​

その他の設定​

use-running-store-server​

save-prefix​

tag​

global-dir​

global-bin-dir​

state-dir​

cache-dir​