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

.npmrc

O pnpm obtém sua configuração da linha de comando, variáveis de ambiente e arquivos .npmrc.

O comando pnpm config pode ser usado para atualizar e editar o conteúdo dos arquivos user e global .npmrc.

Os quatro arquivos relevantes são:

  • arquivo de configuração por projeto (/path/to/my/project/.npmrc)
  • arquivo de configuração por área de trabalho (o diretório que contém o arquivo pnpm-workspace.yaml)
  • arquivo de configuração por usuário (~/.npmrc)
  • arquivo de configuração global (/etc/npmrc)

Todos os arquivos .npmrc são listas formatadas em INI de parâmetros chave = valor.

Os valores nos arquivos .npmrc podem conter variáveis env usando a sintaxe ${NAME}. As variáveis env também podem ser especificadas com valores padrão. Usar ${NAME-fallback} retornará fallback se NAME não estiver definido. ${NAME:-fallback} retornará fallback se NAME não estiver definido ou for uma string vazia.

Configurações de elevação de dependência​

hoist​

  • Valor padrão: false
  • Tipo: Boolean

Quando true, todas as dependências são elevadas para node_modules/.pnpm/node_modules. Isso torna as dependências não listadas acessíveis a todos os pacotes dentro da node_modules.

hoist-workspace-packages​

Added in: v8.14.0

  • Padrão: low
  • Tipo: Boolean

When true, packages from the workspaces are symlinked to either <workspace_root>/node_modules/.pnpm/node_modules or to <workspace_root>/node_modules depending on other hoisting settings (hoist-pattern and public-hoist-pattern).

hoist-pattern​

  • Valor padrão: false
  • Tipo: Boolean

Diz ao pnpm quais pacotes devem ser elevados para a node_modules/.pnpm/node_modules. Por padrão, todos os pacotes são elevados, contudo, se você sabe que apenas alguns pacotes falhos têm dependências fantasmas, você pode usar esta opção para elevar especificamente as dependências fantasmas (recomendado).

Por exemplo:

hoist-pattern[]=*eslint*
hoist-pattern[]=*babel*

Você também pode excluir padrões de serem elevados usando !.

Por exemplo:

hoist-pattern[]=*types*
hoist-pattern[]=!@types/react

public-hoist-pattern​

  • Padrão: ['*eslint*', '*mais bonito*']
  • Tipo: Boolean

Ao contrário de hoist-pattern, que eleva dependências para um diretório de módulos ocultos dentro da loja virtual, public-hoist-pattern eleva dependências que correspondem ao padrão ao diretório de módulos raiz. O Hoisting para o diretório raiz dos módulos significa que o código de aplicação terá acesso a dependências fantasmas, mesmo se modificarem a estratégia de resolução impropriamente.

Essa configuração é útil ao lidar com algumas ferramentas conectáveis defeituosas que não resolvem as dependências adequadamente.

Por exemplo:

public-hoist-pattern[]=*plugin*

Nota: Definir shamefully-hoist para true é o mesmo que definir public-hoist-pattern para *.

Você também pode excluir padrões do hoisting usando !.

Por exemplo:

public-hoist-pattern[]=*types*
public-hoist-pattern[]=!@types/react

shamefully-hoist​

  • Padrão: low
  • Tipo: Boolean

Por padrão, o pnpm cria uma node_modules semi estrita, o que significa que as dependências têm acesso a dependências não declaradas, mas os módulos fora da node_modules não tem. Com esse layout, a maioria dos pacotes no ecossistema funciona sem problemas. No entanto, se alguma ferramenta só funciona quando as dependências elevadas estiverem na raiz da node_modules, você pode definir essa opção como true para elevar elas para você.

Configurações de Módulos Node​

store-dir​

  • Padrão:
    • Se a variável $PNPM_HOME existir, então $PNPM_HOME/store
    • Se a variável $XDG_DATA_HOME existir, então $XDG_DATA_HOME/pnpm/store
    • No Windows: ~/AppData/Local/pnpm/store
    • No macOS: ~/Library/pnpm/store
    • No Linux: ~/.local/share/pnpm/store
  • Tipo: caminho

