Yarnrc files (.yarnrc.yml)

The path where the downloaded packages are stored on your system. 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.

Path to file containing one or multiple Certificate Authority signing certificates

The base git refs that the current HEAD is compared against in the version plugin. This overrides the default behavior of comparing against master, origin/master, upstream/master, main, origin/main, and upstream/main. Supports git branches, tags, and commits.

An Array of glob patterns. Files matching the following patterns (in terms of relative paths compared to the root of the project) will be ignored by the yarn version check command.

If throw (the default), Yarn will throw an exception on yarn install if it detects that a package doesn't match the checksum stored within the lockfile. If update, the lockfile checksum will be updated to match the new value. If ignore, the checksum check will not happen.

The compression level employed for zip archives, with 0 being 'no compression, faster' and 9 being 'heavy compression, slower'. The default is 'mixed', which is a variant of 9 where files may be stored uncompressed if the builtin libzip heuristic thinks it will lead to a more sensible result.

The path of the constraints file.

Default language mode that should be used when a package doesn't offer any insight.

Yarn is a modular package manager that can resolve packages from various sources. As such, semver ranges and tag names don't only work with the npm registry - just change the default protocol to something else and your semver ranges will be fetched from whatever source you select.

The default prefix for semantic version dependency ranges, which is used for new dependencies that are installed to a manifest. Possible values are "^" (the default), "~" or "".

The folder where the versioning files are stored.

If true (by default detects terminal capabilities), Yarn will format its pretty-print its output by using colors to differentiate important parts of its messages.

If true, Yarn will disregard the cacheFolder settings and will store the cache files into a folder shared by all local projects sharing the same configuration.

If true (by default detects terminal capabilities), the CLI is allowed to use hyperlinks in its output.

If true, Yarn will refuse the change the cache in any way (whether it would add files or remove them) when running yarn install.

If true (the default on CI), Yarn will refuse to change the installation artifacts (apart from the cache) when running an install. This flag is quite intrusive, you typically should only set it on your CI by manually passing the --immutable flag to yarn install.

If true (the default on CI environments), Yarn will print the build output directly within the terminal instead of buffering it in a log file.

If true (the default), Yarn will use the global folder as indirection between the network and the actual cache. This makes installs much faster for projects that don't already benefit from Zero-Installs.

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 (the default outside of CI environments), Yarn will show progress bars for long-running events.

If false, Yarn will not execute the postInstall scripts when installing the project. Note that you can now also disable scripts on a per-package basis thanks to 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 dependency in your project, how many install you ran, etc. Consult the Telemetry page for more details about it.

If false, Yarn will not print the time spent running each sub-step when running various commands. This is typically 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 that all workspace accesses are made through the workspace: protocol. This is usually only needed in some very specific circumstances.

The path where all system-global files (for example the list of all packages registered through yarn link) are stored.

Defines a proxy to use when making an HTTP request. Note that Yarn only supports HTTP proxies at the moment (help welcome!).

Defines a proxy to use when making an HTTPS request. Note that Yarn only supports HTTP proxies at the moment (help welcome!).

Timeout of each http request in milliseconds

Retry times on http failure

If true, the --cwd flag will be ignored.

If true, the local executable will be ignored when using the global one.

An array of patterns for files and directories that aren't allowed to change when running installs with the `--immutable` flag set.

Scope used when creating packages via the init command.

Additional fields to set when creating packages via the init command.

Path of the file where the install state will be persisted.

Defines overrides for log levels for message names or message text. Through this setting you can hide specific messages or give them a more important visibility.

Defines the name of the lockfiles that will be generated by Yarn.

Defines how many requests are allowed to run at the same time. Yarn defaults 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 concurrent requests.

Additional network settings, per hostname

Defines the highest point where packages can be hoisted. One of workspaces (don't hoist packages past the workspace that depends on them), dependencies (packages aren't hoisted past the direct dependencies for each workspace), or none (the default, packages are hoisted as much as possible). This setting can be overriden per-workspace through the installConfig.hoistingLimits field.

Defines whether workspaces are allowed to require themselves - results in creation of self-referencing symlinks. This setting can be overriden per-workspace through the installConfig.selfReferences field.

If set to hardlinks-local Yarn will utilize hardlinks to reduce disk space consumption inside node_modules directories in a current project. With hardlinks-global Yarn will use global content addressable storage to reduce node_modules size across all the projects using this option.

