Settings (.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
- 默认值: true
- 类型: boolean
当 true
时,工作区中的包将符号链接到 <workspace_root>/node_modules/.pnpm/node_modules
或 <workspace_root>/node_modules
,具体取决于其他提升设置(hoist-pattern
和 public-hoist-pattern
) 。
hoist-pattern
- 默认值: ['*']
- 类型: string[]
告诉 pnpm 哪些包应该被提升到 node_modules/.pnpm/node_modules
。 默认情况下,所有包都被提升 —— 但是,如果您知道只有某些有缺陷的包具有幻影依赖,您可以使用此选项专门提升幻影依赖(推荐做法)。
例如:
hoist-pattern[]=*eslint*
hoist-pattern[]=*babel*
从 v7. 开始, 您还可以在模式 pattern 前面添加 !
来避免提升。
例如:
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
为 *
是一样的。
从 v7. 开始, 您还可以在模式 pattern 前面添加 !
来避免提升。
例如:
public-hoist-pattern[]=*types*
public-hoist-pattern[]=!@types/react
shamefully-hoist
- 默认值: false
- 类型:Boolean
默认情况下,pnpm 创建一个半严格的 node_modules
,这意味着依赖项可以访问未声明的依赖项,但 node_modules
之外的模块不行。 通过这种布局,生态系统中的大多数的包都可以正常工作。 但是,如果某些工具仅在提升的依赖项位于根目录的 node_modules
时才有效,您可以将其设置为 true
来为您提升它们。
Node 模块设置
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
。 这将使堆栈跟踪更清晰,因为依赖项的路径将会提高一个目录层级。
注意: 虚拟存储不能在多个项目之间共享。 每个项目都应该有自己的虚拟存储(除了在工作空间中被共享的根目录)。
virtual-store-dir-max-length
Added in: v9.1.0
- Default: 120
- Types: number
Sets the maximum allowed length of directory names inside the virtual store directory (node_modules/.pnpm
). You may set this to a lower number if you encounter long path issues on Windows.
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 在模块目录中保存了一个包的缓存。 切换分支或降级依赖项时,这会提高安装速度。
dlx-cache-max-age
- Default: 1440 (1 day in minutes)
- 类型:number
The time in minutes after which dlx cache expires. After executing a dlx command, pnpm keeps a cache that omits the installation step for subsequent calls to the same dlx command.