Перейти до основного вмісту
Версія: 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 не дозволяє створювати міжпристрійні жорсткі посилання між різними підтомами одного розділу, він дозволяє створювати reflink. Як наслідок, pnpm використовує посилання для обміну даними між цими підтомами.

Чи працює pnpm на кількох дисках або файлових системах?​

Сховище пакунків повинно знаходитися на тому ж диску і у тій же файловій системі, що й встановлення, інакше пакунки буде скопійовано, а не звʼязано. Це повʼязано з обмеженням того, як працює жорстке звʼязування, оскільки файл в одній файловій системі не може адресувати розташування в іншій. See Issue #712 for more details.

pnpm функціонує по-різному у 2 випадках нижче:

Вказано шлях до сховища​

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.