Passa al contenuto principale
Versione: Prossimo

Domande frequenti (FAQ)

Perché la mia cartella node_modules utilizza spazio su disco se i pacchetti sono salvati in un archivio globale?​

pnpm crea "collegamenti fisici" dall'archivio globale alla cartella node_modules del progetto. I collegamenti fisici puntano allo stesso spazio sul disco dove si trovano i file originali. Quindi, ad esempio, se hai foo nel tuo progetto come dipendenza e occupa 1 Mb di spazio, sembrerà che occupi 1 Mb di spazio nella cartella node_modules del progetto e la stessa quantità di spazio nell'archivio globale. Tuttavia, 1 Mb è lo stesso spazio sul disco indirizzato da due posizioni diverse. Quindi in totale foo occupa 1MB, non 2MB.

Per saperne di più su questo argomento:

Funziona su Windows?​

Risposta breve: sì. Risposta lunga: Usare i collegamenti simbolici su Windows è a dir poco problematico, tuttavia, pnpm ha una soluzione alternativa. Per Windows, usiamo le giunzioni.

Ma l'approccio annidato di node_modules è incompatibile con Windows?​

Le prime versioni di npm hanno avuto problemi a causa del annidamento di tutti i node_modules (vedi questo ticket). Tuttavia, pnpm non crea cartelle profonde, memorizza tutti i pacchetti pianamente e utilizza collegamenti simbolici per creare la struttura ad albero delle dipendenze.

E i collegamenti simbolici circolari?​

Sebbene pnpm utilizzi il collegamento per inserire le dipendenze nella cartella node_modules, collegamenti simbolici circolari vengono evitati perché i pacchetti padre vengono inseriti nella stessa node_modules in cui si trovano le loro dipendenze. Quindi le dipendenze di foo non sono in foo/node_modules, ma foo è in node_modules insieme alle sue dipendenze.

Perché avere collegamenti fisici alla fine? Perché non collegare simbolicamente direttamente all'archivio globale?​

Un pacchetto può avere diversi insiemi di dipendenze su una macchina.

Nel progetto A foo@1.0.0 può avere una dipendenza risolta in bar@1.0.0, ma nel progetto B la stessa dipendenza di foo potrebbe risolversi in bar@1.1.0; quindi, pnpm collega fisicamente foo@1.0.0 a ogni progetto in cui viene utilizzato, per creare diversi insiemi di dipendenze per esso.

Il collegamento simbolico diretto all'archivio globale funzionerebbe con il flag --preserve-symlinks di Node, tuttavia, questo approccio ha una pletora dei suoi problemi, quindi abbiamo deciso di attenerci ai collegamenti fisici. Per maggiori dettagli sul perché stata presa questa decisione, vedere questo ticket.

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:

Il percorso dell'archivio è specificato​

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.

Il percorso dell'archivio NON è specificato​

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.

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

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

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