.npmrc
pnpm 从命令行、环境变量和 .npmrc
文件中获取其配置。
pnpm config
命令可用于更新和编辑 用户和全局 .npmrc
文件的内容。
四个相关文件分别为:
- 每个项目的配置文件(
/path/to/my/project/.npmrc
) - 每个工作区的配置文件(包含
pnpm-workspace.yaml
文件的目录) - 每位用户的配置文件(
~/.npmrc
) - 全局配置文件(
/etc/npmrc
)
所有 .npmrc
文件都遵循 INI-formatted 列表,包含 key = value
参数。
.npmrc
文件中的值可能包含使用 ${NAME}
语法的环境变量。 也可以使用默认值指定环境变量。 运行 ${NAME-fallback}
,如果 NAME
不存在,命令会输出 fallback
。 运行 ${NAME-fallback}
,如果 NAME
不存在或为空,命令会输出 fallback
。
依赖提升设置
hoist
- 默认值: true
- 类型: boolean
当 hoist 为 true
时,所有依赖项都会被提升到 node_modules/.pnpm/node_modules
。 这使得 node_modules
所有包都可以访问 未列出的依赖项。
hoist-workspace-packages
Added in: v8.14.0
- 默认值: false
- 类型: boolean
When true
, packages from the workspaces are symlinked to either <workspace_root>/node_modules/.pnpm/node_modules
or to <workspace_root>/node_modules
depending on other hoisting settings (hoist-pattern
and public-hoist-pattern
).
hoist-pattern
- 默认值: ['*']
- 类型: string[]
告诉 pnpm 哪些包应该被提升到 node_modules/.pnpm/node_modules
。 默认情况下,所有包都被提升 —— 但是,如果您知道只有某些有缺陷的包具有幻影依赖,您可以使用此选项专门提升幻影依赖(推荐做法)。
例如:
hoist-pattern[]=*eslint*
hoist-pattern[]=*babel*
You may also exclude patterns from hoisting using !
.
例如:
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
为 *
是一样的。
You may also exclude patterns from hoisting using !
.
例如:
public-hoist-pattern[]=*types*
public-hoist-pattern[]=!@types/react
shamefully-hoist
- 默认值: false
- 类型:Boolean
默认情况下,pnpm 创建一个半严格的 node_modules
,这意味着依赖项可以访问未声明的依赖项,但 node_modules
之外的模块不行。 通过这种布局,生态系统中的大多数的包都可以正常工作。 但是,如果某些工具仅在提升的依赖项位于根目录的 node_modules
时才有效,您可以将其设置为 true
来为您提升它们。
Node 模块设置
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 包。
- isolated - 依赖项从虚拟存储
node_modules/.pnpm
中建立符号链接 - hoisted - 创建一个没有符号链接的扁平的
node_modules
。 与 npm 或 Yarn Classic 创建node_modules
一致。 当使用此设置时,Yarn 的一个库用于提升。 使用此设置的正当理由:- 您的工具不适用于符号链接。 React Native 项目很可能只有在你使用提升的
node_modules
才能工作。 - 您的项目会被部署到 serverless 服务提供商。 一些 serverless 提供商(例如 AWS Lambda)不支持符号链接。 此问题的另一种解决方案是在部署之前打包您的应用程序。
- 如果你想用
"bundledDependencies"
发布你的包。 - 如果您使用 --preserve-symlinks 标志运行 Node.js。
- 您的工具不适用于符号链接。 React Native 项目很可能只有在你使用提升的
- 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) 中挂载模块目录时很有用。 有一个实验性 CLI 允许您在 FUSE 中挂载模块目录:@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 中的文件,并且不会在中央内容可寻址存储中修改它们。
不幸的是,并非所有文件系统都支持克隆。 我们建议使用写时复制 (CoW) 文件系统(例如,在 Linux 上使用 Btrfs 而不是 Ext4)以获得最佳的 pnpm 体验。
modules-cache-max-age
- 默认值: 10080 (以分钟为单位的 7 天)
- 类型:number
孤立包应该从模块目录中被删除的时间(以分钟为单位)。 pnpm 在模块目录中保存了一个包的缓存。 切换分支或降级依赖项时,这会提高安装速度。
锁文件设置
lockfile
- 默认值: true
- 类型:Boolean
当设置为 false
时,pnpm 不会读取或生成 pnpm-lock.yaml
文件。
prefer-frozen-lockfile
- 默认值: true
- 类型:Boolean
当设置为 true
并且存在 pnpm-lock.yaml
满足 package.json
中的依赖关系时,执行无头安装。 无头安装会跳过所有依赖项解析,因为它不需要修改lockfile。
lockfile-include-tarball-url
- 默认值: false
- 类型:Boolean
将包的 tarball 的完整 URL 添加到 pnpm-lock.yaml
中的每个条目。
git-branch-lockfile
- 默认值: false
- 类型:Boolean
如果设置为 true
,那么在安装后生成的 lockfile 名称将基于当前分支名称命名,以完全避免合并冲突。 例如,如果当前分支名称为 feature-foo
,则 对应的 lockfile 名称将为 pnpm-lock.feature-foo.yaml
而不是 pnpm-lock.yaml
。 It is typically used in conjunction with the command line argument --merge-git-branch-lockfiles
or by setting merge-git-branch-lockfiles-branch-pattern
in the .npmrc
file.
merge-git-branch-lockfiles-branch-pattern
- Default: null
- Type: Array or null
This configuration matches the current branch name to determine whether to merge all git branch lockfile files. By default, you need to manually pass the --merge-git-branch-lockfiles
command line parameter. This configuration allows this process to be automatically completed.
例如:
merge-git-branch-lockfiles-branch-pattern[]=main
merge-git-branch-lockfiles-branch-pattern[]=release*
You may also exclude patterns using !
.
注册源 & 身份验证设置
registry
- 默认值:https://registry.npmjs.org/
- 类型:url
The base URL of the npm package registry (trailing slash included).
<scope>:registry
The npm registry that should be used for packages of the specified scope. For example, setting @babel:registry=https://example.com/packages/npm/
will enforce that when you use pnpm add @babel/core
, or any @babel
scoped package, the package will be fetched from https://example.com/packages/npm
instead of the default registry.
<URL>:_authToken
Define the authentication bearer token to use when accessing the specified registry. 示例:
//registry.npmjs.org/:_authToken=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
You may also use an environment variable. 示例:
//registry.npmjs.org/:_authToken=${NPM_TOKEN}
或者,您可以直接使用环境变量,而不更改 .npmrc
:
npm_config_//registry.npmjs.org/:_authToken=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
<URL>:tokenHelper
A token helper is an executable which outputs an auth token. This can be used in situations where the authToken is not a constant value but is something that refreshes regularly, where a script or other tool can use an existing refresh token to obtain a new access token.
The configuration for the path to the helper must be an absolute path, with no arguments. In order to be secure, it is only permitted to set this value in the user .npmrc
. Otherwise a project could place a value in a project's local .npmrc
and run arbitrary executables.
Setting a token helper for the default registry:
tokenHelper=/home/ivan/token-generator
Setting a token helper for the specified registry:
//registry.corp.com:tokenHelper=/home/ivan/token-generator
请求设置
ca
- 默认值:The npm CA certificate
- 类型:String,Array 或 null
与注册源 SSL 连接时使用的受信任的证书颁发机构签名证书。 值应采用 PEM 格式(AKA “Base-64 encoded X.509 (.CER)”)。 示例:
ca="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"
设置为 null 来仅允许已知注册商,或设置为特定 CA 证书来只信任该特定签名机构。
通过指定一组证书,可以信任多个 CA:
ca[]="..."
ca[]="..."
另请参阅 strict-ssl
配置。
cafile
- Default: null
- 类型:path
包含一个或多个证书颁发机构签名证书的文件的路径。 类似于 ca
设置,但允许多个 CA,以及将 CA 信息存储在文件中,而不是通过 CLI 指定。
cert
- Default: null
- 类型:String
访问注册源时要传递的客户端证书。 值应采用 PEM 格式(AKA “Base-64 encoded X.509 (.CER)”)。 示例:
cert="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"
它不是证书文件的路径(并且没有 certfile
选项)。
key
- Default: null
- 类型:String
访问注册源时传递的客户端密钥。 值应采用 PEM 格式(也称 “Base-64 encoded 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
- Default: null
- 类型:url
用于传出 HTTPS 请求的代理。 如果设置了 HTTPS_PROXY
、 https_proxy
、HTTP_PROXY
或 http_proxy
环境变量,将使用环境变量的值。
If your proxy URL contains a username and password, make sure to URL-encode them. 例如:
https-proxy=https://use%21r:pas%2As@my.proxy:1234/foo
Do not encode the colon (:
) between the username and password.
http-proxy
proxy
- Default: null
- 类型:url
用于传出 HTTP 请求的代理。 如果设置了 HTTP_PROXY 或 http_proxy 环境变量,底层请求库将遵循代理设置。
local-address
- 默认值:undefined
- 类型:**IP Address **
连接到 npm registry 时要使用的本地接口 IP 地址。
maxsockets
- 默认值:network-concurrency x 3
- 类型:Number
每个源(由协议/主机/端口号组合而成)允许的最大连接数。
noproxy
- Default: null
- 类型:String
一个由逗号分割的域名字符串,表示不应该被使用的代理
strict-ssl
- 默认值: true
- 类型:Boolean
通过 HTTPS 向registry发出请求时是否进行 SSL 密钥验证。
另请参阅 ca
配置项。
network-concurrency
- 默认值:16
- 类型:Number
控制同时处理的最大 HTTP(S) 的网络请求数。
fetch-retries
- 默认值:2
- 类型:Number
如果 pnpm 无法从registry中获取,重试次数。
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 设置
auto-install-peers
- 默认值: true
- 类型:Boolean
当值为 true
时,将自动安装任何缺少的非可选同级依赖关系。
Version Conflicts
If there are conflicting version requirements for a peer dependency from different packages, pnpm will not install any version of the conflicting peer dependency automatically. Instead, a warning is printed. For example, if one dependency requires react@^16.0.0
and another requires react@^17.0.0
, these requirements conflict, and no automatic installation will occur.
Conflict Resolution
In case of a version conflict, you'll need to evaluate which version of the peer dependency to install yourself, or update the dependencies to align their peer dependency requirements.
dedupe-peer-dependents
- 默认值: true
- 类型:Boolean
When this setting is set to true
, packages with peer dependencies will be deduplicated after peers resolution.
For instance, let's say we have a workspace with two projects and both of them have webpack
in their dependencies. webpack
has esbuild
in its optional peer dependencies, and one of the projects has esbuild
in its dependencies. In this case, pnpm will link two instances of webpack
to the node_modules/.pnpm
directory: one with esbuild
and another one without it:
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
This makes sense because webpack
is used in two projects, and one of the projects doesn't have esbuild
, so the two projects cannot share the same instance of webpack
. However, this is not what most developers expect, especially since in a hoisted node_modules
, there would only be one instance of webpack
. Therefore, you may now use the dedupe-peer-dependents
setting to deduplicate webpack
when it has no conflicting peer dependencies (explanation at the end). In this case, if we set dedupe-peer-dependents
to true
, both projects will use the same webpack
instance, which is the one that has esbuild
resolved:
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)
In this case, we cannot dedupe webpack
as webpack
has react
in its peer dependencies and react
is resolved from two different versions in the context of the two projects.
strict-peer-dependencies
- 默认值: false
- 类型:Boolean
如果启用了此选项,那么在依赖树中存在缺失或无效的 peer 依赖关系时,命令将执行失败。
resolve-peers-from-workspace-root
- 默认值: true
- 类型:Boolean
启用后,将会使用根工作区项目的 dependencies 解析工作区中任何项目的 peer dependencies 。 这是一个有用的功能,因为你可以只在工作区的根目录中安装 peer dependencies,并且确保工作区中的所有项目都使用相同版本的 peer dependencies 。
命令行设置
[no-]color
- 默认值:auto
- 类型:auto, always, never
设置输出的颜色.
- auto - 当标准输出是终端或 TTY 时,输出会带有颜色。
- always - 忽略终端和 pipe 之间的区别。 你很少需要这个选项; 在大多数情况下,如果您想在重定向的输出中使用颜色代码,您可以将
--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 版本不兼容的包。
但无论该属性设置成什么值,如果项目(不是依赖项)在其 engines
字段中指定了不兼容的版本,则安装将始终失败。
npm-path
- 类型:path
Pnpm 用于某些操作(例如发布)的 npm 的二进制文件的位置。
构建设置
ignore-scripts
- 默认值: false
- 类型:Boolean
不执行项目的 package.json
及其依赖定义的任何脚本。
该标记不会阻止.pnpmfile.cjs 的执行
ignore-dep-scripts
- 默认值: false
- 类型:Boolean
不执行已安装的包的任何脚本。 当前项目的 scripts 会执行
child-concurrency
- 默认值: 5
- 类型:Number
同时分配的最大子进程数以构建 node_modules。
side-effects-cache
- 默认值: true
- 类型:Boolean
使用且缓存 (pre/post)install 钩子的结果。
side-effects-cache-readonly
- 默认值: false
- 类型:Boolean
仅在存在 side effects cache 时使用,不要为新包创建它。
unsafe-perm
- 默认值:true, 如果以 root 身份运行则为 false