O local onde todos os pacotes são salvos no disco.

A store deve estar sempre no mesmo disco em que a instalação está acontecendo, para exista uma store por disco. Se houver um diretório home no disco atual, então a store será criado dentro dele. Se não houver algum diretório home no disco, a store será criada a partir da raiz do sistema de arquivos. Por exemplo, se a instalação está acontecendo em um sistema de arquivos montado em /mnt, então a store será criada em /mnt/.pnpm-store. O mesmo acontece para os sistemas windows.

É possível definir uma store a partir de um disco diferente, mas nesse caso o pnpm vai copiar os pacotes da store ao invés de fazer um hard-linking deles, pois hard links só são possíveis no mesmo sistema de arquivos.

modules-dir​

  • Padrão: node_modules
  • Tipo: caminho

O diretório que as dependências serão instaladas (ao invés de node_modules).

node-linker​

  • Padrão: ** isolated **
  • Tipo: isolated, hoisted, pnp

Define qual linker deve ser usado para instalar os pacotes do Node.

  • isolated - as dependências são vinculadas a partir de uma loja virtual em node_modules/.pnpm.
  • hoisted - um node_modules limpo sem links simbólicos é criado. O mesmo que node_modules criado por npm ou Yarn Classic. Uma das bibliotecas do Yarn é usada para fazer o hoisting quando essa configuração é usada. Razões legítimas para usar esta configuração:
    1. Suas ferramentas não funcionam bem com links simbólicos. Um Projeto Native reagirá muito provavelmente só funcionará se você usar um hoisted node_modules.
    2. Seu projeto é implantado em um provedor de hospedagem sem servidor. Alguns provedores sem servidor (por exemplo, AWS Lambda) não oferecem suporte a links simbólicos. Uma solução alternativa para esse problema é agrupar seu aplicativo antes da implantação.
    3. Se você deseja publicar seu pacote com "bundledDependencies".
    4. Se você estiver executando o Node.js com o parâmetro --preserve-symlinks.
  • pnp - sem node_modules. Plug'n'Play é uma estratégia inovadora para Node que é utilizada pelo Yarn Berry. Recomenda-se também definir a configuração symlink para false ao usar pnp como seu vinculador.
  • Valor padrão: true
  • Tipo: Boolean

Quando o symlink é configurado para false, o pnpm cria o diretório virtual da store sem symlinks. É uma configuração útil junto com node-linker=pnp.

enable-modules-dir​

  • Valor padrão: true
  • Tipo: Boolean

Quando false, o pnpm não gravará nenhum arquivo no diretório de módulos (node_modules). Isso é útil quando o diretório de módulos é montado com sistema de arquivos no espaço do usuário (FUSE). Existe uma CLI experimental que permite montar um diretório de módulos com FUSE: @pnpm/mount-modules.

virtual-store-dir​

  • Padrão: node_modules/.pnpm
  • Tipo: caminho

O diretório com links para o armazenamento. Todas as dependências diretas e indiretas do projeto estão vinculadas a este diretório.

Essa é uma configuração útil que pode resolver problemas com caminhos longos no Windows. Se você tiver algumas dependências com caminhos muito longos, você pode selecionar um armazenamento virtual na raiz da sua unidade (por exemplo, C:\my-project-store).

Ou você pode defiinr o armazenamento virtual como .pnpm e adicioná-lo a .gitignore. Isto tornará os rastreamentos de pilha mais limpos, pois os caminhos para as dependências estarão um diretório acima.

NOTA: o armazenamento virtual não pode ser compartilhado entre vários projetos. Cada projeto deve ter seu próprio armazenamento virtual (exceto em espaços de trabalho onde a raiz é compartilhada).

package-import-method​

  • Padrão: auto
  • Type: auto, hardlink, copy, clone, clone-or-copy

Controls the way packages are imported from the store (if you want to disable symlinks inside node_modules, then you need to change the node-linker setting, not this one).

  • auto - tente clonar pacotes da loja. Se a clonagem não for suportada, então os pacotes hardlink da loja. Se nem a clonagem nem a vinculação forem possíveis, volte a copiar
  • hardlink - pacotes de links rígidos da loja
  • clone-or-copy - tenta clonar pacotes a partir da store. Se a clonagem não é suportada, então volte para copia comum
  • copy - copia pacotes da loja
  • clone - pacotes clone (também conhecido como copy-on-write ou link de referência) da loja

