Yarn Config (.yarnrc.yml)

They'll be normalized, compressed, and saved under the form of zip archives with standardized names. The cache is deemed to be relatively safe to be shared by multiple projects, even when multiple Yarn instances run at the same time on different projects. For setting a global cache folder, you should use enableGlobalCache instead.

Whether or not a cache entry is outdated depends on whether it has been built and checksumed by an earlier release of Yarn, or under a different compression settings. Possible behaviors are:

• If required-only, it'll keep using the file as-is, unless the version that generated it was decidedly too old.
• If match-spec, it'll also rebuild the file if the compression level has changed.
• If always (the default), it'll always regenerate the cache files so they use the current cache version.

Supports git branches, tags, and commits. The default configuration will compare against master, origin/master, upstream/master, main, origin/main, and upstream/main.

Files matching the following patterns (in terms of relative paths compared to the root of the project) will be ignored by every command checking whether files changed compared to the base ref (this include both yarn version check and yarn workspaces foreach --since).

Possible behaviors are:

• If throw (the default), Yarn will throw an exception.
• If update, the lockfile will be updated to match the cached checksum.
• If reset, the cache entry will be purged and fetched anew.
• If ignore, nothing will happen, Yarn will skip the check.

We by default limit it to 2 concurrent clone operations.

When set, Yarn will block any git dependency whose normalized repository URL doesn't match one of these patterns. GitHub repositories must be explicitly approved.

Possible values go from 0 ("no compression, faster") to 9 ("heavy compression, slower"). The value mixed is a variant of 9 where files are stored uncompressed if the gzip overhead would exceed the size gain.

The default is 0, which tends to be significantly faster to install. Projects using zero-installs are advised to keep it this way, as experiments showed that Git stores uncompressed package archives more efficiently than gzip-compressed ones.

This only matters for Prolog constraints, which are being deprecated. JavaScript constraints will always be read from the yarn.config.cjs file.

This is an internal configuration setting that shouldn't be touched unless you really know what you're doing.

This is an internal configuration setting that shouldn't be touched unless you really know what you're doing.

Possible values are "^" (the default), "~" or "".

The default is to check the terminal capabilities, but you can manually override it to either true or false.

If true, Yarn will run your constraints right after finishing its installs. This may help decrease the feedback loop delay by catching errors long before your CI would even report them.

If true (the default), Yarn will store the cache files into a folder located within globalFolder instead of respecting cacheFolder.

If true, Yarn will query the remote registries to validate that the lockfile content matches the remote information. These checks make installs slower, so you should only run them on branches managed by users outside your circle of trust.

Yarn will automatically enable the hardened mode on GitHub pull requests from public repository. Should you want to disable it, explicitly set it to false in your yarnrc file.

The default is to check the terminal capabilities, but you can manually override it to either true or false.

If true, Yarn will refuse to change the cache in any way, whether it would add files or remove them, and will abort installs instead of letting that happen.

If true (the default on CI), Yarn will refuse to change the lockfile in any way, whether it would add new entries or remove them. Other files can be added to the checklist via the immutablePatterns setting.

If true (the default on CI environments), Yarn will print the build output directly within the terminal instead of buffering it in an external log file. Note that by default Yarn will attempt to use collapsible terminal sequences on supporting CI providers to make the output more legible.

If true, Yarn will print any patch sections (hunks) that could not be applied successfully to the terminal.

If true, Yarn will prefix most messages with codes suitable for search engines, with hyperlink support if your terminal allows it.

If true (the default), Yarn will use the global folder as indirection between the network and the actual cache. This is only useful if enableGlobalCache is explicitly set to false, as otherwise the cache entries are persisted to the global cache no matter what.

If false, Yarn will never make any request to the network by itself, and will throw an exception rather than let it happen. It's a very useful setting for CI, which typically want to make sure they aren't loading their dependencies from the network by mistake.

If true, Yarn will replace any network requests by reads from its local caches - even if they contain old information. This can be useful when performing local work on environments without network access (trains, planes, ...), as you can at least leverage the packages you installed on the same machine in the past.

