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. The env variables may also be specified with default values. 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
Questo campo consente di indicare a pnpm di sovrascrivere qualsiasi dipendenza nel grafico delle dipendenze. 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.
Nota che il campo delle sostituzioni può essere impostato solo alla radice del progetto.
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.
Un override può essere definito come un riferimento alla specifica di una dipendenza diretta.
This is achieved by prefixing the name of the dependency with a $
:
{
"dependencies": {
"foo": "^1.0.0"
}
}
overrides:
foo: "$foo"
Il pacchetto di riferimento non deve necessariamente corrispondere a quello sovrascritto:
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
.
Un esempio più grande:
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
Questa impostazione consente di disattivare gli avvisi di deprecazione di pacchetti specifici.
Esempio:
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. Ad esempio:
ignoredOptionalDependencies:
- fsevents
- "@esbuild/*"
Impostazioni di inserimento delle dipendenze
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
. Per
impostazione predefinita, tutti i pacchetti sono installati - tuttavia, se sai che solo alcuni pacchetti difettosi
hanno dipendenze fantasma, è possibile utilizzare questa opzione per installare esclusivamente
le dipendenze fantasma (raccomandato).
Ad esempio:
hoistPattern:
- "*eslint*"
- "*babel*"
You may also exclude patterns from hoisting using !
.
Ad esempio:
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. Installare nella cartella radice dei moduli
significa che il codice dell'applicazione avrà accesso alle dipendenze fantasma,
anche se modificano la strategia di risoluzione in modo improprio.
Questa impostazione è utile quando si ha a che fare con alcuni strumenti collegabili difettosi che non risolvere correttamente le dipendenze.
Ad esempio:
publicHoistPattern:
- "*plugin*"
Note: Setting shamefullyHoist
to true
is the same as setting
publicHoistPattern
to *
.
You may also exclude patterns from hoisting using !
.
Ad esempio:
publicHoistPattern:
- "*types*"
- "!@types/react"
shamefullyHoist
- Default: false
- Type: Boolean
By default, pnpm creates a semistrict node_modules
, meaning dependencies have
access to undeclared dependencies but modules outside of node_modules
do not.
Con questo layout, la maggior parte dei pacchetti nell'ecosistema funzionano senza problemi.
However, if some tooling only works when the hoisted dependencies are in the
root of node_modules
, you can set this to true
to hoist them for you.
Impostazioni Node-Modules
modulesDir
- Default: node_modules
- Type: path
The directory in which dependencies will be installed (instead of
node_modules
).
nodeLinker
- Default: isolated
- Type: isolated, hoisted, pnp
Definisce quale linker dovrebbe essere usato per installare i pacchetti Node.
- isolated - dependencies are symlinked from a virtual store at
node_modules/.pnpm
. - hoisted - a flat
node_modules
without symlinks is created. Same as thenode_modules
created by npm or Yarn Classic. Una delle librerie di Yarn viene utilizzata per l'hoisting, quando viene utilizzata questa impostazione. Motivi legittimi per utilizzare questa impostazione:- I tuoi strumenti non funzionano bene con i collegamenti simbolici. A React Native project will most probably only work if you use a hoisted
node_modules
. - Il tuo progetto viene distribuito a un provider di hosting senza server. Alcuni provider senza server (ad esempio, AWS Lambda) non supportano i collegamenti simbolici. Una soluzione alternativa a questo problema consiste nel raggruppare l'applicazione prima della distribuzione.
- If you want to publish your package with
"bundledDependencies"
. - If you are running Node.js with the --preserve-symlinks flag.
- I tuoi strumenti non funzionano bene con i collegamenti simbolici. A React Native project will most probably only work if you use a hoisted
- pnp - no
node_modules
. Plug'n'Play is an innovative strategy for Node that is used by Yarn Berry. It is recommended to also setsymlink
setting tofalse
when usingpnp
as your linker.
symlink
- Default: true
- Type: Boolean
When symlink
is set to false
, pnpm creates a virtual store directory without
any symlinks. It is a useful setting together with nodeLinker=pnp
.
enableModulesDir
- Default: true
- Type: Boolean
When false
, pnpm will not write any files to the modules directory
(node_modules
). Questo è utile quando la cartella dei moduli è montata con
filesystem nello spazio utente (FUSE). There is an experimental CLI that allows you to
mount a modules directory with FUSE: @pnpm/mount-modules.
virtualStoreDir
- Default: node_modules/.pnpm
- Types: path
La cartella con i collegamenti all'archivio. Tutte le dipendenze dirette e indirette del progetto sono collegate in questa cartella.
Questa è un'impostazione utile che può risolvere problemi con percorsi lunghi su Windows. If
you have some dependencies with very long paths, you can select a virtual store
in the root of your drive (for instance C:\my-project-store
).
Or you can set the virtual store to .pnpm
and add it to .gitignore
. Questo
renderà gli stacktrace più puliti poiché i percorsi delle dipendenze saranno di una cartella
più in alto.
NOTE: the virtual store cannot be shared between several projects. Ogni progetto dovrebbe avere un proprio archivio virtuale (tranne negli spazi di lavoro dove è condivisa la radice).
virtualStoreDirMaxLength
- Predefinito:
- On Linux/macOS: 120
- On Windows: 60
- Types: number
Sets the maximum allowed length of directory names inside the virtual store directory (node_modules/.pnpm
). You may set this to a lower number if you encounter long path issues on Windows.
packageImportMethod
- Default: 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 nodeLinker setting, not this one).
- auto - try to clone packages from the store. Se la clonazione non è supportata collega i pacchetti dall'archivio. Se né la clonazione né il collegamento è possibile, esegue la copia
- hardlink - hard link packages from the store
- clone-or-copy - try to clone packages from the store. Se la clonazione non è supportata, allora torna alla copia
- copy - copy packages from the store
- clone - clone (AKA copy-on-write or reference link) packages from the store
La clonazione è il modo migliore per scrivere pacchetti in node_modules. È il modo più veloce e più sicuro. Quando viene utilizzata la clonazione, puoi modificare i file nei tuoi node_modules e non verranno modificati nell'archivio centrale indirizzabile al contenuto.
Sfortunatamente, non tutti i file system supportano la clonazione. Si consiglia di utilizzare un file system copy-on-write (CoW) (ad esempio, Btrfs invece di Ext4 su Linux) per la migliore esperienza con pnpm.
modulesCacheMaxAge
- Default: 10080 (7 days in minutes)
- Type: number
Il tempo in minuti dopo il quale i pacchetti orfani dalla cartella dei moduli devono essere rimossi. pnpm mantiene una cache dei pacchetti nella cartella dei moduli. Questa velocità di installazione aumenta quando si cambia ramo o si retrocedono delle dipendenze.
dlxCacheMaxAge
- Default: 1440 (1 day in minutes)
- Type: number
The time in minutes after which dlx cache expires. After executing a dlx command, pnpm keeps a cache that omits the installation step for subsequent calls to the same dlx command.
enableGlobalVirtualStore
Added in: v10.12.1
- Default: false (always false in CI)
- Type: Boolean
- Status: Experimental
When enabled, node_modules
contains only symlinks to a central virtual store, rather than to node_modules/.pnpm
. By default, this central store is located at <store-path>/links
(use pnpm store path
to find <store-path>
).
In the central virtual store, each package is hard linked into a directory whose name is the hash of its dependency graph. As a result, all projects on the system can symlink their dependencies from this shared location on disk. This approach is conceptually similar to how NixOS manages packages, using dependency graph hashes to create isolated and shareable package directories in the Nix store.
This should not be confused with the global content-addressable store. The actual package files are still hard linked from the content-addressable store—but instead of being linked directly into
node_modules/.pnpm
, they are linked into the global virtual store.
Using a global virtual store can significantly speed up installations when a warm cache is available. However, in CI environments (where caches are typically absent), it may slow down installation. If pnpm detects that it is running in CI, this setting is automatically disabled.
To support hoisted dependencies when using a global virtual store, pnpm relies on the NODE_PATH
environment variable. This allows Node.js to resolve packages from the hoisted node_modules
directory. However, this workaround does not work with ESM modules, because Node.js no longer respects NODE_PATH
when using ESM.
If your dependencies are ESM and they import packages not declared in their own package.json
(which is considered bad practice), you’ll likely run into resolution errors. There are two ways to fix this:
- Use packageExtensions to explicitly add the missing dependencies.
- Add the @pnpm/plugin-esm-node-path config dependency to your project. This plugin registers a custom ESM loader that restores
NODE_PATH
support for ESM, allowing hoisted dependencies to be resolved correctly.
Store Settings
storeDir
- Predefinito:
- If the $PNPM_HOME env variable is set, then $PNPM_HOME/store
- If the $XDG_DATA_HOME env variable is set, then $XDG_DATA_HOME/pnpm/store
- On Windows: ~/AppData/Local/pnpm/store
- On macOS: ~/Library/pnpm/store
- On Linux: ~/.local/share/pnpm/store
- Type: path
La posizione in cui tutti i pacchetti vengono salvati sul disco.
L'archivio dovrebbe essere sempre sullo stesso disco su cui sta avvenendo l'installazione,
quindi ci sarà un archivio per disco. Se è presente una directory home sul disco
corrente, l'archivio viene creato al suo interno. Se non c'è nessuna home sul disco,
allora l'archivio viene creato alla radice del filesystem. For
example, if installation is happening on a filesystem mounted at /mnt
,
then the store will be created at /mnt/.pnpm-store
. Lo stesso vale per i sistemi Windows.
È possibile impostare un archivio da un disco diverso, ma in tal caso pnpm copierà i pacchetti dallo store invece di collegarli, poiché i collegamenti fisici sono possibili solo sullo stesso filesystem.
verifyStoreIntegrity
- Default: true
- Type: 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 verifyStoreIntegrity
is set to false
, files in the content-addressable store will not be checked during installation.
useRunningStoreServer
Deprecated feature
- Default: false
- Type: Boolean
Consente l'installazione solo con un server di archiviazione. Se nessun server di archiviazione è in esecuzione, l'installazione fallirà.
strictStorePkgContentCheck
- Default: true
- Type: Boolean
Some registries allow the exact same content to be published under different package names and/or versions. This breaks the validity checks of packages in the store. To avoid errors when verifying the names and versions of such packages in the store, you may set the strictStorePkgContentCheck
setting to false
.
Impostazioni file di blocco
lockfile
- Default: true
- Type: Boolean
When set to false
, pnpm won't read or generate a pnpm-lock.yaml
file.
preferFrozenLockfile
- Default: true
- Type: Boolean
When set to true
and the available pnpm-lock.yaml
satisfies the
package.json
dependencies directive, a headless installation is performed. A
headless installation skips all dependency resolution as it does not need to
modify the lockfile.
lockfileIncludeTarballUrl
- Default: false
- Type: Boolean
Add the full URL to the package's tarball to every entry in pnpm-lock.yaml
.
gitBranchLockfile
- Default: false
- Type: 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 mergeGitBranchLockfilesBranchPattern
in the pnpm-workspace.yaml
file.
mergeGitBranchLockfilesBranchPattern
- 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.
Ad esempio:
mergeGitBranchLockfilesBranchPattern:
- main
- release*
You may also exclude patterns using !
.
peersSuffixMaxLength
- Default: 1000
- Type: number
Max length of the peer IDs suffix added to dependency keys in the lockfile. If the suffix is longer, it is replaced with a hash.
Registry & Authentication Settings
registry
- Default: https://registry.npmjs.org/
- Type: url
The base URL of the npm package registry (trailing slash included).
<scope>: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 use pnpm add @babel/core
, or any @babel
scoped
package, the package will be fetched from https://example.com/packages/npm
instead of the default registry.
<URL>:_authToken
Define the authentication bearer token to use when accessing the specified registry. Ad esempio:
//registry.npmjs.org/:_authToken=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
You may also use an environment variable. Ad esempio:
//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
Impostazioni richiesta
ca
- Default: The npm CA certificate
- Type: String, Array or null
Il certificato di firma dell'autorità di certificazione considerato attendibile per le connessioni SSL al registro. I valori devono essere in formato PEM (ovvero "X.509 codificato in base-64 (.CER)"). Ad esempio:
ca="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"
Imposta a null per consentire solo ai registrar noti o un certificato CA specifico di considerare attendibile solo quella specifica autorità di firma.
È possibile considerare attendibili più CA specificando una serie di certificati:
ca[]="..."
ca[]="..."
See also the strict-ssl
config.
cafile
- Default: null
- Type: path
Un percorso a un file contenente una o più autorità di certificazione che firmano
certificati. Similar to the ca
setting, but allows for multiple CAs, as well
as for the CA information to be stored in a file instead of being specified via
CLI.
<URL>:cafile
Define the path to a Certificate Authority file to use when accessing the specified registry. Ad esempio:
//registry.npmjs.org/:cafile=ca-cert.pem
cert
- Default: null
- Type: String
Un certificato client da passare quando si accede al registro. I valori devono essere in formato PEM (ovvero "X.509 codificato in base-64 (.CER)"). Ad esempio:
cert="-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"
It is not the path to a certificate file.
<URL>:certfile
Define the path to a certificate file to use when accessing the specified registry. Ad esempio:
//registry.npmjs.org/:certfile=server-cert.pem
key
- Default: null
- Type: String
Una chiave client da passare quando si accede al registro. I valori devono essere in formato PEM (ovvero "X.509 codificato in base-64 (.CER)"). Ad esempio:
key="-----BEGIN PRIVATE KEY-----\nXXXX\nXXXX\n-----END PRIVATE KEY-----"
It is not the path to a key file (and there is no keyfile
option).
Questa impostazione contiene informazioni sensibili. Don't write it to a local .npmrc
file committed to the repository.
<URL>:keyfile
Define the path to a client key file to use when accessing the specified registry. Ad esempio:
//registry.npmjs.org/:keyfile=server-key.pem
gitShallowHosts
- Default: ['github.com', 'gist.github.com', 'gitlab.com', 'bitbucket.com', 'bitbucket.org']
- Type: string[]
Durante il recupero delle dipendenze che sono repository Git, se l'host è elencato in questa impostazione, pnpm utilizzerà la clonazione superficiale per recuperare solo il commit necessario, non tutta la cronologia.
https-proxy
- Default: null
- Type: url
Un proxy da utilizzare per le richieste HTTPS in uscita. If the HTTPS_PROXY
, https_proxy
,
HTTP_PROXY
or http_proxy
environment variables are set, their values will be
used instead.
If your proxy URL contains a username and password, make sure to URL-encode them. Ad esempio:
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
- Type: url
Un proxy da utilizzare per le richieste http in uscita. Se le variabili di ambiente HTTP_PROXY o http_proxy sono impostate, le impostazioni del proxy saranno onorate dalla libreria di richiesta sottostante.
local-address
- Default: undefined
- Type: IP Address
L'indirizzo IP dell'interfaccia locale da utilizzare quando si effettuano connessioni al registro npm.
maxsockets
- Default: networkConcurrency x 3
- Type: Number
Il numero massimo di connessioni da utilizzare per origine (combinazione protocollo/host/porta).
noproxy
- Default: null
- Type: String
Una stringa di estensioni di dominio separate da virgole per le quali non dovrebbe essere utilizzato un proxy.
strict-ssl
- Default: true
- Type: Boolean
Se eseguire o meno la convalida della chiave SSL quando si effettuano richieste al registro tramite HTTPS.
See also the ca
option.
networkConcurrency
- Default: 16
- Type: Number
Controlla il numero massimo di richieste HTTP(S) da elaborare contemporaneamente.
fetchRetries
- Default: 2
- Type: Number
Quante volte riprovare se pnpm non riesce a recuperare dal registro.
fetchRetryFactor
- Default: 10
- Type: Number
Il fattore esponenziale per i tentativi di backoff.
fetchRetryMintimeout
- Default: 10000 (10 seconds)
- Type: Number
Il timeout minimo (di base) per ritentare le richieste.
fetchRetryMaxtimeout
- Default: 60000 (1 minute)
- Type: Number
Il timeout di fallback massimo per garantire che il fattore di ripetizione non esegua richieste troppo lunghe.
fetchTimeout
- Default: 60000 (1 minute)
- Type: Number
Il tempo massimo di attesa per il completamento delle richieste HTTP.
Impostazioni dipendenze peer
autoInstallPeers
- Default: true
- Type: Boolean
When true
, any missing non-optional peer dependencies are automatically installed.
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.
dedupePeerDependents
- Default: true
- Type: 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 dedupePeerDependents
setting to deduplicate webpack
when it has no conflicting peer dependencies (explanation at the end). In this case, if we set dedupePeerDependents
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.
strictPeerDependencies
- Default: false
- Type: Boolean
Se abilitato, i comandi falliranno se c'