A clonagem é a melhor maneira de escrever pacotes em node_modules. É o caminho mais rápido e seguro. Quando a clonagem é usada, você pode editar arquivos em seus node_modules e eles não serão modificados no armazenamento endereçável de conteúdo central.

Infelizmente, nem todos os sistemas de arquivos suportam clonagem. Recomendamos o uso de um sistema de arquivos copy-on-write (CoW) (por exemplo, Btrfs em vez de Ext4 no Linux) para obter a melhor experiência com pnpm.

modules-cache-max-age​

  • Padrão: 10080 (7 dias em minutos)
  • Tipo: número

O tempo em minutos após o qual os pacotes órfãos do diretório de módulos devem ser removidos. pnpm mantém um cache de pacotes no diretório de módulos. Isso aumenta a velocidade de instalação ao alternar ou fazer downgrade de dependências.

Configurações do arquivo de bloqueio​

lockfile​

  • Padrão: true
  • Tipo: Boolean

Quando definido como false, pnpm não lerá ou gerará o arquivo pnpm-lock.yaml.

prefer-frozen-lockfile​

  • Padrão: true
  • Tipo: Boolean

Quando definido como true e o pnpm-lock.yaml disponível satisfaça a diretiva de dependências no package.json, uma instalação headless é realizada. Uma instalação headless ignora toda a resolução de dependência, pois não precisa modificar o arquivo de bloqueio.

lockfile-include-tarball-url​

  • Padrão: low
  • Tipo: Boolean

Adiciona a URL completa ao tarball do pacote para cada entrada em pnpm-lock.yaml.

git-branch-lockfile​

  • Padrão: low
  • Tipo: Boolean

When set to true, the generated lockfile name after installation will be named based on the current branch name to completely avoid merge conflicts. For example, if the current branch name is feature-foo, the corresponding lockfile name will be pnpm-lock.feature-foo.yaml instead of pnpm-lock.yaml. It is typically used in conjunction with the command line argument --merge-git-branch-lockfiles or by setting merge-git-branch-lockfiles-branch-pattern in the .npmrc file.

merge-git-branch-lockfiles-branch-pattern​

  • Default: null
  • Type: Array or null

This configuration matches the current branch name to determine whether to merge all git branch lockfile files. By default, you need to manually pass the --merge-git-branch-lockfiles command line parameter. This configuration allows this process to be automatically completed.

Por exemplo:

merge-git-branch-lockfiles-branch-pattern[]=main
merge-git-branch-lockfiles-branch-pattern[]=release*

You may also exclude patterns using !.

Configurações de Autenticação & Registro​

registry​

A URL base do pacote no registro npm (barra no final incluída).

<escopo>:registry​

O registro npm que deve ser usado para pacotes do escopo especificado. Por exemplo, definir @babel:registry=https://example.com/packages/npm/ irá forçar que quando você utilizar pnpm add @babel/core, ou qualquer pacote @babel, o pacote será obtido em https://example.com/packages/npm/ em vez do registro padrão.

<URL>:_authToken​

Define o token de autenticação bearer ao acessar o registro especificado. Por exemplo:

//registry.npmjs.org/:_authToken=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Você também pode usar uma variável de ambiente. Por exemplo:

//registry.npmjs.org/:_authToken=${NPM_TOKEN}

Or you may just use an environment variable directly, without changing .npmrc at all:

npm_config_//registry.npmjs.org/:_authToken=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

<URL>:tokenHelper​

Um token helper é um executável que gera um token de autenticação. Isso pode ser utilizado em situação onde o authToken não é um valor constante, mas é algo que é atualizado regularmente, onde um script ou outra ferramenta pode utilizar um refresh token para obter um novo token de acesso.

A configuração para o caminho do helper deve ser um caminho absoluto, sem argumentos. Para que seja seguro, só é permitido definir esse valor no arquivo .npmrc do usuário. Caso contrário, um projeto pode colocar um valor no .npmrc do projeto local e iniciar executáveis arbitrários.

