跳到主内容
版本：9.x

常见问题

Why does my node_modules folder use disk space if packages are stored in a global store?​

pnpm creates hard links from the global store to the project's node_modules folders. 硬链接指向磁盘上原始文件所在的同一位置。 So, for example, if you have foo in your project as a dependency and it occupies 1MB of space, then it will look like it occupies 1MB of space in the project's node_modules folder and the same amount of space in the global store. However, that 1MB is the same space on the disk addressed from two different locations. So in total foo occupies 1MB, not 2MB.

获取有关此主题的更多信息：

能用于Windows吗？​

短回答：当然 长答案：在 Windows 上使用符号链接至少可以说是有问题的，但是，pnpm 有一个解决方法。 For Windows, we use junctions instead.

But the nested node_modules approach is incompatible with Windows?​

Early versions of npm had issues because of nesting all node_modules (see this issue). 但是，pnpm 不会创建深层文件夹，它使用符号链接来创建依赖关系树结构。

Although pnpm uses linking to put dependencies into node_modules folders, circular symlinks are avoided because parent packages are placed into the same node_modules folder in which their dependencies are. So foo's dependencies are not in foo/node_modules, but foo is in node_modules together with its own dependencies.

为什么使用硬链接？ 为什么不直接创建到全局存储的符号链接？​

一台机器上一个包在可以有不同的依赖集。

In project A foo@1.0.0 can have a dependency resolved to bar@1.0.0, but in project B the same dependency of foo might resolve to bar@1.1.0; so, pnpm hard links foo@1.0.0 to every project where it is used, in order to create different sets of dependencies for it.

Direct symlinking to the global store would work with Node's --preserve-symlinks flag, however, that approach comes with a plethora of its own issues, so we decided to stick with hard links. For more details about why this decision was made, see this issue.

pnpm 是否可以在 Btrfs 分区中的不同子卷工作？​

虽然 Btrfs 不允许单个分区中不同子卷之间的跨设备硬链接，但它允许引用链接。 因此，pnpm 利用引用链接在这些子卷之间共享数据。

Pnpm 是否可以跨多个驱动器或文件系统工作？​

包存储应与安装的位置处于同一驱动器和文件系统上，否则，包将被复制，而不是被链接。 这是由于硬链接的工作方式带来的一个限制，因为一个文件系统上的文件无法寻址另一个文件系统中的位置。 See Issue #712 for more details.

pnpm 在以下两种情况下的功能有所不同：

存储路径已指定​

If the store path is specified via the store config, then copying occurs between the store and any projects that are on a different disk.

If you run pnpm install on disk A, then the pnpm store must be on disk A. If the pnpm store is located on disk B, then all required packages will be directly copied to the project location instead of being linked. 这严重抑制了 pnpm 的存储和性能优势。

存储路径未指定​

如果未设置存储路径，则会创建多个存储（每个驱动器或文件系统一个）。

If installation is run on disk A, the store will be created on A .pnpm-store under the filesystem root. If later the installation is run on disk B, an independent store will be created on B at .pnpm-store. 项目仍将保持 pnpm 的优势，但每个驱动器可能有冗余包。

What does pnpm stand for?​

pnpm stands for performant npm. @rstacruz came up with the name.

pnpm does not work with <YOUR-PROJECT-HERE>?​

In most cases it means that one of the dependencies require packages not declared in package.json. It is a common mistake caused by flat node_modules. 如果发生这种情况，这是依赖项中的错误，应修复依赖项。 但这可能需要时间，因此 pnpm 支持额外的解决方法来使有问题的包工作。

解决方案1​

In case there are issues, you can use the node-linker=hoisted setting. This creates a flat node_modules structure similar to the one created by npm.

解决方案2​

In the following example, a dependency does not have the iterall module in its own list of deps.

The easiest solution to resolve missing dependencies of the buggy packages is to add iterall as a dependency to our project's package.json.

You can do so, by installing it via pnpm add iterall, and will be automatically added to your project's package.json.

  "dependencies": {
    ...
    "iterall": "^1.2.2",
    ...
  }

解决方案3​

One of the solutions is to use hooks for adding the missing dependencies to the package's package.json.

An example was Webpack Dashboard which wasn't working with pnpm. It has since been resolved such that it works with pnpm now.

它曾经抛出一个错误：

Error: Cannot find module 'babel-traverse'
  at /node_modules/inspectpack@2.2.3/node_modules/inspectpack/lib/actions/parse

The problem was that babel-traverse was used in inspectpack which was used by webpack-dashboard, but babel-traverse wasn't specified in inspectpack's package.json. It still worked with npm and yarn because they create flat node_modules.

The solution was to create a .pnpmfile.cjs with the following contents:

module.exports = {
  hooks: {
    readPackage: (pkg) => {
      if (pkg.name === "inspectpack") {
        pkg.dependencies['babel-traverse'] = '^6.26.0';
      }
      return pkg;
    }
  }
};

After creating a .pnpmfile.cjs, delete pnpm-lock.yaml only - there is no need to delete node_modules, as pnpm hooks only affect module resolution. Then, rebuild the dependencies & it should be working.