跳至主要内容
版本: 9.x

.npmrc

pnpm 从命令行、环境变量和 .npmrc 文件获取其配置。

pnpm config 命令可用于更新和编辑用户和全局 .npmrc 文件的内容。

四个相关文件是

  • 每个项目配置文件 (/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。

依赖项提升设置​

提升​

  • 默认: true
  • 类型: 布尔值

当 true 时，所有依赖项都会提升到 node_modules/.pnpm/node_modules。这使得未列出的依赖项可供 node_modules 中的所有包访问。

提升工作区包​

  • 默认: true
  • 类型: 布尔值

当 true 时，工作区中的包将被符号链接到 <workspace_root>/node_modules/.pnpm/node_modules 或 <workspace_root>/node_modules，具体取决于其他提升设置 (hoist-pattern 和 public-hoist-pattern)。

提升模式​

  • 默认: ['*']
  • 类型: 字符串[]

告诉 pnpm 哪些包应该提升到 node_modules/.pnpm/node_modules。默认情况下，所有包都会被提升 - 但是，如果您知道只有某些有缺陷的包具有虚假依赖项，您可以使用此选项来专门提升虚假依赖项 (推荐)。

例如

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

您也可以使用 ! 从提升中排除模式。

例如

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

公共提升模式​

  • 默认: ['*eslint*', '*prettier*']
  • 类型: 字符串[]

与 hoist-pattern 不同，hoist-pattern 将依赖项提升到虚拟存储中的隐藏模块目录，public-hoist-pattern 将匹配模式的依赖项提升到根模块目录。提升到根模块目录意味着应用程序代码将能够访问虚假依赖项，即使它们不正确地修改了解决方案策略。

此设置在处理某些有缺陷的可插拔工具时很有用，这些工具无法正确解析依赖项。

例如

public-hoist-pattern[]=*plugin*

注意: 将 shamefully-hoist 设置为 true 等同于将 public-hoist-pattern 设置为 *。

您也可以使用 ! 从提升中排除模式。

例如

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

可耻地提升​

  • 默认: false
  • 类型: 布尔值

默认情况下，pnpm 创建一个半严格的 node_modules，这意味着依赖项可以访问未声明的依赖项，但 node_modules 之外的模块则不能。使用此布局，生态系统中的大多数包都能正常工作。但是，如果某些工具仅在提升的依赖项位于 node_modules 的根目录时才有效，您可以将其设置为 true 来为您提升它们。

Node-Modules 设置​

存储目录​

  • 默认
    • 如果设置了 $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
  • 类型: 路径

所有包在磁盘上保存的位置。

存储应始终位于与安装发生相同的磁盘上，因此每个磁盘将有一个存储。如果当前磁盘上存在主目录，则存储将在其中创建。如果磁盘上没有主目录，则存储将在文件系统的根目录处创建。例如，如果安装发生在挂载到 /mnt 的文件系统上，则存储将在 /mnt/.pnpm-store 处创建。Windows 系统也是如此。

可以从不同的磁盘设置存储，但在这种情况下，pnpm 将从存储中复制包，而不是硬链接它们，因为硬链接只能在同一个文件系统上进行。

模块目录​

  • 默认: node_modules
  • 类型: 路径

将安装依赖项的目录 (而不是 node_modules)。

节点链接器​

  • 默认: isolated
  • 类型: isolated, hoisted, pnp

定义应使用什么链接器来安装 Node 包。

  • isolated - 依赖项从 node_modules/.pnpm 处的虚拟存储中符号链接。
  • hoisted - 创建一个没有符号链接的扁平 node_modules。与 npm 或 Yarn Classic 创建的 node_modules 相同。当使用此设置时，将使用 Yarn 的一个库来进行提升。使用此设置的正当理由
    1. 您的工具无法很好地与符号链接配合使用。React Native 项目很可能只有在您使用提升的 node_modules 时才能正常工作。
    2. 您的项目部署到无服务器托管提供商。一些无服务器提供商 (例如 AWS Lambda) 不支持符号链接。解决此问题的另一种方法是在部署之前捆绑您的应用程序。
    3. 如果您想使用 "bundledDependencies" 发布您的包。
    4. 如果您使用 --preserve-symlinks 标志运行 Node.js。
  • pnp - 没有 node_modules。Plug'n'Play 是一种针对 Node 的创新策略，由 Yarn Berry 使用。建议在使用 pnp 作为您的链接器时，也将 symlink 设置设置为 false。

符号链接​

  • 默认: true
  • 类型: 布尔值

当 symlink 设置为 false 时，pnpm 会创建一个没有符号链接的虚拟存储目录。它与 node-linker=pnp 一起使用是一个有用的设置。

启用模块目录​

  • 默认: true
  • 类型: 布尔值

当 false 时，pnpm 不会向模块目录 (node_modules) 写入任何文件。这在模块目录使用用户空间文件系统 (FUSE) 挂载时很有用。有一个实验性的 CLI 允许您使用 FUSE 挂载模块目录: @pnpm/mount-modules.

虚拟存储目录​

  • 默认: node_modules/.pnpm
  • 类型: 路径

包含指向存储的链接的目录。项目的直接和间接依赖项都链接到此目录。

这是一个有用的设置，可以解决 Windows 上的路径过长问题。如果您有一些路径很长的依赖项，您可以选择驱动器根目录中的虚拟存储 (例如 C:\my-project-store)。

或者，您可以将虚拟存储设置为 .pnpm 并将其添加到 .gitignore。这将使堆栈跟踪更清晰，因为依赖项的路径将高出一级目录。

注意: 虚拟存储不能在多个项目之间共享。每个项目都应该有自己的虚拟存储 (除了工作区，工作区的根目录是共享的)。

包导入方法​

  • 默认: auto
  • 类型: auto, hardlink, copy, clone, clone-or-copy

控制从存储中导入包的方式 (如果您想禁用 node_modules 中的符号链接，那么您需要更改 node-linker 设置，而不是这个设置)。

  • auto - 尝试从存储中克隆包。如果克隆不受支持，则从存储中硬链接包。如果克隆和链接都不可能，则回退到复制
  • hardlink - 从存储中硬链接包
  • clone-or-copy - 尝试从存储中克隆包。如果克隆不受支持，则回退到复制
  • copy - 从存储中复制包
  • clone - 克隆 (也称为写时复制或引用链接) 包从存储中

克隆是将包写入 node_modules 的最佳方式。它是最快也是最安全的方式。当使用克隆时，您可以编辑 node_modules 中的文件，它们不会在中央内容寻址存储中被修改。

不幸的是，并非所有文件系统都支持克隆。我们建议使用写时复制 (CoW) 文件系统 (例如，在 Linux 上使用 Btrfs 而不是 Ext4) 以获得最佳的 pnpm 体验。

模块缓存最大年龄​

  • 默认: 10080 (7 天，以分钟为单位)
  • 类型: 数字

模块目录中孤儿包应被删除的时间 (以分钟为单位)。pnpm 在模块目录中保留一个包缓存。这在切换分支或降级依赖项时会提高安装速度。

锁定文件设置​

锁定文件​

  • 默认: true
  • 类型: 布尔值

当设置为 false 时，pnpm 不会读取或生成 pnpm-lock.yaml 文件。

首选冻结锁定文件​

  • 默认: true
  • 类型: 布尔值

当设置为 true 且可用的 pnpm-lock.yaml 满足 package.json 依赖项指令时，将执行无头安装。无头安装跳过所有依赖项解析，因为它不需要修改 lockfile。

lockfile-include-tarball-url​

  • 默认: false
  • 类型: 布尔值

将完整 URL 添加到 pnpm-lock.yaml 中每个条目中的包的 tarball。

git-branch-lockfile​

  • 默认: false
  • 类型: 布尔值

当设置为 true 时，安装后生成的 lockfile 名称将根据当前分支名称命名，以完全避免合并冲突。例如，如果当前分支名称为 feature-foo，则相应的 lockfile 名称将为 pnpm-lock.feature-foo.yaml 而不是 pnpm-lock.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（包括尾部斜杠）。

<scope>: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​

令牌助手是一个可执行文件，它输出身份验证令牌。这可以在身份验证令牌不是恒定值而是定期刷新的情况下使用，在这种情况下，脚本或其他工具可以使用现有的刷新令牌来获取新的访问令牌。

助手路径的配置必须是绝对路径，没有参数。为了安全起见，只允许在用户 .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-----"

设置为 null 以仅允许已知注册商，或设置为特定 CA 证书以仅信任该特定签名机构。

可以通过指定证书数组来信任多个 CA

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

另请参阅 strict-ssl 配置。

cafile​

  • 默认值：null
  • 类型: 路径

包含一个或多个证书颁发机构签名证书的文件的路径。类似于 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']
  • 类型: 字符串[]

当获取是 Git 存储库的依赖项时，如果主机列在此设置中，pnpm 将使用浅克隆来仅获取所需的提交，而不是所有历史记录。

https-proxy​

  • 默认值：null
  • 类型：url

用于传出 HTTPS 请求的代理。如果设置了 HTTPS_PROXY、https_proxy、HTTP_PROXY 或 http_proxy 环境变量，则将使用它们的值。

如果您的代理 URL 包含用户名和密码，请确保对它们进行 URL 编码。例如

https-proxy=https://use%21r:pas%[email protected]:1234/foo

不要对用户名和密码之间的冒号 (:) 进行编码。

http-proxy​

proxy​

  • 默认值：null
  • 类型：url

用于传出 http 请求的代理。如果设置了 HTTP_PROXY 或 http_proxy 环境变量，则底层请求库将遵守代理设置。

local-address​

  • 默认值：未定义
  • 类型：IP 地址

连接到 npm 注册表时要使用的本地接口的 IP 地址。

maxsockets​

  • 默认值：网络并发度 x 3
  • 类型：数字

每个来源（协议/主机/端口组合）要使用的最大连接数。

noproxy​

  • 默认值：null
  • 类型：字符串

一个逗号分隔的域名扩展字符串，代理不应该用于这些扩展名。

strict-ssl​

  • 默认: true
  • 类型: 布尔值

是否在通过 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
  • 类型: 布尔值

当 true 时，任何缺少的非可选对等依赖项都会自动安装。

版本冲突​

如果不同包的对等依赖项存在冲突的版本要求，pnpm 不会自动安装任何版本的冲突对等依赖项。相反，将打印警告。例如，如果一个依赖项需要 react@^16.0.0，而另一个依赖项需要 react@^17.0.0，则这些要求会冲突，并且不会发生任何自动安装。

冲突解决​

如果发生版本冲突，您需要评估要自己安装的对等依赖项的版本，或者更新依赖项以使其对等依赖项要求一致。

dedupe-peer-dependents​

  • 默认: true
  • 类型: 布尔值

当此设置设置为 true 时，具有对等依赖项的包将在对等项解析后进行重复数据删除。

例如，假设我们有一个工作区，其中包含两个项目，并且它们都将其依赖项中的 webpack。webpack 在其可选对等依赖项中具有 esbuild，并且其中一个项目在其依赖项中具有 esbuild。在这种情况下，pnpm 将链接 webpack 的两个实例到 node_modules/.pnpm 目录：一个带有 esbuild，另一个没有。

node_modules
  .pnpm
    [email protected][email protected]
    [email protected]
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/[email protected]/node_modules/webpack
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/[email protected][email protected]/node_modules/webpack
    esbuild

这是有道理的，因为 webpack 用于两个项目，并且其中一个项目没有 esbuild，因此这两个项目无法共享 webpack 的同一个实例。但是，这不是大多数开发人员所期望的，尤其是因为在提升的 node_modules 中，只有一个 webpack 实例。因此，您现在可以使用 dedupe-peer-dependents 设置在 webpack 没有冲突的对等依赖项时对其进行重复数据删除（解释在最后）。在这种情况下，如果我们将 dedupe-peer-dependents 设置为 true，则这两个项目将使用同一个 webpack 实例，即已解析 esbuild 的实例。

node_modules
  .pnpm
    [email protected][email protected]
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/[email protected][email protected]/node_modules/webpack
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/[email protected][email protected]/node_modules/webpack
    esbuild

什么是冲突的对等依赖项？ 冲突的对等依赖项是指以下情况

node_modules
  .pnpm
    [email protected][email protected][email protected]
    [email protected][email protected]
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/[email protected]/node_modules/webpack
    react (v17)
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/[email protected][email protected]/node_modules/webpack
    esbuild
    react (v16)

在这种情况下，我们无法对 webpack 进行重复数据删除，因为 webpack 在其对等依赖项中具有 react，并且 react 在两个项目的上下文中从两个不同的版本解析。

strict-peer-dependencies​

  • 默认: false
  • 类型: 布尔值

如果启用此选项，则在依赖树中存在缺失或无效的 peer 依赖项时，命令将失败。

resolve-peers-from-workspace-root​

  • 默认: true
  • 类型: 布尔值

启用此选项后，将使用根工作区项目的依赖项来解析工作区中任何项目的 peer 依赖项。这是一个有用的功能，因为您只需在工作区的根目录中安装 peer 依赖项，并且可以确保工作区中的所有项目都使用相同版本的 peer 依赖项。

CLI 设置​

[no-]color​

  • 默认: auto
  • 类型：auto、always、never

控制输出中的颜色。

  • auto - 当标准输出是终端或 TTY 时，输出使用颜色。
  • always - 忽略终端和管道之间的差异。您很少需要这样做；在大多数情况下，如果您希望在重定向的输出中使用颜色代码，则可以改为将 --color 标志传递给 pnpm 命令以强制其使用颜色代码。默认设置几乎总是您想要的。
  • never - 关闭颜色。这是 --no-color 使用的设置。

loglevel​

  • 默认值：info
  • 类型：debug、info、warn、error

将显示所有级别等于或高于给定级别的日志。您也可以传递 --silent 来关闭所有输出日志。

use-beta-cli​

  • 默认: false
  • 类型: 布尔值

启用 CLI 的 beta 功能的实验性选项。这意味着您可能会获得一些对 CLI 功能的更改，这些更改是重大更改，或者可能是错误。

recursive-install​

  • 默认: true
  • 类型: 布尔值

如果启用此选项，pnpm install 的主要行为将变为 pnpm install -r，这意味着安装将在所有工作区或子目录包上执行。

否则，pnpm install 将专门构建当前目录中的包。

engine-strict​

  • 默认: false
  • 类型: 布尔值

如果启用此选项，pnpm 将不会安装任何声称与当前 Node 版本不兼容的包。

无论此配置如何，如果项目（而不是依赖项）在其 engines 字段中指定了不兼容的版本，安装将始终失败。

npm-path​

  • 类型: 路径

pnpm 用于某些操作（如发布）的 npm 二进制文件的路径。

构建设置​

ignore-scripts​

  • 默认: false
  • 类型: 布尔值

不要执行项目 package.json 及其依赖项中定义的任何脚本。

注意

此标志不会阻止 .pnpmfile.cjs 的执行。

ignore-dep-scripts​

  • 默认: false
  • 类型: 布尔值

不要执行已安装包的任何脚本。项目脚本将被执行。

child-concurrency​

  • 默认值：5
  • 类型：数字

同时分配给构建 node_modules 的子进程的最大数量。

side-effects-cache​

  • 默认: true
  • 类型: 布尔值

使用并缓存 (pre/post)install 钩子的结果。

side-effects-cache-readonly​

  • 默认: false
  • 类型: 布尔值

仅在存在时使用副作用缓存，不要为新包创建它。

unsafe-perm​

  • 默认值：如果以 root 身份运行，则为 false，否则为 true
  • 类型: 布尔值

设置为 true 以在运行包脚本时启用 UID/GID 切换。如果显式设置为 false，则以非 root 用户身份安装将失败。

node-options​

  • 默认值：NULL
  • 类型：字符串

通过 NODE_OPTIONS 环境变量传递给 Node.js 的选项。这不会影响 pnpm 本身的执行方式，但会影响生命周期脚本的调用方式。

Node.js 设置​

use-node-version​

  • 默认值：未定义
  • 类型：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:<releaseDir>​

  • 默认值：https://node.org.cn/download/<releaseDir>/
  • 类型：URL

设置下载 Node.js 的基本 URL。此设置的 <releaseDir> 部分可以是 https://node.org.cn/download 中的任何目录：release、rc、nightly、v8-canary 等。

以下是 pnpm 如何配置从中国的 Node.js 镜像下载 Node.js 的方法

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
  • 类型: 布尔值

如果启用此选项，工作区中的本地包将优先于注册表中的包，即使注册表中存在该包的更新版本也是如此。

此设置仅在工作区不使用 save-workspace-protocol 时才有用。

shared-workspace-lockfile​

  • 默认: true
  • 类型: 布尔值

如果启用此选项，pnpm 将在工作区的根目录中创建一个 pnpm-lock.yaml 文件。这也意味着工作区包的所有依赖项都将在单个 node_modules 中（并被符号链接到其包 node_modules 文件夹以供 Node 的模块解析使用）。

此选项的优点

  • 每个依赖项都是一个单例
  • 在单仓库中更快地安装
  • 代码审查中的更改更少，因为它们都在一个文件中
注意

即使所有依赖项都将硬链接到根 node_modules，包也只能够访问其 package.json 中声明的那些依赖项，因此 pnpm 的严格性得以保留。这是由于上述符号链接的结果。

save-workspace-protocol​

  • 默认值：rolling
  • 类型：true、false、rolling

此设置控制如何将从工作区链接的依赖项添加到 package.json。

如果 [email protected] 位于工作区中，并且您在工作区的另一个项目中运行 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
  • 类型: 布尔值

在工作区中递归执行命令时，也在根工作区项目上执行它们。

ignore-workspace-cycles​

  • 默认: false
  • 类型: 布尔值

设置为 true 时，不会打印任何工作区循环警告。

disallow-workspace-cycles​

  • 默认: false
  • 类型: 布尔值

设置为 true 时，如果工作区存在循环，安装将失败。

其他设置​

use-running-store-server​

  • 默认: false
  • 类型: 布尔值

仅允许使用存储服务器进行安装。如果没有存储服务器正在运行，安装将失败。

save-prefix​

  • 默认值：'^'
  • 类型：'^'、'~'、''

配置如何为安装到 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
  • 类型：字符串

如果您 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
  • 类型: 路径

指定一个自定义目录来存储全局包。

global-bin-dir​

  • 默认
    • 如果设置了$XDG_DATA_HOME 环境变量，则为$XDG_DATA_HOME/pnpm
    • 在 Windows 上：~/AppData/Local/pnpm
    • 在 macOS 上：~/Library/pnpm
    • 在 Linux 上：~/.local/share/pnpm
  • 类型: 路径

允许设置全局安装包的 bin 文件的目标目录。

state-dir​

  • 默认
    • 如果设置了$XDG_STATE_HOME 环境变量，则为$XDG_STATE_HOME/pnpm
    • 在 Windows 上：~/AppData/Local/pnpm-state
    • 在 macOS 上：~/.pnpm-state
    • 在 Linux 上：~/.local/state/pnpm
  • 类型: 路径

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
  • 类型: 路径

包元数据缓存的位置。

use-stderr​

  • 默认: false
  • 类型: 布尔值

当为 true 时，所有输出都写入 stderr。

update-notifier​

  • 默认: true
  • 类型: 布尔值

设置为 false 以在使用比最新版本更旧的 pnpm 版本时抑制更新通知。

prefer-symlinked-executables​

  • 默认：true，当node-linker 设置为hoisted 且系统为 POSIX 时
  • 类型: 布尔值

在 node_modules/.bin 中创建指向可执行文件的符号链接，而不是命令 shim。此设置在 Windows 上被忽略，因为只有命令 shim 在 Windows 上有效。

verify-store-integrity​

  • 默认: true
  • 类型: 布尔值

默认情况下，如果存储中的文件已被修改，则在将该文件链接到项目的 node_modules 之前会检查该文件的内容。如果 verify-store-integrity 设置为 false，则在安装期间不会检查内容寻址存储中的文件。

ignore-compatibility-db​

  • 默认: false
  • 类型: 布尔值

在安装过程中，某些包的依赖项会自动修补。如果你想禁用此功能，请将此配置设置为 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
  • 类型: 布尔值

如果正在使用的注册表在缩写元数据中返回 "time" 字段，请将其设置为 true。截至目前，只有 Verdaccio 从 v5.15.1 开始支持此功能。

extend-node-path​

  • 默认: true
  • 类型: 布尔值

当 false 时，NODE_PATH 环境变量不会在命令 shim 中设置。

deploy-all-files​

  • 默认: false
  • 类型: 布尔值

在部署包或安装本地包时，将复制包的所有文件。默认情况下，如果包在 package.json 中具有 "files" 字段，则仅复制列出的文件和目录。

dedupe-direct-deps​

  • 默认: false
  • 类型: 布尔值

当设置为 true 时，已经符号链接到工作区根目录 node_modules 目录的依赖项不会符号链接到子项目 node_modules 目录。

dedupe-injected-deps​

  • 默认: true
  • 类型: 布尔值

启用此设置后，注入的依赖项 将尽可能从工作区符号链接。如果依赖项目和注入的依赖项引用相同的对等依赖项，则无需将注入的依赖项物理复制到依赖项的 node_modules 中；符号链接就足够了。

package-manager-strict​

  • 默认: true
  • 类型: 布尔值

禁用此设置后，如果 pnpm 的版本与 package.json 的 packageManager 字段中指定的版本不匹配，pnpm 不会失败。

或者，你可以将 COREPACK_ENABLE_STRICT 环境变量设置为 0。