Definindo um token helper para o registro padrão:

tokenHelper=/home/ivan/token-generator

Definindo um token helper para o registro especificado:

//registry.corp.com:tokenHelper=/home/ivan/token-generator

Configurações de Requisição​

ca​

  • Padrão: O certificado CA do npm
  • Tipo: String, Array ou null

O certificado de assinatura da Autoridade Certificadora que é confiável para conexões SSL com o registro. Os valores podem ser no formato PEM (também conhecido como "Base-64 encoded X.509 (.CER)"). Por exemplo:

ca="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"

Defina como "null" para permitir apenas registros conhecidos, ou um certificado de CA específico para confiar apenas naquela autoridade de assinatura específica.

Múltiplos CAs confiáveis podem especificados em um array de certificados:

ca[]="..."
ca[]="..."

Veja também a configuração strict-ssl.

cafile​

  • Padrão: null
  • Tipo: caminho

O caminho de um arquivo contendo um ou mais certificados de assinatura de Autoridade Certificadora. Semelhante à configuração de ca, mas permite vários CAs, assim como para que as informações da CA sejam armazenadas em um arquivo em vez de serem especificadas via CLI.

cert​

  • Padrão: null
  • Tipo: String

Um certificado de cliente a ser aprovado ao acessar o registro. Os valores devem estar em formato PEM (também conhecido como "Base-64 codificado X.509 (. CER)"). Por exemplo:

cert="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"

Não é o caminho para um arquivo de certificado (e não há nenhuma opção certfile).

key​

  • Padrão: null
  • Tipo: String

Uma chave de cliente a ser passada para acessar o registry. Os valores devem estar no formato PEM (X.509 codificado em Base-64 (.CER)). Por exemplo:

key="-----BEGIN PRIVATE KEY-----\nXXXX\nXXXX\n-----END PRIVATE KEY-----"

Não é o caminho para um arquivo de chave (e não existe uma opção keyfile).

Essa configuração contém informações confidenciais. Não o grave em um arquivo local .npmrc confirmado no repositório.

git-shallow-hosts​

  • Padrão: ['github.com', 'gist.github.com', 'gitlab.com', 'bitbucket.com', 'bitbucket.org']
  • Tipo: Boolean

Ao buscar dependências que são repositórios Git, se o host estiver listado nesta configuração, o pnpm usará clonagem superficial para buscar apenas o commit necessário, não todo o histórico.

https-proxy​

  • Padrão: null
  • Tipo: url

Um proxy a ser usado para solicitações HTTPS de saída. Se as variáveis de ambiente HTTPS_PROXY, https_proxy, HTTP_PROXY ou http_proxy forem definidas, seus valores serão usados em vez disso.

If your proxy URL contains a username and password, make sure to URL-encode them. Por exemplo:

https-proxy=https://use%21r:pas%2As@my.proxy:1234/foo

Do not encode the colon (:) between the username and password.

http-proxy​

proxy​

  • Padrão: null
  • Tipo: url

Um proxy a ser usado para solicitações http de saída. Se as variáveis de ambiente HTTP_PROXY ou http_proxy forem definidas, as configurações de proxy serão respeitadas pela biblioteca de solicitação subjacente.

local-address​

  • Padrão: ** undefined **
  • Tipo: Endereço IP

O endereço IP da interface local a ser usada ao fazer conexões com o registro npm.

maxsockets​

  • Padrão: network-concurrency x 3
  • Tipo: Number

O número máximo de conexões a serem usadas por origem (combinação protocolo/host/porta [protocol/host/port]).

noproxy​

  • Padrão: null
  • Tipo: String

Uma sequência de extensões de domínio separada por vírgulas para as quais um proxy não deve ser usado.

strict-ssl​

  • Valor padrão: false
  • Tipo: Boolean

Se deve ou não fazer a validação da chave SSL ao fazer solicitações ao registro via HTTPS.

Veja também a opção ca.

network-concurrency​

  • Padrão: 16
  • Tipo: Number

Controla o número máximo de solicitações HTTP(S) a serem processadas simultaneamente.

