Pular para o conteúdo principal
Version: 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: Utilizar links simbólicos no Windows é no mínimo problemático, mas pnpm tem uma alternativa. 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.

E quanto aos links simbólicos circulares?#

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

Por que usar hard links? Por que não criar um link simbólico direto para o armazenamento global?#

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

No projeto A, [email protected] pode depender de [email protected], mas no projeto B, a mesma dependencia foo pode depender de [email protected]; então, pnpm liga [email protected] 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.

O pnpm funciona com diversas unidades de armazenamento ou sistemas de arquivos?#

O armazenamento global de pacotes deve estar na mesma unidade de armazenamento e utilizando o mesmo sistema de arquivos da instalação. Caso contrário, os pacotes serão copiados, e não vinculados. Isso ocorre devido a uma limitação de como os hard links funcionam - um arquivo num determinado sistema de arquivos não pode ser direcionado para um endereço em outro sistema. Veja a issue #712 para mais detalhes.

pnpm funciona de maneira diferente nos dois casos abaixo:

O caminho para o armazenamento global é especificado#

Caso o caminho para o armazenamento global seja especificado, a cópia ocorrerá entre o armazenamento e quaisquer projetos que estejam numa unidade de armazenamento diferente.

Se você executar pnpm install na unidade A, então o armazenamento global deve estar na unidade A. Se o armazenamento estiver localizado na unidade B, então todos os pacotes serão copiados para a localização do projeto, ao invés de serem vinculados. Isso inibe severamente os benefícios de armazenamento e desempenho do pnpm.

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

Caso o caminho não seja especificado, então múltiplas instâncias do armazenamento global serão criadas (uma vez por cada unidade ou sistema de arquivos).

Caso a instalação seja executada na unidade A, o armazenamento global será criado em A, na pasta .pnpm-store, na pasta raiz (ou root). Se, posteriormente, a instalação for executada na unidade B, um armazenamento global independente será criado em B, na pasta .pnpm-store. Os projetos ainda irão manter os benefícios do pnpm, mas cada unidade de armazenamento pode conter pacotes redundantes.

O que pnpm store prune faz? É prejudicial?#

O comando pnpm store prune remove pacotes não referenciados.

Pacotes não referenciados são pacotes que não são usados por nenhum projeto no sistema. Pacotes podem se tornar não referenciados após a maioria das operações de instalação, quando, por exemplo, dependências se tornam redundantes.

Por exemplo, durante pnpm install, o pacote [email protected] é atualizado para [email protected]. pnpm vai manter [email protected] no armazenamento global, já que os pacotes não serão removidos automaticamente. Caso o pacote [email protected] não seja usado por mais nenhum projeto no sistema, ele se torna um pacote não referenciado. Executar pnpm store prune removeria [email protected] do armazenamento global.

Executar pnpm store prune não é prejudicial nem tem efeitos colaterais em seus projetos. Caso instalações futuras precisem dos pacotes removidos, pnpm irá baixá-los novamente.

É recomendado que se execute pnpm store prune ocasionalmente para limpar o armazenamento global, mas não com muita frequência. Algumas vezes, pacotes não referenciados podem ser exigidos novamente. Isso poderia acontecer ao trocar de branch e ter que instalar dependências mais antigas, que teriam que ser baixadas novamente, tornando o processo de instalação mais lento.

O que pnpm significa?#

pnpm significa performant npm (inglês para npm com desempenho). @rstacruz came up with the name.

pnpm não funciona com <SEU-PROJETO-AQUI>?#

Na maioria dos casos, isso significa que uma de suas dependências requer pacotes não declarados no package.json. Este é um erro comum, causado pela abordagem de um node_modules plano. Caso isso aconteça, este é um erro na dependência, que deve ser corrigida. No entanto, isso pode levar algum tempo, então o pnpm suporta soluções alternativas para fazer com que os pacotes problemáticos funcionem.

Solução 1#

No exemplo a seguir, uma dependência não possui o pacote iterall em sua própria lista de dependências.

A solução mais fácil para resolver o problema de dependências faltantes nos pacotes problemáticos é adicionar iterall como uma dependência no arquivo package.json de seu projeto.

Você pode fazer isso instalando-o via pnpm add iterall, e ele será automaticamente adicionado ao arquivo package.json de seu projeto.

  "dependencies": {    ...    "iterall": "^1.2.2",    ...  }

Solução 2#

Uma das soluções é usar hooks para adicionar as dependências faltantes ao package.jsondo pacote.

Um exemplo era o pacote Webpack Dashboard, que não estava funcionando com pnpm. O problema foi resolvido, e o pacote funciona com pnpm agora.

Antes, ele costumava gerar um erro:

Error: Cannot find module 'babel-traverse'  at /node_modules/[email protected]/node_modules/inspectpack/lib/actions/parse

O problema era que babel-traverse foi utilizado em inspectpack, que foi utilizado pelo webpack-dashboard, mas babel-traverse não era especificado no package.json do inspectpack. Ele ainda funcionava com npm e yarn por que eles utilizam um node_modules plano.

A solução foi criar um arquivo nomeado .pnpmfile.cjs com o seguinte conteúdo:

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

Após criar o .pnpmfile.cjs, exclua o arquivo pnpm-lock.yaml apenas - não há necessidade de excluir a pasta node_modules, uma vez que os hooks do pnpm afetam apenas a resolução do módulo. Então, reinstale as dependências & tudo deve estar funcionando.

Solução 3#

Caso hajam muitos problemas, você pode utilizar a opção shamefully-hoist. Isso cria um node_modules plano, com estrutura similar ao criado pelo npm ou yarn, algo não recomendado, uma vez que evitar esta estrutura é o principal objetivo da abordagem de node_modules do pnpm.

Para utilizá-lo, execute pnpm install --shamefully-hoist.