Settings (pnpm-workspace.yaml)
pnpm gets its configuration from the command line, environment variables, pnpm-workspace.yaml
, and
.npmrc
files.
The pnpm config
command can be used to read and edit the contents of the project and global configuration files.
The relevant configuration files are:
- Per-project configuration file:
/path/to/my/project/pnpm-workspace.yaml
- Global configuration file:
~/.config/pnpm/rc
(an INI-formatted list ofkey = value
parameters)
Authorization-related settings are handled by npm's configuration system. So, pnpm config set registry=<value>
will actually save the setting to npm's global configuration file.
Values in the configuration files may contain env variables using the ${NAME}
syntax. As variáveis env também podem ser especificadas com valores padrão. Using ${NAME-fallback}
will return fallback
if NAME
isn't set. ${NAME:-fallback}
will return fallback
if NAME
isn't set, or is an empty string.
Dependency Resolution
overrides
This field allows you to instruct pnpm to override any dependency in the dependency graph. This is useful for enforcing all your packages to use a single version of a dependency, backporting a fix, replacing a dependency with a fork, or removing an unused dependency.
Note that the overrides field can only be set at the root of the project.
An example of the overrides
field:
overrides:
"foo": "^1.0.0"
"quux": "npm:@myorg/quux@^1.0.0"
"bar@^2.1.0": "3.0.0"
"qar@1>zoo": "2"
You may specify the package the overridden dependency belongs to by
separating the package selector from the dependency selector with a ">", for
example qar@1>zoo
will only override the zoo
dependency of qar@1
, not for
any other dependencies.
An override may be defined as a reference to a direct dependency's spec.
This is achieved by prefixing the name of the dependency with a $
:
{
"dependencies": {
"foo": "^1.0.0"
}
}
overrides:
foo: "$foo"
The referenced package does not need to match the overridden one:
overrides:
bar: "$foo"
If you find that your use of a certain package doesn't require one of its dependencies, you may use -
to remove it. For example, if package foo@1.0.0
requires a large package named bar
for a function that you don't use, removing it could reduce install time:
overrides:
"foo@1.0.0>bar": "-"
This feature is especially useful with optionalDependencies
, where most optional packages can be safely skipped.
packageExtensions
The packageExtensions
fields offer a way to extend the existing package definitions with additional information. For example, if react-redux
should have react-dom
in its peerDependencies
but it has not, it is possible to patch react-redux
using packageExtensions
:
packageExtensions:
react-redux:
peerDependencies:
react-dom: "*"
The keys in packageExtensions
are package names or package names and semver ranges, so it is possible to patch only some versions of a package:
packageExtensions:
react-redux@1:
peerDependencies:
react-dom: "*"
The following fields may be extended using packageExtensions
: dependencies
, optionalDependencies
, peerDependencies
, and peerDependenciesMeta
.
A bigger example:
packageExtensions:
express@1:
optionalDependencies:
typescript: "2"
fork-ts-checker-webpack-plugin:
dependencies:
"@babel/core": "1"
peerDependencies:
eslint: ">= 6"
peerDependenciesMeta:
eslint: {
optional: true
Together with Yarn, we maintain a database of packageExtensions
to patch broken packages in the ecosystem.
If you use packageExtensions
, consider sending a PR upstream and contributing your extension to the @yarnpkg/extensions
database.
allowedDeprecatedVersions
This setting allows muting deprecation warnings of specific packages.
Exemplo:
allowedDeprecatedVersions:
express: "1"
request: "*"
With the above configuration pnpm will not print deprecation warnings about any version of request
and about v1 of express
.
updateConfig
updateConfig.ignoreDependencies
Sometimes you can't update a dependency. For instance, the latest version of the dependency started to use ESM but your project is not yet in ESM. Annoyingly, such a package will be always printed out by the pnpm outdated
command and updated, when running pnpm update --latest
. However, you may list packages that you don't want to upgrade in the ignoreDependencies
field:
updateConfig: {
ignoreDependencies:
- load-json-file
Patterns are also supported, so you may ignore any packages from a scope: @babel/*
.
supportedArchitectures
You can specify architectures for which you'd like to install optional dependencies, even if they don't match the architecture of the system running the install.
For example, the following configuration tells to install optional dependencies for Windows x64:
supportedArchitectures:
os:
- win32
cpu:
- x64
Whereas this configuration will install optional dependencies for Windows, macOS, and the architecture of the system currently running the install. It includes artifacts for both x64 and arm64 CPUs:
supportedArchitectures:
os:
- win32
- darwin
- current
cpu:
- x64
- arm64
Additionally, supportedArchitectures
also supports specifying the libc
of the system.
ignoredOptionalDependencies
If an optional dependency has its name included in this array, it will be skipped. Por exemplo:
ignoredOptionalDependencies:
- fsevents
- "@esbuild/*"
Configurações de elevação de dependência
hoist
- Default: true
- Type: boolean
When true
, all dependencies are hoisted to node_modules/.pnpm/node_modules
. This makes
unlisted dependencies accessible to all packages inside node_modules
.
hoistWorkspacePackages
- Default: true
- Type: 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 (hoistPattern
and publicHoistPattern
).
hoistPattern
- Default: ['*']
- Type: string[]
Tells pnpm which packages should be hoisted to 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:
hoistPattern:
- "*eslint*"
- "*babel*"
You may also exclude patterns from hoisting using !
.
Por exemplo:
hoistPattern:
- "*types*"
- "!@types/react"
publicHoistPattern
- Default: []
- Type: string[]
Unlike hoistPattern
, which hoists dependencies to a hidden modules directory
inside the virtual store, publicHoistPattern
hoists dependencies matching
the pattern to the root modules directory. 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:
publicHoistPattern:
- "*plugin*"
Note: Setting shamefullyHoist
to true
is the same as setting
publicHoistPattern
to *
.
You may also exclude patterns from hoisting using !
.
Por exemplo:
publicHoistPattern:
- "*types*"
- "!@types/react"