fetch-retries​

  • Padrão: 2
  • Tipo: Number

Quantas vezes tentar novamente se o pnpm falhar na busca do registro.

fetch-retry-factor​

  • Padrão: 10
  • Tipo: Number

O fator exponencial para recuar novamente.

fetch-retry-mintimeout​

  • Padrão: 10000 (10 segundos)
  • Tipo: Number

O tempo limite mínimo (base) para repetir solicitações.

fetch-retry-maxtimeout​

  • Padrão: 60000 (1 minuto)
  • Tipo: Number

O tempo limite máximo de fallback para garantir que o fator de repetição não torne as solicitações muito longas.

fetch-timeout​

  • Padrão: 60000 (1 minuto)
  • Tipo: Number

A quantidade máxima de tempo para aguardar a conclusão das solicitações HTTP.

Configurações de dependência de pares​

auto-install-peers​

  • Valor padrão: false
  • Tipo: Boolean

Quando true, quaisquer dependências de peer não opcionais ausentes são instaladas automaticamente.

Version Conflicts​

If there are conflicting version requirements for a peer dependency from different packages, pnpm will not install any version of the conflicting peer dependency automatically. Instead, a warning is printed. For example, if one dependency requires react@^16.0.0 and another requires react@^17.0.0, these requirements conflict, and no automatic installation will occur.

Conflict Resolution​

In case of a version conflict, you'll need to evaluate which version of the peer dependency to install yourself, or update the dependencies to align their peer dependency requirements.

dedupe-peer-dependents​

  • Valor padrão: false
  • Tipo: Boolean

When this setting is set to true, packages with peer dependencies will be deduplicated after peers resolution.

For instance, let's say we have a workspace with two projects and both of them have webpack in their dependencies. webpack has esbuild in its optional peer dependencies, and one of the projects has esbuild in its dependencies. In this case, pnpm will link two instances of webpack to the node_modules/.pnpm directory: one with esbuild and another one without it:

node_modules
  .pnpm
    webpack@1.0.0_esbuild@1.0.0
    webpack@1.0.0
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
    esbuild

This makes sense because webpack is used in two projects, and one of the projects doesn't have esbuild, so the two projects cannot share the same instance of webpack. However, this is not what most developers expect, especially since in a hoisted node_modules, there would only be one instance of webpack. Therefore, you may now use the dedupe-peer-dependents setting to deduplicate webpack when it has no conflicting peer dependencies (explanation at the end). In this case, if we set dedupe-peer-dependents to true, both projects will use the same webpack instance, which is the one that has esbuild resolved:

node_modules
  .pnpm
    webpack@1.0.0_esbuild@1.0.0
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
    esbuild

What are conflicting peer dependencies? By conflicting peer dependencies we mean a scenario like the following one:

node_modules
  .pnpm
    webpack@1.0.0_react@16.0.0_esbuild@1.0.0
    webpack@1.0.0_react@17.0.0
project1
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0/node_modules/webpack
    react (v17)
project2
  node_modules
    webpack -> ../../node_modules/.pnpm/webpack@1.0.0_esbuild@1.0.0/node_modules/webpack
    esbuild
    react (v16)

In this case, we cannot dedupe webpack as webpack has react in its peer dependencies and react is resolved from two different versions in the context of the two projects.

strict-peer-dependencies​

  • Padrão: low
  • Tipo: Boolean

Se estiver habilitado, os comandos falharão se houver uma dependência de peer ausente ou inválida na árvore.

resolve-peers-from-workspace-root​

  • Valor padrão: false
  • Tipo: Boolean

When enabled, dependencies of the root workspace project are used to resolve peer dependencies of any projects in the workspace. It is a useful feature as you can install your peer dependencies only in the root of the workspace, and you can be sure that all projects in the workspace use the same versions of the peer dependencies.

Configurações da CLI​

[no-]color​

  • Padrão: auto
  • Tipo: auto, always, never

Controla as cores na saída.

  • auto - a saída usa cores quando a saída padrão é um terminal ou TTY.
  • always - ignore a diferença entre terminais e pipes. Você raramente vai querer isso; na maioria dos cenários, se você quiser códigos de cores em sua saída redirecionada, você pode passar um sinalizador --color para o comando pnpm para forçá-lo a usar códigos de cores. A configuração padrão é quase sempre o que você deseja.
  • never - desativa as cores. Esta é a configuração usada por --no-color.

