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

O comandopnpm 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 arquivopnpm-workspace.yaml)
• arquivo de configuração por usuário (~/.npmrc)
• arquivo de configuração global (/etc/npmrc)

Todos os arquivos.npmrc sãolistas formatadas em INI de parâmetroschave = 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 seNAME não estiver definido.${NAME:-fallback} retornaráfallback seNAME não estiver definido ou for uma string vazia.

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

hoist​

• Valor padrão:false
• Tipo:Boolean

Quandotrue, todas as dependências são elevadas paranode_modules/.pnpm/node_modules. Isso torna as dependências não listadas acessíveis a todos os pacotes dentro danode_modules.

hoist-workspace-packages​

Added in: v8.14.0

• Padrão:low
• Tipo:Boolean

Whentrue, 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 andpublic-hoist-pattern).

hoist-pattern​

• Valor padrão:false
• Tipo:Boolean

Diz ao pnpm quais pacotes devem ser elevados para anode_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*

You may also exclude patterns from hoisting using!.

Por exemplo:

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

public-hoist-pattern​

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

Ao contrário dehoist-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: Definirshamefully-hoist paratrue é o mesmo que definirpublic-hoist-pattern para*.

You may also exclude patterns from hoisting using!.

Por exemplo:

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

shamefully-hoist​

• Padrão:low
• Tipo:Boolean

Por padrão, o pnpm cria umanode_modules semi estrita, o que significa que as dependências têm acesso a dependências não declaradas, mas os módulos fora danode_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 danode_modules, você pode definir essa opção comotrue para elevar elas para você.

Configurações de Módulos Node​

store-dir​

• Padrão:
  • If the$PNPM_HOME env variable is set, then$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 denode_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 emnode_modules/.pnpm.
• hoisted - umnode_modules limpo sem links simbólicos é criado. O mesmo quenode_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 hoistednode_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 - semnode_modules. Plug'n'Play é uma estratégia inovadora para Node que éutilizada pelo Yarn Berry. Recomenda-se também definir a configuraçãosymlink parafalse ao usarpnp como seu vinculador.

symlink​

• Valor padrão:false
• Tipo:Boolean

Quando osymlink é configurado parafalse, o pnpm cria o diretório virtual da store sem symlinks. É uma configuração útil junto comnode-linker=pnp.

enable-modules-dir​

• Valor padrão:false
• Tipo:Boolean

Quandofalse, 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 insidenode_modules, then you need to change thenode-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 comocopy-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​

• Valor padrão:false
• Tipo:Boolean

When set tofalse, pnpm won't read or generate apnpm-lock.yaml file.

prefer-frozen-lockfile​

• Valor padrão:false
• Tipo:Boolean

When set totrue and the availablepnpm-lock.yaml satisfies thepackage.json dependencies directive, a headless installation is performed. A headless installation skips all dependency resolution as it does not need to modify the lockfile.

lockfile-include-tarball-url​

• Padrão:low
• Tipo:Boolean

Add the full URL to the package's tarball to every entry inpnpm-lock.yaml.

git-branch-lockfile​

• Padrão:low
• Tipo:Boolean

When set totrue, 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 isfeature-foo, the corresponding lockfile name will bepnpm-lock.feature-foo.yaml instead ofpnpm-lock.yaml. It is typically used in conjunction with the command line argument--merge-git-branch-lockfiles or by settingmerge-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​

• Padrão:https://registry.npmjs.org/
• Tipo:url

The base URL of the npm package registry (trailing slash included).

<escopo>:registry​

The npm registry that should be used for packages of the specified scope. For example, setting@babel:registry=https://example.com/packages/npm/ will enforce that when you usepnpm add @babel/core, or any@babel scoped package, the package will be fetched fromhttps://example.com/packages/npm instead of the default registry.

<URL>:_authToken​

Define the authentication bearer token to use when accessing the specified registry. Por exemplo:

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

You may also use an environment variable. 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​

A token helper is an executable which outputs an auth token. This can be used in situations where the authToken is not a constant value but is something that refreshes regularly, where a script or other tool can use an existing refresh token to obtain a new access token.

The configuration for the path to the helper must be an absolute path, with no arguments. In order to be secure, it is only permitted to set this value in the user.npmrc. Otherwise a project could place a value in a project's local.npmrc and run arbitrary executables.

Setting a token helper for the default registry:

tokenHelper=/home/ivan/token-generator

Setting a token helper for the specified registry:

//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çãostrict-ssl.

cafile​

• Default:null
• Tipo:caminho

O caminho de um arquivo contendo um ou mais certificados de assinatura de Autoridade Certificadora. Semelhante à configuração deca, 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​

• Default: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çãocertfile).

key​

• Default: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çãokeyfile).

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​

• Default:null
• Tipo:url

Um proxy a ser usado para solicitações HTTPS de saída. Se as variáveis de ambienteHTTPS_PROXY,https_proxy,HTTP_PROXY ouhttp_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​

• Default: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​

• Default: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çãoca.

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

Quandotrue, 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 requiresreact@^16.0.0 and another requiresreact@^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 totrue, 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 havewebpack in their dependencies.webpack hasesbuild in its optional peer dependencies, and one of the projects hasesbuild in its dependencies. In this case, pnpm will link two instances ofwebpack to thenode_modules/.pnpm directory: one withesbuild 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 becausewebpack is used in two projects, and one of the projects doesn't haveesbuild, so the two projects cannot share the same instance ofwebpack. However, this is not what most developers expect, especially since in a hoistednode_modules, there would only be one instance ofwebpack. Therefore, you may now use thededupe-peer-dependents setting to deduplicatewebpack when it has no conflicting peer dependencies (explanation at the end). In this case, if we setdedupe-peer-dependents totrue, both projects will use the samewebpack instance, which is the one that hasesbuild 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 dedupewebpack aswebpack hasreact in its peer dependencies andreact 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 ofpnpm install becomes that ofpnpm 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 itsengines 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

Do not execute any scripts defined in the projectpackage.json and its dependencies.

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 runningpnpm run commands or thepnpm node command.

Isso pode ser usado em vez de.nvmrc envm. 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 pornode -v, sem o prefixo v
• Tipo:semver

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

Se você deseja impedir que os colaboradores do seu projeto adicionem novas dependências incompatíveis, usenode-version eengine-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 fromhttps://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)​

link-workspace-packages​

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

If this is enabled, locally available packages are linked tonode_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 thedeep setting.

Else, packages are downloaded and installed from the registry. However, workspace packages can still be linked by using theworkspace: 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 usesave-workspace-protocol.

shared-workspace-lockfile​

• Valor padrão:false
• Tipo:Boolean

If this is enabled, pnpm creates a singlepnpm-lock.yaml file in the root of the workspace. This also means that all dependencies of workspace packages will be in a singlenode_modules (and get symlinked to their packagenode_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

save-workspace-protocol​

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

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

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

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​

Added in: v8.1.0

• Padrão:low
• Tipo:Boolean

When set totrue, no workspace cycle warnings will be printed.

disallow-workspace-cycles​

Added in: v8.9.0

• Padrão:low
• Tipo:Boolean

When set totrue, 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 arquivopackage.json recebem o prefixo.

Por exemplo, se um pacote tem a versão1.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 utilizarpnpm 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 defoo nopackage.json como2, independentemente do valor desave prefix.

tag​

• Padrão:latest
• Tipo:String

Se você utilizar o comandopnpm 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 aopackage@version especificado pelo comandopnpm 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 arquivopnpm-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 comofalse 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, whennode-linker is set tohoisted and the system is POSIX
• Tipo:Boolean

Create symlinks to executables innode_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'snode_modules. Ifverify-store-integrity is set tofalse, 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 tofalse.

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

resolution-mode​

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

Whenresolution-mode is set totime-based, dependencies will be resolved the following way:

1. Direct dependencies will be resolved to their lowest versions. So if there isfoo@^1.1.0 in the dependencies, then1.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'sfull metadata. So it is slower in some scenarios. However, if you useVerdaccio v5.15.1 or newer, you may set theregistry-supports-time-field setting totrue, and it will be really fast.

Whenresolution-mode is set tolowest-direct, direct dependencies will be resolved to their lowest versions.

registry-supports-time-field​

• Padrão:low
• Tipo:Boolean

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

extend-node-path​

• Valor padrão:false
• Tipo:Boolean

Whenfalse, theNODE_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 thepackage.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 totrue, dependencies that are already symlinked to the rootnode_modules directory of the workspace will not be symlinked to subprojectnode_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'snode_modules; a symlink is sufficient.