Pular para o conteúdo principal
Versão: Next

Perguntas frequentes

Por que minha pasta node_modules usa espaço se os pacotes são armazenados globalmente?​

pnpm cria hard links do armazenamento global para a pasta node_modules de cada projeto. Hard links apontam para o mesmo espaço no disco onde os arquivos originais estão. Então, por exemplo, se você tem o pacote foo em seu projeto como uma dependência, e ocupa 1MB de espaço, então irá parecer que ocupa 1MB de espaço na pasta node_modules, e 1MB de espaço no armazenamento global. No entanto, esse 1MB é o mesmo espaço no disco, apontado de duas localizações diferentes. Então, no total, foo ocupa 1MB, não 2MB.

Para mais sobre este assunto:

Ele funciona no Windows?​

Resposta curta: Sim. Resposta longa: Usando um link simbólico no Windows é problemático pra dizer o mínimo, entretanto, pnpm tem uma solução alternativa/gambiarra. Para Windows, nós usamos junções em vez disso.

Mas a abordagem aninhada do node_modules é incompatível com Windows?​

As primeiras versões do npm apresentavam problemas devido ao aninhamento de todos os node_modules (veja essa issue). No entanto, pnpm não cria pastas profundas, ele armazena todos os pacotes de forma plana e utiliza links simbólicos para criar a estrutura de dependências.

Mesmo que o pnpm use links para colocar dependências dentro das pastas node_modules, symlinks circulares são evitados porque os pacotes-pai são colocados na mesma pasta node_modules em que estão suas dependências. Portanto, as dependências de foo não estão em foo/node_modules, mas foo está em node_modules, junto com suas próprias dependências.

Um pacote pode ter diferentes conjuntos de dependências numa mesma máquina.

No projeto A, foo@1.0.0 pode depender de bar@1.0.0, mas no projeto B, a mesma dependência foo pode depender de bar@1.1.0; então, pnpm liga foo@1.0.0 para todos os projetos que o usam, a fim de criar diferentes conjuntos de dependências em cada um deles.

Um link simbólico direto para o armazenamento global iria funcionar com a opção --preserve-symlinks do Node, mas essa abordagem viria com uma infinidade de problemas, então nós decidimos continuar utilizando hard links. Para mais detalhes sobre por que esta decisão foi tomada, veja esta 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:

O caminho para o armazenamento global é especificado​

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.

O caminho para o armazenamento global NÃO é especificado​

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.

Solução 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.

Solução 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",
    ...
  }

Solução 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.