loglevel​

  • Padrão: info
  • Tipo: debug, info, warn, error

Quaisquer logs no nível ou acima dele serão mostrados. Em vez disso, você pode passar --silent para desativar todos os logs de saída.

use-beta-cli​

  • Padrão: low
  • Tipo: Boolean

Opção experimental que habilita recursos beta da CLI. This means that you may get some changes to the CLI functionality that are breaking changes, or potentially bugs.

recursive-install​

  • Valor padrão: false
  • Tipo: Boolean

If this is enabled, the primary behaviour of pnpm install becomes that of pnpm install -r, meaning the install is performed on all workspace or subdirectory packages.

Else, pnpm install will exclusively build the package in the current directory.

engine-strict​

  • Padrão: low
  • Tipo: Boolean

If this is enabled, pnpm will not install any package that claims to not be compatible with the current Node version.

Regardless of this configuration, installation will always fail if a project (not a dependency) specifies an incompatible version in its engines field.

npm-path​

  • Tipo: caminho

The location of the npm binary that pnpm uses for some actions, like publishing.

Configurações de compilação​

ignore-scripts​

  • Padrão: low
  • Tipo: Boolean

Não execute nenhum script definido no package.json do projeto e nas suas dependências.

nota

Esta flag não evita a execução do .pnpmfile.cjs

ignore-dep-scripts​

  • Padrão: low
  • Tipo: Boolean

Do not execute any scripts of the installed packages. Scripts of the projects are executed.

child-concurrency​

  • Padrão: 5
  • Tipo: Number

The maximum number of child processes to allocate simultaneously to build node_modules.

side-effects-cache​

  • Valor padrão: false
  • Tipo: Boolean

Use and cache the results of (pre/post)install hooks.

side-effects-cache-readonly​

  • Padrão: low
  • Tipo: Boolean

Only use the side effects cache if present, do not create it for new packages.

unsafe-perm​

  • Padrão: false se executar como root; caso contrário, true
  • Tipo: Boolean

Set to true to enable UID/GID switching when running package scripts. If set explicitly to false, then installing as a non-root user will fail.

Configurações do Node.js​

use-node-version​

  • Padrão: ** undefined **
  • Tipo: semver

Specifies which exact Node.js version should be used for the project's runtime. pnpm will automatically install the specified version of Node.js and use it for running pnpm run commands or the pnpm node command.

Isso pode ser usado em vez de .nvmrc e nvm. Instead of the following .nvmrc file:

16.16.0

Use este arquivo .npmrc:

use-node-version=16.16.0

node-version​

  • Padrão: o valor retornado por node -v, sem o prefixo v
  • Tipo: semver

A versão do Node.js a ser usada ao verificar a configuração engines de um pacote.

Se você deseja impedir que os colaboradores do seu projeto adicionem novas dependências incompatíveis, use node-version e engine-strict em um arquivo .npmrc na raiz do projeto:

node-version=12.22.0
engine-strict=true

This way, even if someone is using Node.js v16, they will not be able to install a new dependency that doesn't support Node.js v12.22.0.

node-mirror:<releaseDir>​

  • Default: https://nodejs.org/download/<releaseDir>/
  • Type: URL

Sets the base URL for downloading Node.js. The <releaseDir> portion of this setting can be any directory from https://nodejs.org/download: release, rc, nightly, v8-canary, etc.

Here is how pnpm may be configured to download Node.js from Node.js mirror in China:

node-mirror:release=https://npmmirror.com/mirrors/node/
node-mirror:rc=https://npmmirror.com/mirrors/node-rc/
node-mirror:nightly=https://npmmirror.com/mirrors/node-nightly/

Configurações da Workspace (Área de Trabalho)​

  • Valor padrão: false
  • Tipo: true, false, deep

If this is enabled, locally available packages are linked to node_modules instead of being downloaded from the registry. This is very convenient in a monorepo. If you need local packages to also be linked to subdependencies, you can use the deep setting.

