.npmrc

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

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

四个相关文件分别为:

  • 每个项目的配置文件(/path/to/my/project/.npmrc
  • 每个工作区的配置文件(包含 pnpm-workspace.yaml 文件的目录)
  • 每位用户的配置文件( ~/.npmrc
  • 全局配置文件( /etc/npmrc

所有 .npmrc 文件都遵循 INI-formatted 列表,包含 key = value 参数。

Values in the .npmrc files may contain env variables using the ${NAME} syntax. The env variables may also be specified with default values. Using ${NAME-fallback} will return fallback if NAME isn’t set. ${NAME:-fallback} will return fallback if NAME isn’t set, or is an empty string.

依赖提升设置

hoist

  • 默认值: true
  • 类型: boolean

当 hoist 为 true 时,所有依赖项都会被提升到 node_modules/.pnpm。 This makes unlisted dependencies accessible to all packages inside node_modules.

hoist-pattern

  • 默认值: [‘*‘]
  • 类型: string[]

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

例如:

  1. hoist-pattern[]=*eslint*
  2. hoist-pattern[]=*babel*

You may also exclude patterns from hoisting using !.

例如:

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

public-hoist-pattern

  • 默认值: [‘*eslint*‘, ‘*prettier*‘]
  • 类型: string[]

Unlike hoist-pattern, which hoists dependencies to a hidden modules directory inside the virtual store, public-hoist-pattern hoists dependencies matching the pattern to the root modules directory. Hoisting to the root modules directory means that application code will have access to phantom dependencies, even if they modify the resolution strategy improperly.

This setting is useful when dealing with some flawed pluggable tools that don’t resolve dependencies properly.

例如:

  1. public-hoist-pattern[]=*plugin*

Note: Setting shamefully-hoist to true is the same as setting public-hoist-pattern to *.

You may also exclude patterns from hoisting using !.

例如:

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

shamefully-hoist

  • 默认值: false
  • 类型:Boolean

By default, pnpm creates a semistrict node_modules, meaning dependencies have access to undeclared dependencies but modules outside of node_modules do not. With this layout, most of the packages in the ecosystem work with no issues. However, if some tooling only works when the hoisted dependencies are in the root of node_modules, you can set this to true to hoist them for you.

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

The location where all the packages are saved on the disk.

The store should be always on the same disk on which installation is happening, so there will be one store per disk. If there is a home directory on the current disk, then the store is created inside it. If there is no home on the disk, then the store is created at the root of the filesystem. For example, if installation is happening on a filesystem mounted at /mnt, then the store will be created at /mnt/.pnpm-store. The same goes for Windows systems.

It is possible to set a store from a different disk but in that case pnpm will copy packages from the store instead of hard-linking them, as hard links are only possible on the same filesystem.

modules-dir

  • 默认值:node_modules
  • 类型:path

The directory in which dependencies will be installed (instead of node_modules).

node-linker

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

Defines what linker should be used for installing Node packages.

  • isolated - 依赖项从虚拟存储 node_modules/.pnpm 中建立符号链接
  • hoisted - 创建一个没有符号链接的扁平的 node_modules。 与 npm 或 Yarn Classic 创建 node_modules 一致。 当使用此设置时,Yarn 的一个库用于提升。 使用此设置的正当理由:
    1. 您的工具不适用于符号链接。 React Native 项目很可能只有在你使用提升的 node_modules 才能工作。
    2. 您的项目会被部署到 serverless 服务提供商。 一些 serverless 提供商(例如 AWS Lambda)不支持符号链接。 此问题的另一种解决方案是在部署之前打包您的应用程序。
    3. 如果你想用 “bundledDependencies” 发布你的包。
    4. 如果您使用 --preserve-symlinks 标志运行 Node.js。
  • pnp - 没有 node_modules。 Plug’n’Play 是一种 Yarn Berry 使用的创新的 Node 依赖策略。 当使用 pnp 作为您的链接器时,建议同时将 symlink 设置为 false
  • 默认值: true
  • 类型:Boolean

When symlink is set to false, pnpm creates a virtual store directory without any symlinks. It is a useful setting together with node-linker=pnp.

enable-modules-dir

  • 默认值: true
  • 类型:Boolean

When false, pnpm will not write any files to the modules directory (node_modules). This is useful for when the modules directory is mounted with filesystem in userspace (FUSE). There is an experimental CLI that allows you to mount a modules directory with FUSE: @pnpm/mount-modules.

virtual-store-dir

  • 默认值:node_modules/.pnpm
  • 类型:path

The directory with links to the store. All direct and indirect dependencies of the project are linked into this directory.

This is a useful setting that can solve issues with long paths on Windows. If you have some dependencies with very long paths, you can select a virtual store in the root of your drive (for instance C:\my-project-store).

Or you can set the virtual store to .pnpm and add it to .gitignore. This will make stacktraces cleaner as paths to dependencies will be one directory higher.

NOTE: the virtual store cannot be shared between several projects. Every project should have its own virtual store (except for in workspaces where the root is shared).

package-import-method

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

Controls the way packages are imported from the store (if you want to disable symlinks inside node_modules, then you need to change the node-linker setting, not this one).

  • auto - 尝试从存储克隆包。 如果不支持克隆则从存储硬链接包。 如果克隆和链接都不支持,则回退到复制
  • hardlink - 从存储硬链接包
  • clone-or-copy - 尝试从存储中克隆包。 如果不支持克隆则回退到复制。
  • copy - 从存储中复制包
  • clone - 从存储中克隆(也称为 copy-on-write 或参考链接)包

Cloning is the best way to write packages to node_modules. It is the fastest way and safest way. When cloning is used, you may edit files in your node_modules and they will not be modified in the central content-addressable store.

Unfortunately, not all file systems support cloning. We recommend using a copy-on-write (CoW) file system (for instance, Btrfs instead of Ext4 on Linux) for the best experience with pnpm.

.npmrc - 图1提示

Even though macOS supports cloning, there is currently a bug in Node.js that prevents us from using it in pnpm. If you have ideas how to fix it, help us.

modules-cache-max-age

  • 默认值: 10080 (以分钟为单位的 7 天)
  • 类型:number

The time in minutes after which orphan packages from the modules directory should be removed. pnpm keeps a cache of packages in the modules directory. This boosts installation speed when switching branches or downgrading dependencies.

锁文件设置

lockfile

  • 默认值: true
  • 类型:Boolean

When set to false, pnpm won’t read or generate a pnpm-lock.yaml file.

prefer-frozen-lockfile

  • 默认值: true
  • 类型:Boolean

When set to true and the available pnpm-lock.yaml satisfies the package.json dependencies directive, a headless installation is performed. A headless installation skips all dependency resolution as it does not need to modify the lockfile.

lockfile-include-tarball-url

  • 默认值: false
  • 类型:Boolean

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

注册源 & 身份验证设置

registry

npm包注册源地址 (包括末尾斜杠) 。

<scope>:registry

用于指定包的注册源范围 例如,设置 @babel:registry=https://example.com/packages/npm/ 将在您使用 pnpm add @babel/core 或任何 @babel 范围内的包时,该包将强制从 https://example.com/packages/npm 获取而不是默认注册源。

<URL>:_authToken

访问指定注册源时要使用的身份验证承载令牌。 示例:

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

您也可以使用环境变量。 示例:

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

或者,您可以直接使用环境变量,而不更改 .npmrc:

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

<URL>:tokenHelper

令牌助手是输出身份验证令牌的可执行文件。 这可以用于 authToken 不是常量值而是定期刷新值的情况,其中脚本或其他工具可以使用现有的刷新令牌来获取新的访问令牌。

助手路径的配置必须是绝对路径,没有参数。 为了安全起见,只允许在用户 .npmrc设置此值。 否则,项目可以在项目的本地 .npmrc 放置一个值并运行任意可执行文件。

为默认注册表设置令牌助手:

  1. tokenHelper=/home/ivan/token-generator

为指定注册源设置令牌助手:

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

请求设置

ca

  • Default: The npm CA certificate
  • Type: String, Array or null

与注册源 SSL 连接时使用的受信任的证书颁发机构签名证书。 值应采用 PEM 格式(AKA “Base-64 encoded X.509 (.CER)”)。 示例:

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

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

通过指定一组证书,可以信任多个 CA:

  1. ca[]="..."
  2. ca[]="..."

另请参阅 strict-ssl 配置。

cafile

  • 默认值:null
  • 类型:path

包含一个或多个证书颁发机构签名证书的文件的路径。 类似于 ca 设置,但允许多个 CA,以及将 CA 信息存储在文件中,而不是通过 CLI 指定。

cert

  • 默认值:null
  • 类型:String

访问注册源时要传递的客户端证书。 值应采用 PEM 格式(AKA “Base-64 encoded X.509 (.CER)”)。 示例:

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

它不是证书文件的路径(并且没有 certfile 选项)。

key

  • 默认值:null
  • 类型:String

访问注册源时传递的客户端密钥。 值应采用 PEM 格式(也称 “Base-64 encoded X.509 (.CER)”)。 示例:

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

它不是密钥文件的路径(也没有 keyfile 选项)。

这个设置含有敏感信息! 不要将其写入本地会提交到仓库的 .npmrc 文件。

git-shallow-hosts

  • Default: [‘github.com’, ‘gist.github.com’, ‘gitlab.com’, ‘bitbucket.com’, ‘bitbucket.org’]
  • 类型: string[]

当获取 Git 仓库中的依赖项时,如果域名在此设置中列出,pnpm 将使用浅克隆仅获取所需的提交,而不是所有历史记录。

https-proxy

  • 默认值:null
  • Type: url

用于传出 HTTPS 请求的代理。 如果设置了 HTTPS_PROXYhttps_proxyHTTP_PROXYhttp_proxy 环境变量,将使用环境变量的值。

If your proxy URL contains a username and password, make sure to URL-encode them. 例如:

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

Do not encode the colon (:) between the username and password.

http-proxy

proxy

  • 默认值:null
  • Type: url

用于传出 HTTP 请求的代理。 如果设置了 HTTP_PROXY 或 http_proxy 环境变量,底层请求库将遵循代理设置。

local-address

  • 默认值:undefined
  • 类型:IP Address

连接到 npm registry 时要使用的本地接口 IP 地址。

maxsockets

  • Default: network-concurrency x 3
  • 类型:Number

每个源(由协议/主机/端口号组合而成)允许的最大连接数。

noproxy

  • 默认值: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 时,将自动安装任何缺少的非可选同级依赖关系。

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:

  1. node_modules
  2. .pnpm
  3. webpack@1.0.0_esbuild@1.0.0
  4. webpack@1.0.0
  5. project1
  6. node_modules
  7. webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack
  8. project2
  9. node_modules
  10. webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
  11. 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:

  1. node_modules
  2. .pnpm
  3. webpack@1.0.0_esbuild@1.0.0
  4. project1
  5. node_modules
  6. webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
  7. project2
  8. node_modules
  9. webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
  10. esbuild

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

  1. node_modules
  2. .pnpm
  3. webpack@1.0.0_react@16.0.0_esbuild@1.0.0
  4. webpack@1.0.0_react@17.0.0
  5. project1
  6. node_modules
  7. webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack
  8. react (v17)
  9. project2
  10. node_modules
  11. webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
  12. esbuild
  13. 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

When enabled, dependencies of the root workspace project are used to resolve peer dependencies of any projects in the workspace. It is a useful feature as you can install your peer dependencies only in the root of the workspace, and you can be sure that all projects in the workspace use the same versions of the 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 和它的依赖项中定义的任何脚本.

.npmrc - 图2注意

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

ignore-dep-scripts

  • 默认值: false
  • 类型:Boolean

Do not execute any scripts of the installed packages. Scripts of the projects are executed.

child-concurrency

  • Default: 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
  • 类型:Boolean

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

Node.js 设置

use-node-version

  • 默认值:undefined
  • 类型:semver

指定应用于项目运行时的确切 Node.js 版本。 pnpm 将自动安装指定版本的 Node.js 并将其用于执行 pnpm run 命令或 pnpm node 命令。

This may be used instead of .nvmrc and nvm. Instead of the following .nvmrc file:

  1. 16.16.0

Use this .npmrc file:

  1. use-node-version=16.16.0

node-version

  • 默认值:node -v 的返回值,不带 v 前缀
  • 类型:semver

The Node.js version to use when checking a package’s engines setting.

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:

  1. node-version=12.22.0
  2. 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 等中的任何目录。

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

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

Workspace Settings

  • 默认值: 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. 如果您需要本地包也链接到子依赖项,您可以使用 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:

  • 每个依赖都是一个单例
  • 在 monorepo 中的安装更快
  • 代码更改都在一个文件中、代码审查(Cr )减少

.npmrc - 图3注意

Even though all the dependencies will be hard linked into the root node_modules, packages will have access only to those dependencies that are declared in their package.json, so pnpm’s strictness is preserved. This is a result of the aforementioned symbolic linking.

save-workspace-protocol

  • Default: rolling
  • Type: 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-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

When executing commands recursively in a workspace, execute them on the root workspace project as well.

ignore-workspace-cycles

Added in: v8.1.0

  • 默认值: false
  • 类型:Boolean

When set to true, no workspace cycle warnings will be printed.

其它设置

use-running-store-server

  • 默认值: false
  • 类型:Boolean

Only allows installation with a store server. If no store server is running, installation will fail.

save-prefix

  • Default: ‘^’
  • 类型: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

  • 默认值: false
  • 类型:String

如果您执行 pnpm add 添加了一个包并且没有提供特定版本,那么它安装设置中这个标记下的版本。

如果 pnpm tag 命令没有给出明确的标签,这也会设置的标签添加到指定的 package@version

global-dir

  • 默认值:
    • 如果设置了 $XDG_DATA_HOME 环境变量,则为 $XDG_DATA_HOME/pnpm/store
    • 在 Windows 上:~/AppData/Local/pnpm/store
    • 在 macOS 上:~/Library/pnpm/global
    • 在 Linux 上:~/.local/share/pnpm/global
  • 类型:path

指定储存全局依赖的目录。

global-bin-dir

  • 默认值:
    • If the $XDG_DATA_HOME env variable is set, then $XDG_DATA_HOME/pnpm
    • On Windows: ~/AppData/Local/pnpm
    • On macOS: ~/Library/pnpm
    • On Linux: ~/.local/share/pnpm
  • 类型:path

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

state-dir

  • 默认值:
    • If the $XDG_STATE_HOME env variable is set, then $XDG_STATE_HOME/pnpm
    • On Windows: ~/AppData/Local/pnpm-state
    • On macOS: ~/.pnpm-state
    • On 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

设置为 false 以便在使用较旧版本的 pnpm 时关闭更新通知。

prefer-symlinked-executables

  • Default: true, when node-linker is set to hoisted and the system is POSIX
  • 类型:Boolean

Create symlinks to executables in node_modules/.bin instead of command shims. This setting is ignored on Windows, where only command shims work.

verify-store-integrity

  • 默认值: true
  • 类型:Boolean

By default, if a file in the store has been modified, the content of this file is checked before linking it to a project’s node_modules. If verify-store-integrity is set to false, files in the content-addressable store will not be checked during installation.

ignore-compatibility-db

  • 默认值: false
  • 类型:Boolean

During installation the dependencies of some packages are automatically patched. If you want to disable this, set this config to false.

The patches are applied from Yarn’s @yarnpkg/extensions package.

resolution-mode

  • Default: lowest-direct
  • Type: highest, time-based, lowest-direct

When resolution-mode is set to time-based, dependencies will be resolved the following way:

  1. Direct dependencies will be resolved to their lowest versions. So if there is foo@^1.1.0 in the dependencies, then 1.1.0 will be installed.
  2. Subdependencies will be resolved from versions that were published before the last direct dependency was published.

With this resolution mode installations with warm cache are faster. It also reduces the chance of subdependency hijacking as subdependencies will be updated only if direct dependencies are updated.

This resolution mode works only with npm’s full metadata. So it is slower in some scenarios. However, if you use Verdaccio v5.15.1 or newer, you may set the registry-supports-time-field setting to true, and it will be really fast.

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

registry-supports-time-field

  • 默认值: false
  • 类型:Boolean

Set this to true if the registry that you are using returns the “time” field in the abbreviated metadata. As of now, only Verdaccio from v5.15.1 supports this.

extend-node-path

  • 默认值: true
  • 类型:Boolean

false时,命令 shims 中不会设置 NODE_PATH 环境变量。

deploy-all-files

  • 默认值: false
  • 类型:Boolean

When deploying a package or installing a local package, all files of the package are copied. By default, if the package has a "files" field in the package.json, then only the listed files and directories are copied.

dedupe-direct-deps

Added in: v8.1.0

  • 默认值: false
  • 类型:Boolean

When set to true, dependencies that are already symlinked to the root node_modules directory of the workspace will not be symlinked to subproject node_modules directories.