Skip to main content
Version: 6.x


なぜ、 node_modules フォルダは、パッケージがグローバルストアに保存されている場合にディスク容量を使用するのですか?

pnpm は、 ハードリンク を、グローバルストアからプロジェクトの node_modules フォルダーに作成します。 ハードリンクは、元の ファイルがあるディスク上の同じ場所を指します。 例えば、1MBを占める foo を依存に持つプロジェクトでは、そのプロジェクト配下の node_modules フォルダが、リンク元のグローバルストアと同じ 1MB を消費しているように見えます。 ただし、2つの異なるリンクが示す、占有されている 1MB はディスク上の 同じ位置 にあります。 そのため、全体で foo は 2MB ではなく 1MB のみ占有しています。



簡単な答え:はい。 詳細な答え: Windows 上でシンボリックリンクを使用することに関しては少なくとも問題はありますが、しかし、pnpm には回避策があります。 Windows では、代わりに ジャンクション を使用します。

しかし、ネストされた node_modules アプローチは Windows と互換性がありますか?

npm の初期のバージョンはすべての node_modules を入れ子にするために問題がありました ( この issue を参照してください)。 However, pnpm does not create deep folders, it stores all packages flatly and uses symbolic links to create the dependency tree structure.

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.

One package can have different sets of dependencies on one machine.

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.


パッケージストアは、インストール先と同じドライブおよびファイルシステム上にある必要があります そうでない場合、パッケージはリンクされずにコピーされます。 これは、あるファイルシステム上のファイルは、他のファイルシステム上の場所を扱うことができないというハードリンクの仕組みによる制限です。 詳細については、Issue #712 を参照してください。



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. This severely inhibits the storage and performance benefits of pnpm.

Store path is NOT specified

If the store path is not set, then multiple stores are created (one per drive or filesystem).

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. The projects would still maintain the benefits of pnpm, but each drive may have redundant packages.

pnpm は何の略ですか?

pnpmperformant npm の略です。 @rstacruz がこの名前を考案しました。

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. If this happens, this is an error in the dependency and the dependency should be fixed. That might take time though, so pnpm supports workarounds to make the buggy packages work.


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",


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.

It used to throw an error:

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.

これの解決策は次のような .pnpmfile.cjs を作成することでした:

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

.pnpmfile.cjs を作成後、pnpm-lock.yamlのみを削除してください。pnpmのフックはモジュール解決のみに影響するため、 node_modules を削除する必要はありません。 Then, rebuild the dependencies & it should be working.


In case there are too many issues, you can use the shamefully-hoist option. This creates a flat node_modules structure similar to the one created by npm or yarn, which is not recommended as avoiding this structure is the primary purpose of pnpm's node_modules approach.

To use it, try pnpm install --shamefully-hoist.