.npmrc
pnpm は、コマンド行、環境変数、および .npmrc
ファイルから設定を取得します。
pnpm config
コマンドを使用して、ユーザーおよびグローバルの .npmrc
ファイルの内容を更新および編集することができます。
関連する4つのファイルは次のとおりです。
- プロジェクトごとの設定ファイル(
/path/to/my/project/.npmrc
) - ワークスペースごとの設定ファイル (
pnpm-workspace.yaml
ファイルが含まれているディレクトリー) - ユーザーごとの設定ファイル(
~/.npmrc
) - グローバルな設定ファイル (
/etc/npmrc
)
.npmrc
ファイルはすべて key = value
という INI形式 のパラメータのリストです。
.npmrc
ファイルの値には、 ${NAME}
構文を使用して環境変数を含めることができます。 また、 環境変数はデフォルト値と共に指定することもできます。 ${NAME-fallback}
は、 NAME
が設定されていない場合、fallback
を返します。 ${NAME:-fallback}
はNAME
が設定されていないか空文字の場合に、fallback
を返します。
依存の巻き上げ設定
hoist
- デフォルト: true
- タイプ: boolean
true
の場合、すべての依存関係は node_modules/.pnpm/node_modules
に巻き上げられます。 これにより、リストされていない依存に、 node_modules
内のすべてのパッケージからアクセスできるようになります。
hoist-pattern
- デフォルト: ['*']
- タイプ: string[]
どのパッケージを node_modules/.pnpm/node_modules
に巻き上げるかを指定します。 デフォルトでは、全てのパッケージが巻き上げられます。しかし、phantom dependency を持つ、扱いに困るパッケージの存在が分かっている場合には、このオプションにより、それらを除外して巻き上げることができます (推奨)。
例:
hoist-pattern[]=*eslint*
hoist-pattern[]=*babel*
!
を使用して巻き上げから除外するパターンを指定することもできます。
例:
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
を *
に設定するのは同じ効果があります。
!
を使用して巻き上げから除外するパターンを指定することもできます。
例:
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
- デフォルト:
- $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
パッケージをディスク上のどこに保存するか指定します。
ストアはインストールを行うのと同じディスク状にある必要があります。つまり、ディスクごとに一つのストアを持つことになります。 現在のディスクにホームディレクトリがある場合は、その中にストアが作成されます。 ディスク上にホームディレクトリがない場合は、ストアはファイルシステムのルートに作られます。 例えば、/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 つが巻き上げに使用されます。 この設定を使用する合理的な理由は以下のとおりです:- 使っているツールはシンボリックリンクではうまく機能しない。 React Native のプロジェクトは、おそらく、巻き上げられた(hoisted)
node_modules
を使用する場合にのみ機能します。 - プロジェクトがサーバーレスホスティングにデプロイされる。 一部のサーバーレスサービスの提供者 (AWS Lambdaなど) はシンボリックリンクをサポートしていません。 この問題を解決する代替策は、デプロイ前にアプリケーションをバンドルすることです。
"bundledDependencies"
としてパッケージを公開したい場合- --preserve-symlinks フラグを指定して Node.js を実行している場合。
- 使っているツールはシンボリックリンクではうまく機能しない。 React Native のプロジェクトは、おそらく、巻き上げられた(hoisted)
- 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-include-tarball-url
- デフォルト: false
- タイプ: Boolean
pnpm-lock.yaml
のすべてのエントリに、パッケージの tarball への完全な URL を追加します。
レジストリ & 認証設定
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
指数関数バックオフに使用する係数を指定する。
fetch-retry-mintimeout
- デフォルト: 10000 (10 秒)
- タイプ: Number
リクエストをリトライする際の最小(最初) のタイムアウト。
fetch-retry-maxtimeout
- デフォルト: 60000 (1 分)
- タイプ: Number
リクエストが長時間リトライされないということがないようにするためのフォールバック用の最大タイムアウト。
fetch-timeout
- デフォルト: 60000 (1 分)
- タイプ: Number
HTTP リクエストが完了するまでに待つ最大の時間。
Peer Dependency Settings
auto-install-peers
- デフォルト: true
- タイプ: Boolean
true
の場合、不足している Optional ではないピアの依存関係が自動的にインストールされます。
dedupe-peer-dependents
- デフォルト: true
- タイプ: 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
競合する peer dependencies とは何か? 競合する peer dependencies とは、次のようなシナリオを意味します:
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
- デフォルト: false
- タイプ: Boolean
このオプションを有効にすると、コマンドを実行した際に欠落していたり無効な peer dependency が存在すると失敗します。
resolve-peers-from-workspace-root
- デフォルト: true
- タイプ: 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
- デフォルト: 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
このオプションを有効にすると、ローカルで利用可能なパッケージはレジストリからダウンロードせずに node_modules
へとリンクされます。 これはモノレポで非常に役立ちます。 ローカルパッケージも subependencies にリンクさせる必要がある場合は、deep
の設定を使用することができます。
それ以外の場合には、依存はレジストリからダウンロードされます。 ただし、ワークスペースのパッケージは workspace:
プロトコルを範囲指定することでリンクすることができます。
prefer-workspace-packages
- デフォルト: false
- タイプ: Boolean
このオプションを有効にすると、レジストリに新しいバージョンのパッケージがある場合でも、ワークスペース内のローカルにあるパッケージが優先されます。
この設定は、ワークスペースのオプションで save-workspace-protocol
が使用されていない場合にのみ役立ちます。
shared-workspace-lockfile
- デフォルト: true
- タイプ: Boolean
このオプションが有効になっている場合、pnpm はワークスペースのルートの pnpm-lock.yaml
のみを作成します。 これにより、すべてのワークスペースの依存がワークスペースのルートの node_modules
この一箇所に集められます。(そして各パッケージの node_modules
ディレクトリへとシンボリックリンクが作成されます。)
このオプションの利点:
- 各依存の一箇所への設置
- より高速なモノレポでのインストール
- 一箇所にすべて記述され、より少ないコードレビュー時の変更
たとえルートの node_modules
にすべての依存がハードリンクされていても、各ワークスペースパッケージはその package.json
に定義された依存にしかアクセスできません。これにより、 pnpm の厳密性は保持されます。 これは前述のシンボリックリンクによるものです。
save-workspace-protocol
- Default: rolling
- タイプ: 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
- デフォルト: false
- タイプ: Boolean
コマンドをワークスペースで再帰的に実行する時に、ルートワークスペースプロジェクトでも実行します。
ignore-workspace-cycles
追加されたバージョン:v8.1.0
- デフォルト: false
- タイプ: Boolean
true
に設定すると、ワークスペースの循環参照警告は出力されません。
その他の設定
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
の設定値を考慮しません。
tag
- デフォルト: latest
- タイプ: String
パッケージを 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 に設定すると、すべての出力は標準エラーに書き込まれます。
update-notifier
- デフォルト: true
- タイプ: Boolean
false
に設定すると、最新版より古いバージョンのpnpmを使用している場合に、更新通知を行わないようにします。
prefer-symlinked-executables
- デフォルト: true (node-linker が hoisted に設定され、POSIXシステム上である場合)
- タイプ: Boolean
command shim の代わりに実行行可能ファイルへのシンボリックリンクをnode_modules/.bin
に作成します。 この設定は、command shim のみが機能するWindowsでは無視されます。
verify-store-integrity
- デフォルト: true
- タイプ: Boolean
デフォルトでは、ストア内のファイルが変更されている場合、プロジェクトの node_modules
にリンクする前に、そのファイルの内容がチェックされます。 verify-store-integrity
が false
に設定されている場合、コンテンツアドレス可能ストア内のファイルはインストール中にチェックされません。
ignore-compatibility-db
- デフォルト: false
- タイプ: Boolean
インストール中に、いくつかのパッケージの依存関係は自動的にパッチされます。 これを無効にしたい場合は、この設定を false
に設定してください。
パッチは Yarn の @yarnpkg/extensions
パッケージから適用されます。
resolution-mode
- Default: lowest-direct
- タイプ: highest, time-based, lowest-direct
resolution-mode
が time-based
に設定されている場合、依存関係は次の流れで解決されます。
- 直接の依存関係は、最も低いバージョンに解決されます。 そのため、依存関係に
foo@^ 1.1.0
がある場合は、1.1.0
がインストールされます。 - 従属依存関係 (訳注: 依存関係の依存関係) は、最後の直接の依存関係がパブリッシュされる前にパブリッシュされたバージョンから解決されます。
この resolution mode では、ウォーム キャッシュを使用したインストールが高速になります。 また、直接の依存関係が更新された場合にのみ従属依存関係が更新されるため、従属依存関係のハイジャックの可能性も減少します。
この解決モードは、npm の 完全なメタデータ がある場合のみ機能します。 そのため、一部のシナリオでは遅くなります。 ただし、 Verdaccio v5.15.1 以降を使用する場合は、 registry-supports-time-field
設定を true
に設定すると、本当に高速になります。
resolution-mode
が lowest-direct
に設定されている場合、直接の依存関係は最も低いバージョンに解決されます。
registry-supports-time-field
- デフォルト: false
- タイプ: Boolean
使用しているレジストリが省略形メタデータ (訳注: abbreviated metadata) の「時刻」フィールドを返す場合、true
を設定します。 今のところ、v5.15.1 以降の Verdaccio のみがこれをサポートしています。
extend-node-path
- デフォルト: true
- タイプ: Boolean
false
の場合、command shims でNODE_PATH
環境変数を設定しないようにします。
deploy-all-files
- デフォルト: false
- タイプ: Boolean
パッケージをデプロイする場合、またはローカルパッケージをインストールする場合は、パッケージのすべてのファイルがコピーされます。 デフォルトでは、パッケージの package.json
に "files"
フィールドがある場合、リストされたファイルとディレクトリのみがコピーされます。
dedupe-direct-deps
追加されたバージョン:v8.1.0
- デフォルト: false
- タイプ: Boolean
true
に設定すると、ワークスペースのルートの node_modules
ディレクトリに既にシンボリックリンクされている依存関係は、サブプロジェクトの node_modules
ディレクトリにシンボリックリンクされません。