Passer au contenu principal
Version : 7.x

Questions fréquemment posées

Pourquoi mon dossier node_modules utilise-t-il de l'espace disque si les packages sont stockés dans un magasin global ?​

pnpm crée des liens du magasin global vers le dossier node_modules du projet. Les liens matériels pointent vers le même endroit sur le disque où se trouvent les fichiers originaux. Donc, par exemple, si vous avez foo dans votre projet en tant que dépendance et qu'il occupe 1Mo d'espace, alors, il semblera qu'il utilise 1 Mo d'espace dans le dossier node_modules du projet et la même quantité d'espace dans le magasin global. Cependant, ce 1 Mo est le même espace sur le disque adressé à partir de deux emplacements différents. Donc au total, foo occupe 1 Mo, et non 2 Mo.

Pour en savoir plus sur ce sujet:

Cela fonctionne-t-il sous Windows ?​

Réponse courte : oui. Réponse longue : l'utilisation des liens symboliques sous Windows est pour le moins problématique, cependant pnpm a une solution de contournement. Pour Windows, nous utilisation les jonctions à la place.

Mais l'approche des node_modules imbriqués est incompatible avec Windows ?​

Les premières versions de npm ont eu des problèmes à cause de l'imbrication de tous les node_modules (voir cette issue). Cependant, pnpm ne crée pas de dossiers profonds, il stocke tous les packages à plat et utilise des liens symboliques pour créer l'arborescence des dépendances.

Qu'en est-il des liens symboliques circulaires ?​

Bien que pnpm utilise un lien pour mettre les dépendances dans les dossiers node_modules , les liens symboliques circulaires sont évités car les paquets parents sont placés dans le même dossier node_modules dans lequel se trouvent leurs dépendances. Ainsi, les dépendances de foo ne sont pas dans foo/node_modules, mais foo se trouve dans node_modules avec ses propres dépendances.

Pourquoi avoir des liens durs ? Pourquoi ne pas créer un lien symbolique directement vers le magasin global ?​

Un package peut avoir différents ensembles de dépendances sur une machine.

Dans le projet A foo@1.0.0 peut avoir une dépendance résolue en bar@1.0.0, mais dans le projet B la même dépendance de foo peut être résolue en bar@1.1.0 ; alors, pnpm relie en dur foo@1.0.0 à chaque projet où il est utilisé, afin de créer différents ensembles de dépendances pour celui-ci.

La création de liens symboliques directs vers le magasin global fonctionnerait avec l'option --preserve-symlinks de Node, cependant, cette approche s'accompagne d'une panoplie de ses propres problèmes, donc nous avons décidé de garder les liens durs. Pour plus de détails sur les raisons de cette décision, lisez cette issue.

Does pnpm work across multiple drives or filesystems?​

The package store should be on the same drive and filesystem as installations, otherwise packages will be copied, not linked. This is due to a limitation in how hard linking works, in that a file on one filesystem cannot address a location in another. See Issue #712 for more details.

pnpm functions differently in the 2 cases below:

Store path is specified​

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.

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. 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.

Solution 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.

Solution 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",
    ...
  }

Solution 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.

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.

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.