Else, packages are downloaded and installed from the registry. However, workspace packages can still be linked by using the workspace: range protocol.

prefer-workspace-packages​

  • Padrão: low
  • Tipo: Boolean

If this is enabled, local packages from the workspace are preferred over packages from the registry, even if there is a newer version of the package in the registry.

This setting is only useful if the workspace doesn't use save-workspace-protocol.

shared-workspace-lockfile​

  • Valor padrão: false
  • Tipo: Boolean

If this is enabled, pnpm creates a single pnpm-lock.yaml file in the root of the workspace. This also means that all dependencies of workspace packages will be in a single node_modules (and get symlinked to their package node_modules folder for Node's module resolution).

Advantages of this option:

  • every dependency is a singleton
  • faster installations in a monorepo
  • fewer changes in code reviews as they are all in one file
nota

Even though all the dependencies will be hard linked into the root node_modules, packages will have access only to those dependencies that are declared in their package.json, so pnpm's strictness is preserved. This is a result of the aforementioned symbolic linking.

save-workspace-protocol​

  • Default: rolling
  • Type: true, false, rolling

Essa configuração controla como as dependências vinculadas do workspace são adicionadas ao package.json.

Se foo@1.0.0 estiver no workspace e você executar pnpm add foo em outro projeto do workspace, veja abaixo como foo será adicionado ao campo de dependências. A configuração save-prefix também influencia como a especificação é criada.

save-workspace-protocolsave-prefixspec
false''1.0.0
false'~'~1.0.0
false'^'^1.0.0
true''workspace:1.0.0
true'~'workspace:~1.0.0
true'^'workspace:^1.0.0
rolling''workspace:*
rolling'~'workspace:~
rolling'^'workspace:^

include-workspace-root​

  • Padrão: low
  • Tipo: Boolean

Ao executar comandos recursivamente em um workspace, também executa no projeto do workspace raiz.

ignore-workspace-cycles​

Adicionado em: v8.1.0

  • Padrão: low
  • Tipo: Boolean

When set to true, no workspace cycle warnings will be printed.

disallow-workspace-cycles​

Adicionado em: v8.9.0

  • Padrão: low
  • Tipo: Boolean

When set to true, installation will fail if the workspace has cycles.

Outras configurações​

use-running-store-server​

  • Padrão: low
  • Tipo: Boolean

Só permite a instalação com um servidor de armazenamento. Se nenhum servidor de armazenamento estiver em execução, a instalação falhará.

save-prefix​

  • Default: '^'
  • Type: '^', '~', ''

Configure como as versões dos pacotes instalados em um arquivo package.json recebem o prefixo.

Por exemplo, se um pacote tem a versão 1.2.3, por padrão sua versão é definida como ^1.2.3 permitindo que atualizações do tipo minor sejam realizadas para esse pacote, mas após utilizar pnpm config set save-prefix='~' a versão é definida para ~1.2.3 que permite apenas atualizações do tipo patch.

Essa configuração é ignorada quando o pacote adicionado tem um intervalo especificado. Por exemplo, pnpm add foo@2 definirá a versão de foo no package.json como 2, independentemente do valor de save prefix.

tag​

  • Padrão: latest
  • Tipo: String

Se você utilizar o comando pnpm add em um pacote e não fornecer uma versão específica, ele instalará o pacote na versão registrada sob a tag desta configuração.

Isso também define a tag que é adicionada ao package@version especificado pelo comando pnpm tag se nenhuma tag explícita for fornecida.

global-dir​

  • Padrão:
    • Se a variável de ambiente $XDG_DATA_HOME estiver definida, então $XDG_DATA_HOME/pnpm/store
    • No Windows: ~/AppData/Local/pnpm/global
    • No macOS: ~/Library/pnpm/store
    • No Linux: ~/.local/share/pnpm/store
  • Tipo: caminho

Especifica um diretório personalizado para armazenar pacotes globais.

global-bin-dir​

  • Padrão:
    • Se a variável de ambiente $XDG_DATA_HOME estiver definida, então $XDG_DATA_HOME/pnpm
    • On Windows: ~/AppData/Local/pnpm
    • On macOS: ~/Library/pnpm
    • On Linux: ~/.local/share/pnpm
  • Tipo: caminho

Permite definir o diretório de destino para os arquivos bin dos pacotes instalados globalmente.

state-dir​

  • Padrão:
    • Se a variável de ambiente $XDG_STATE_HOME estiver definida, então $XDG_STATE_HOME/pnpm
    • No Windows: ~/AppData/Local/pnpm-state
    • No macOS: ~/.pnpm-state
    • No Linux: ~/.local/state/pnpm
  • Tipo: caminho

O diretório em que pnpm cria o arquivo pnpm-state.json que é usado atualmente apenas pelo verificador de atualização.

cache-dir​

  • Padrão:
    • Se a variável de ambiente $XDG_CACHE_HOME estiver definida, então $XDG_CACHE_HOME/pnpm
    • No Windows: ~/AppData/Local/pnpm-cache
    • No macOS: ~/Library/Caches/pnpm
    • No Linux: ~/.cache/pnpm
  • Tipo: caminho

O local do cache de metadados do pacote.

use-stderr​

  • Padrão: low
  • Tipo: Boolean

Quando true, toda a saída é gravada em stderr.

update-notifier​

  • Valor padrão: false
  • Tipo: Boolean

Define como false para suprimir a notificação de atualização ao usar uma versão mais antiga do pnpm do que a mais recente.

prefer-symlinked-executables​

  • Default: true, when node-linker is set to hoisted and the system is POSIX
  • Tipo: Boolean

Create symlinks to executables in node_modules/.bin instead of command shims. This setting is ignored on Windows, where only command shims work.

verify-store-integrity​

  • Valor padrão: false
  • Tipo: Boolean

By default, if a file in the store has been modified, the content of this file is checked before linking it to a project's node_modules. If verify-store-integrity is set to false, files in the content-addressable store will not be checked during installation.

ignore-compatibility-db​

  • Padrão: low
  • Tipo: Boolean

During installation the dependencies of some packages are automatically patched. If you want to disable this, set this config to false.

The patches are applied from Yarn's @yarnpkg/extensions package.

resolution-mode​

  • Default: highest (was lowest-direct from v8.0.0 to v8.6.12)
  • Type: highest, time-based, lowest-direct

When resolution-mode is set to time-based, dependencies will be resolved the following way:

  1. Direct dependencies will be resolved to their lowest versions. So if there is foo@^1.1.0 in the dependencies, then 1.1.0 will be installed.
  2. Subdependencies will be resolved from versions that were published before the last direct dependency was published.

With this resolution mode installations with warm cache are faster. It also reduces the chance of subdependency hijacking as subdependencies will be updated only if direct dependencies are updated.

This resolution mode works only with npm's full metadata. So it is slower in some scenarios. However, if you use Verdaccio v5.15.1 or newer, you may set the registry-supports-time-field setting to true, and it will be really fast.

When resolution-mode is set to lowest-direct, direct dependencies will be resolved to their lowest versions.

registry-supports-time-field​

  • Padrão: low
  • Tipo: Boolean

Set this to true if the registry that you are using returns the "time" field in the abbreviated metadata. As of now, only Verdaccio from v5.15.1 supports this.

extend-node-path​

  • Valor padrão: false
  • Tipo: Boolean

When false, the NODE_PATH environment variable is not set in the command shims.

deploy-all-files​

  • Padrão: low
  • Tipo: Boolean

When deploying a package or installing a local package, all files of the package are copied. By default, if the package has a "files" field in the package.json, then only the listed files and directories are copied.

dedupe-direct-deps​

Added in: v8.1.0

  • Padrão: low
  • Tipo: Boolean

When set to true, dependencies that are already symlinked to the root node_modules directory of the workspace will not be symlinked to subproject node_modules directories.

dedupe-injected-deps​

Added in: v8.13.1

  • Padrão: low
  • Tipo: Boolean

When this setting is enabled, dependencies that are injected will be symlinked from the workspace whenever possible. If the dependent project and the injected dependency reference the same peer dependencies, then it is not necessary to physically copy the injected dependency into the dependent's node_modules; a symlink is sufficient.