Since this setting will lead to stale data being used, it's recommended to set it for the current session as an environment variable (by running export YARN_ENABLE_OFFLINE_MODE=1 in your terminal) rather than by adding it to your .yarnrc.yml file.

If true (the default outside of CI environments), Yarn will show progress bars for long-running events.

If false (the default), Yarn will not execute the postinstall scripts from third-party packages when installing the project (workspaces will still see their postinstall scripts evaluated, as they're assumed to be safe if you're running an install within them).

Note that you also have the ability to disable scripts on a per-package basis using dependenciesMeta, or to re-enable a specific script by combining enableScripts and dependenciesMeta.

If false, SSL certificate errors will be ignored

If true (the default outside of CI environments), Yarn will periodically send anonymous data to our servers tracking some usage information such as the number of dependencies in your project, how many installs you ran, etc.

Consult the Telemetry page for more details about this process.

If false, Yarn will not print the time spent running each sub-step when running various commands. This is only needed for testing purposes, when you want each execution to have exactly the same output as the previous ones.

If false, Yarn won't link workspaces just because their versions happen to match a semver range. Disabling this setting will require all workspaces to reference one another using the explicit workspace: protocol.

This setting is usually only needed when your project needs to use the published version in order to build the new one (that's for example what happens with Babel, which depends on the latest stable release to build the future ones).

Various files we be stored there: global cache, metadata cache, ...

If true, whatever Yarn version is being executed will keep running rather than looking at the value of yarnPath to decide.

By default Yarn will automatically inject the variables stored in the .env.yarn file, but you can use this setting to change this behavior.

Note that adding a question mark at the end of the path will silence the error Yarn would throw should the file be missing, which may come in handy when declaring local configuration files.

The install state file contains a bunch of cached information about your project. It's only used for optimization purposes, and will be recreated if missing (you don't need to add it to Git).

This can be used to hide specific messages, or instead make them more prominent. Rules defined there accept filtering messages by either name or raw content.

We default to 50 concurrent requests, but it may be required to limit it even more when working behind proxies that can't handle large amounts of traffic.

Replacement of the former nohoist setting. Possible values are:

• If none (the default), packages are hoisted as per the usual rules.
• If workspaces, packages won't be hoisted past the workspace that depends on them.
• If dependencies, transitive dependencies also won't be hoisted past your direct dependencies.

This setting can be overridden on a per-workspace basis using the installConfig.hoistingLimits field.

If false, Yarn won't create self-referencing symlinks when using nodeLinker: node-modules. This setting can be overridden on a per-workspace basis using the installConfig.selfReferences field.

Possible values are:

• If classic, regular copy or clone operations are performed.
• If hardlinks-global, hardlinks to a global content-addressable store will be used.
• If hardlinks-local, hardlinks will only be created between similar packages from the same project.

For compatibility with the ecosystem, the default is classic.

Yarn supports three ways to install your project's dependencies, based on the nodeLinker setting. Possible values are:

• If pnp, a single Node.js loader file will be generated.
• If pnpm, a node-modules will be created using symlinks and hardlinks to a global content-addressable store.
• If node-modules, a regular node_modules folder just like in Yarn Classic or npm will be created.

If a package version is newer than the minimal age gate, it will not be considered for installation. This can be used to reduce the likelihood of installing compromised packages, or to avoid relying on packages that could still be unpublished (e.g. the npm registry has specific rules for packages less than 3 days old).

If a package descriptor or name matches the specified pattern, it will not be considered when evaluating any of the package gates.

By default, the store is stored in the node_modules/.store of the project. Sometimes in CI scenario's it is convenient to store this in a different location so it can be cached and reused.

Possible values are:

• If junctions, Yarn will use Windows junctions when linking workspaces into node_modules directories, which are always absolute paths.
• If symlinks, Yarn will use symlinks, which will use relative paths, and is consistent with Yarn's behavior on non-Windows platforms.

Symlinks are preferred, but they require the Windows user running Yarn to have the create symbolic links privilege. As a result, we default to using junctions instead.

If true, authentication credentials will always be sent when sending requests to the registries. This shouldn't be needed unless you configured the registry to reference a private npm mirror.