Defines what linker should be used for installing Node packages (useful to enable the node-modules plugin), one of: pnp, pnpm and node-modules.

If true, Yarn will always send the authentication credentials when making a request to the registries. This typically shouldn't be needed.

Defines the registry that must be used when auditing dependencies. Doesn't need to be defined, in which case the value of npmRegistryServer will be used.

Defines the authentication credentials to use by default when accessing your registries (equivalent to _auth in the v1). This settings is strongly discouraged in favor of npmAuthToken.

Defines the authentication credentials to use by default when accessing your registries (equivalent to _authToken in the v1). If you're using npmScopes to define multiple registries, the npmRegistries dictionary allows you to override these credentials on a per-registry basis.

Defines the default access to use when publishing packages to the npm registry. Valid values are public and restricted, but restricted usually requires to register for a paid plan (this is up to the registry you use).

Defines the registry that must be used when pushing packages. Doesn't need to be defined, in which case the value of npmRegistryServer will be used. Overridden by publishConfig.registry.

On top of the global configuration, registries can be configured on a per-scope basis (for example to instruct Yarn to use your private registry when accessing packages from a given scope). The following properties are supported:

Defines the hostname of the remote server from where Yarn should fetch the metadata and archives when querying the npm registry. Should you want to define different registries for different scopes, see npmScopes. To define the authentication scheme for your servers, see npmAuthToken. The Hostname must use the HTTPS protocol, but this can be changed by adding it to the unsafeHttpWhitelist.

On top of the global configuration, registries can be configured on a per-scope basis (for example to instruct Yarn to use your private registry when accessing packages from a given scope). The following properties are supported:

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.

The location where Yarn will read and write the .pnp.meta.json file.

If true, Yarn will generate an experimental ESM loader (.pnp.loader.mjs). Yarn tries to automatically detect whether ESM support is required.

If true (the default), Yarn will generate a single .pnp.cjs file that contains all the required data for your project to work properly. If toggled off, Yarn will also generate a .pnp.data.json file meant to be consumed by the @yarnpkg/pnp package.

Enumeration whose values (none, dependencies-only, all) define in which capacity should the PnP hook allow packages to rely on the builtin fallback mechanism. In dependencies-only mode (the default), your workspaces aren't allowed to use it.

An Array of glob patterns. Files matching the following locations (in term of relative path compared to the generated .pnp.cjs file) will not be covered by PnP and will use the regular Node resolution. Typically only needed if you have subprojects that aren't yet part of your workspace tree.

If strict (the default), Yarn won't allow modules to require packages they don't explicitly list in their own dependencies. If loose, Yarn will allow access to the packages that would have been hoisted to the top-level under 1.x installs. Note that, even in loose mode, such calls are unsafe (hoisting rules aren't predictable) and should be discouraged.

A header that will be prepended to the generated .pnp.cjs file. You're allowed to write multiple lines, but this is slightly frowned upon.

The path where unplugged packages will be stored on the disk.

If true, Yarn will only print a one-line report of any cache changes.

If true, Yarn will use the deferred versioning (--deferred) by default when running the yarn version family of commands. This can be overruled on a by-command basis by manually setting the --immediate flag.

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 will truncate lines that would go beyond the size of the terminal. If progress bars are disabled, lines will never be truncated. Forgettable lines (e.g. the fetch step logs) are always truncated.

Which style of progress bar should be used (only when progress bars are enabled). Valid values can be found here.

This setting defines the name of the files that Yarn looks for when resolving the rc files. For obvious reasons this settings cannot be set within rc files, and must be defined in the environment using the YARN_RC_FILENAME variable.

Defines the systems for which Yarn should install packages.

This setting defines the minimal amount of time between two telemetry uploads, in days. By default we only send one request per week, making it impossible for us to track your usage with a lower granularity.

By default, we don't assign unique IDs in the telemetry we send, 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 necessarily run Yarn more often here than anywhere else, the resulting data would be biased).

This setting lists the hostnames for which using the HTTP protocol is allowed. Any other hostname will be required to use HTTPS instead. The reason behind this decision and more details can be found here.

Glob patterns are supported.

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__.

The path of a Yarn binary, which 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 is currently the preferred way to install Yarn within a project, as it ensures that your whole team will use the exact same Yarn version, without having to individually keep it up-to-date.