If not explicitly set, the value of npmRegistryServer will be used.

Replacement of the former _auth setting. Because it requires storing unencrypted values in your configuration, npmAuthToken should be preferred when possible.

Replacement of the former _authToken settings. If you're using npmScopes to define multiple registries, the npmRegistries dictionary allows you to override these credentials on a per-registry basis.

Valid values are public and restricted, but restricted usually requires to register for a paid plan (this is up to the registry you use). Can be overridden on a per-package basis using the publishConfig.access field.

If true, Yarn will generate and publish the provenance information when publishing packages. Can be overridden on a per-package basis using the publishConfig.provenance field.

If not explicitly set, the value of npmRegistryServer will be used. Overridden by publishConfig.registry.

Should you want to define different registries for different scopes, see npmScopes. To define the authentication scheme for your servers, see npmAuthToken. The url must use HTTPS by default, but this can be changed by adding it to the unsafeHttpWhitelist.

Some packages may have been specified incorrectly with regard to their dependencies - for example with one dependency being missing, causing Yarn to refuse it the access. The packageExtensions fields offer a way to extend the existing package definitions with additional information. If you use it, consider sending a PR upstream and contributing your extension to the plugin-compat database.

Note: This field is made to add dependencies; if you need to rewrite existing ones, prefer the resolutions field instead.

If true, Yarn will generate an experimental ESM loader (.pnp.loader.mjs) on top of the CJS one.

If false, Yarn will generate an additional .pnp.data.json file.

Possible values are:

• If all, all packages can access dependencies made available in the fallback.
• If dependencies-only (the default), dependencies will have access to them but not your workspaces.
• If none, no packages will have access to them.

Files matching those locations will not be covered by PnP and will use the regular Node.js resolution algorithm. Typically only needed if you have subprojects that aren't yet part of your workspace tree.

Possible values are:

• If strict (the default), modules won't be allowed to require packages they don't explicitly list in their own dependencies.
• If loose, packages will be allowed to access any other package that would have been hoisted to the top-level under 1.x installs.

Note that, even in loose mode, hoisted require calls are unsafe and should be discouraged.

While Yarn attempts to reference and load packages directly from their zip archives, it may not always be possible. In those cases, Yarn will extract the files to the unplugged folder.

If true, deferred versioning by default when running the yarn version family of commands.

If true, Yarn will ask for your guidance when some actions would be improved by being disambiguated. Enabling this setting also unlocks some features (for example the yarn add command will suggest to reuse the same dependencies as other workspaces if pertinent).

If true, yarn add will attempt to reuse the most common dependency range in other workspaces.

If true, Yarn will truncate lines that would go beyond the size of the terminal. If progress bars are disabled, lines will never be truncated.

We default to the platform parallelism, but for some CI, os.cpus may not report accurate values and may overwhelm their containers.

By default will use workers when performing heavy tasks, such as converting tgz files to zip. This setting can be used to disable workers and use a regular in-thread async processing.

By default we only send one request per week, making it impossible for us to track your usage with a lower granularity.

The default settings never assign unique IDs to anyone, so we have no way to know which data originates from which project. This setting can be used to force a user ID to be sent to our telemetry server.

Frankly, it's only useful in some very specific use cases. For example, we use it on the Yarn repository in order to exclude our own usage from the public dashboards (since we run Yarn far more often here than anywhere else, the resulting data would be biased).

If true, Yarn will automatically add @types dependencies when running yarn add with packages that don't provide their own typings (as reported by the Algolia npm database). This behavior is enabled by default if you have a tsconfig.json file at the root of your project, or in your current workspace.

Due to a particularity in how Yarn installs packages which list peer dependencies, some packages will be mapped to multiple virtual directories that don't actually exist on the filesystem. This settings tells Yarn where to put them. Note that the folder name must be __virtual__.

This binary will be executed instead of any other (including the global one) for any command run within the directory covered by the rc file. If the file extension ends with .js it will be required, and will be spawned in any other case.

The yarnPath setting used to be the preferred way to install Yarn within a project, but we now recommend to use Corepack in most cases.