Yarn now accepts sponsors! Please take a look at our OpenCollective and GitHub Sponsors pages for more details.
Features in master can be tried out by running yarn set version from sources in your project.
preferInteractive forcing interactive mode in non-TTY environments.node-modules linker now honors user-defined symlinks for <workspace>/node_modules directoriesnode-modules linker supports hoisting into inner workspaces that are parents of other workspacesnode-modules linker attemps to hoist tree more exhaustivel until nothing can be hoistednode-modules linker uses aggregated count of peer and regular usages to decide hoisting priority, instead of preferring peer usages over regular as before, which should result in fewer duplicatesTweaks -,--verbose in yarn workspaces foreach; -v will now only print the prefixes, -vv will be necessary to also print the timings.
Adds a new --json option to yarn run when called without script name
Fixes node-modules linker link: dependencies mistreatment as inner workspaces, when they point to a parent folder of a workspace
Fixes spurious "No candidates found" errors
Fixes missing executable permissions when using nodeLinker: pnpm
Fixes packages being incorrectly flagged as optional
Fixes cache key corruptions due to uncontrolled git merges
Fixes yarn version apply --all --dry-run making unexpected changes
Fixes yarn npm login when the remote registry is Verdaccio
node-modules linker when inner workspace depends on outer workspaceyarn npm audit --ignore NUM which didn't apply to deprecationsyarn npm audit --json which didn't print the right output format@yarnpkg/core
yarn explain peer-requirements commandWith Node.js 16's now being End of Life'd, we dropped support for Node.js versions lower than 18.12.
Some important defaults have changed:
yarn init and yarn set version will prefer using packageManager rather than yarnPath when possible (when they detect COREPACK_ROOT in your environment variables).
yarn init will no longer use zero-install by default. You still can enable it, but it should make it easier to start one-of projects without having to rewrite the configuration afterwards.
enableGlobalCache now defaults to true. If your project uses Zero-Installs, the first yarn install you run after migrating to 4.0 will automatically set enableGlobalCache: false in your local .yarnrc.yml.yarn workspaces foreach now requires one of --all, --recursive, --since, or --worktree to be explicitly specified; the previous default was --worktree, but it was rarely what users expected.
compressionLevel now defaults to 0 rather than mixed. It's been proved significantly faster on installs, and the size impact was reasonable enough to change the default. Note that it benefits you even if you use Zero-Installs: as per our tests, a zero-compression is actually easier to handle for Git (you can see by yourself with those examples using compressionLevel: 0 vs compressionLevel: mixed).
yarn install after migrating from 3.6 to 4.0. If you do, it will automatically set the old default (compressionLevel: mixed) in your .yarnrc.yml file. You can then remove it whenever you feel ready to actually change the compression settings.All official Yarn plugins are now included by default in the bundle we provide. You no longer need to run yarn plugin import for official plugins (you still need to do it for third-party plugins, of course).
Yarn's UI during installs has been greatly improved:
node-gyp and transitive peer dependency errors) have been removed.yarn rebuild calls.yarn npm audit.Some settings were renamed or removed:
caFilePath is now httpsCaFilePath
preferAggregateCacheInfo has been removed (it's now always on)pnpDataPath has been removed to adhere to our new PnP specification. For consistency, all PnP files will now be hardcoded to a single value so that third-party tools can implement the PnP specification without relying on the Yarn configuration.The yarn npm audit command has been reimplemented:
/-/npm/v1/security/advisories/bulk endpoint.npmAuditRegistry can be used to temporarily route audit queries to the npm registry.--no-deprecations.Some legacy layers have been sunset:
.pnp.js file when migrating.--assume-fresh-project flag of yarn init has been removed.The following changes only affect people writing Yarn plugins:
The ZipFS and ZipOpenFS classes have been moved from @yarnpkg/fslib to @yarnpkg/libzip. They no longer need or accept the libzip parameter.
open, ZIP_CREATE, and ZIP_TRUNCATE bindings are no longer needed for ZipFS and have also been removed.The dependencies field sent returned by Resolver#resolve must now be the result of a Configuration#normalizeDependencyMap call. This change is prompted by a refactoring of how default protocols (ie npm:) are injected into descriptors. The previous implementation caused various descriptors to never be normalized, which made it difficult to know what were the descriptors each function should expect.
Similarly, the descriptors returned by Resolve#getResolutionDependencies are now expected to be the result of Configuration#normalizeDependency calls.
Note that this only applies to the dependencies field; the peerDependencies field is unchanged, as it must only contains semver ranges without any protocol (with an exception for workspace:, but that's not relevant here).
The Resolve#getResolutionDependencies function must now return an object of arbitrary string keys and descriptor values (instead of a map with DescriptorHash keys). Those descriptors will be resolved and assigned to the same keys as the initial object. This change allows resolvers to wrap resolution dependencies from other resolvers, which wasn't possible before since it'd have caused the key to change.
The generateLoader function in @yarnpkg/pnp no longer generates the $$SETUP_STATE function, it now needs to be present in the loader passed to the function.
The getCustomDataKey function in Installer from @yarnpkg/core has been moved to Linker.
renderForm's options argument is now required to enforce that custom streams are always specified.
npmConfigUtils.getAuditRegistry no longer takes a Manifest as its first argument.
The FetchOptions.skipIntegrityCheck option has been removed. Use FetchOptions.cacheOptions.skipIntegrityCheck instead.
MapConfigurationValue has been removed. Use miscUtils.ToMapValue instead.
Manifest.isManifestFieldCompatible and Manifest.prototype.isCompatibleWith{OS,CPU} have been removed. Use Manifest.prototype.getConditions and structUtils.isPackageCompatible instead.
versionUtils.{fetchBase,fetchRoot,fetchChangedFiles} have been moved from @yarnpkg/plugin-version to @yarnpkg/plugin-git. Use gitUtils.{fetchBase,fetchRoot,fetchChangedFiles} instead.
For consistency reasons:
Link{Resolver,Fetcher} have been renamed to Portal{Resolver,Fetcher}
RawLink{Resolver,Fetcher} have been renamed to Link{Resolver,Fetcher}
FakeFS classes are now required to implement lutimes{Sync,Promise}.
workspace.dependencies has been removed. Use workspace.anchoredPackage.dependencies instead.
The Installer class must now return BuildRequest structures instead of BuildDirective[]. This lets you mark that the build must be skipped, and the reason why.
startCacheReport has been removed, and is now part of the output generated by fetchEverything.
forgettableNames & forgettableBufferSize have been removed (the only messages using them have been removed, making the forgettable logs implementation obsolete).
workspace.locator has been removed. You can instead use:
workspace.anchoredLocator to get the locator that's used throughout the dependency tree.workspace.manifest.version to get the workspace version.configuration.{packageExtensions,refreshPackageExtensions} have been removed. Use configuration.getPackageExtensions instead.
configuration.normalizePackage now requires a packageExtensions option.
ProjectLookup has been removed. Both Configuration.find and Configuration.findProjectCwd now always do a lockfile lookup.
pnpm linker avoids creating symlinks that lead to loops on the file system, by moving them higher up in the directory structure.pnpm linker no longer reports duplicate "incompatible virtual" warnings.enableOfflineMode is a new setting that, when set, will instruct Yarn to only use the metadata and archives already stored on the local machine rather than download them from the registry. This can be useful when performing local development under network-constrained environments (trains, planes, ...).yarn run bin now injects the environment variables defined in .env.yarn when spawning a process. This can be configured using the injectEnvironmentFiles variable.yarn workspaces foreach now automatically enables the --verbose flag in interactive terminals.yarn dlx will no longer report false-positive UNUSED_PACKAGE_EXTENSION warningsyarn workspace will now set $INIT_CWD to the CLI working directory rather than the workspace root.FileHandle.readLines.yarn init.--conditions flag.--watch flag on Node 18 (it previously only supported it on Node 19).pnpapi) can now be imported from ESM modules.ZipFS.prototype.getBufferAndClose will not error on empty archives resulting from an unlink after write.YN0000) from yarn workspaces foreach.hardlinks-global node-modules linker mode by 1.5xftruncate.fchmod.throwIfNoEntry.npm_package_json environment variable is now set by Yarn.node_modules directory, when node-modules linker is activesupportedArchitectures
Various improvements have been made in the core to improve performance. Additionally:
yarn workspaces foreach run command is now able to run binaries.yarn npm info command now supports displaying information about a tagged version of a package (e.g. yarn npm info vue@next).yarn explain command has been added. It can be used to explain an error code, or list all available error codes. yarn explain YN0002.yarn npm publish command now accepts a new --otp option, to set the One-Time Password from the CLI. yarn upgrade-interactive now has improved paging: node_modules is a symbolic link, and doesn't recreate it.cpu and arch fields, Yarn now support a new libc field which can be used in tandem with optionalDependencies to avoid downloading packages that have been linked against incompatible standard libraries (we currently support two values: glibc and musl).node_modules/.store and node_modules folders if they are empty.node_modules/@yarnpkg) if they are empty or after removing a scoped dependency..pnp.cjs files with inlined data will now store the data in a JSON string literal instead of an object literal to improve startup performance.${FOO:+}.read and readSync using options.path property on streams created by createReadStream() and obtained from zip archives.ERR_REQUIRE_ESM error when attempting to require an ES Module, matching the default Node.js behaviour.@yarnpkg/pnpify now escapes paths correctly.node field inside the npm_config_user_agent Yarn sets will now include a leading v.platform isn't set to Node.YARN_IGNORE_NODE environment variable will now be parsed using the same mechanism as env variable configuration settings (i.e. both 1/0 and true/false will be accepted)wrapNetworkRequest hook now lets you wrap network requests (for example to log them).yarn workspaces list and yarn workspaces foreach commands now both support a new --since option that lets you filter the workspace list by changes (only workspaces that changed since the specified commit will be iterated on). This feature is still a little experimental, especially when used with -R,--recursive.yarn workspaces foreach command now handles the fact that a script containing : only becomes global if it exists in exactly one workspace.yarn workspaces foreach command now supports --jobs 1 and --jobs unlimited.yarn init -2 command will now add the packageManager field to your project manifest.pattern matcher from logFilters will now match any part of the log entry.nodeLinker: pnpm mode will let you install packages using the pnpm install strategy, where packages are stored flat and referenced by each others through symlinks. This mode is still a little experimental, so please send our way bugs you might find.supportedArchitectures field to manually enforce the presence of specific architectures.nmMode: hardlinks-global setting will now be automatically downgraded to nmMode: hardlinks-local when global caches and install folders are kept on different devices, thus letting the install continue normally. A warning will still be produced explaining this behaviour.node_modules linker maximizes chances to end-up with only one top-level node_modules in the case of using workspacesnmSelfReferences setting has been added to the nm linker to control whether workspaces are allowed to require themselves - results in creation of self-referencing symlinks. yarn workspaces focus will not create self-referencing symlinks for excluded workspaces anymore.node_modules installs.workspace:^ and workspace:~. When published, those markers will turn into the actual version (just like what used to happen with workspace:*), except that they'll be prefixed with the relevant semver prefix (respectively ^ and ~).npmAuditRegistry setting will let you define which registry to use when running audits. If unset, we'll fallback to the currently configured publish registry (we'll likely change this behavior in Yarn 4 to rather use the fetch registry).node_modules installs will now be given priority during hoisting, preventing cases when indirect regular dependencies would block the way for direct portal dependencies.pnpify binary can now be used from inside directories containing spaces.--version string.node-modules linker.node-modules linker, since they cannot be used from the code anyway.fs module, allowing users to patch it.require.resolve('pnpapi') will be handled correctly even when using exports.yarn run immediately after adding or removing dependencies inside large monorepos.@types version. This matches the behaviour for peer dependencies.pnpEnableEsmLoader.resolve will no longer resolve missing modules to a file with the same name that would happen to be located next to the issuer.VirtualFS.mapToBase to preserve . characters (was converting them to empty strings).readdir with null as second parameter (instead of undefined).yup anymore (we migrated to Typanion as part of Clipanion v3). workspace-tools, remove it from your .yarnrc.yml, upgrade, then import it back.enableImmutableInstalls will now default to true on CI (we still recommend to explicitly use --immutable on the CLI). YARN_ENABLE_IMMUTABLE_INSTALLS=false in your environment variables.initVersion and initLicense configuration options have been removed. initFields should be used instead..pnp.cjs files (instead of .pnp.js) when using PnP, regardless of what the type field inside the manifest is set to.$$virtual into __virtual__.-a alias flag of yarn workspaces foreach got removed; use -A,--all instead, which is strictly the same..vscode/pnpify) won't be cleaned up anymore.--skip-builds flag from yarn install got renamed into --mode=skip-build.bstatePath configuration option has been removed. The build state (.yarn/build-state.yml) has been moved into the install state (.yarn/install-state.gz)@yarnpkg/pnpify has been refactored into 3 packages: @yarnpkg/sdks now contains the Editor SDKs
@yarnpkg/pnpify now contains the PnPify CLI compatibility tool that creates in-memory node_modules
@yarnpkg/nm now contains the node_modules tree builder and hoister@yarnpkg/plugin-node-modules has been renamed to @yarnpkg/plugin-nm
--clipanion=definitions commands supported by our CLIs will now expose the definitions on the entry point (rather than on .command)structUtils.requirableIdent got removed; use structUtils.stringifyIdent instead, which is strictly the same.configuration.format got removed; use formatUtils.pretty instead, which is strictly the same, but type-safe.httpUtils.Options['json'] got removed; use httpUtils.Options['jsonResponse'] instead, which is strictly the same.PackageExtension['description'] got removed, use formatUtils.json(packageExtension, formatUtils.Type.PACKAGE_EXTENSION) instead, which is strictly the same.Project.generateBuildStateFile has been removed, the build state is now in Project.storedBuildState.Project.tryWorkspaceByDescriptor and Project.getWorkspaceByDescriptor now match on virtual descriptors.Workspaces now get self-references even when under the node-modules linker (just like how it already worked with the pnp linker). This means that a workspace called foo can now safely assume that calls to require('foo/package.json') will always work, removing the need for absolute aliases in the majority of cases.
The node-modules linker now does its best to support the portal: protocol. This support comes with two important limitations:
--preserve-symlinks Node option if they wish to access their dependencies.portal: must be hoisted outside of the portal. Failing that (for example if the portal package depends on something incompatible with the version hoisted via another package), the linker will produce an error and abandon the install.The node-modules linker can now utilize hardlinks. The new setting nmMode: classic | hardlinks-local | hardlinks-global specifies which node_modules strategy should be used:
classic - standard node_modules layout, without hardlinkshardlinks-local - standard node_modules layout with hardlinks inside the project onlyhardlinks-global - standard node_modules layout with hardlinks pointing to global content storage across all the projects using this optionnode-modules linker will now ensure that the generated install layouts are terminal, by doing several rounds when needed.node-modules linker will no longer print warnings about postinstall scripts when a workspace depends on another workspace listing install scripts.${ENV_VAR} syntax.preinstall, install, postinstall fail, the remaining scripts will be skipped.git: protocol will now default to fetching HEAD (rather than the hardcoded master).SIGTERM signal will now be propagated to child processes.yarn config unset will now correctly unset non-nested propertiesinitFields edge cases have been fixed.preferAggregateCacheInfo flag will now also aggregate cleanup reports.enableMessageNames flag can be set to false to exclude the YNxxxx from the output.yarn init can now be run even from within existing projects (will create missing files).yarn init and yarn set version will set the packageManager field.yarn set version now downloads binaries from the official Yarn website (rather than GitHub).yarn set version from sources will now upgrade the builtin plugins as well unless --skip-plugins is set.yarn version apply now supports a new --prerelease flag which replaces how prereleases were previously handled.yarn run should be significantly faster to boot on large projects.yarn workspaces foreach --verbose will now print when processes start and end, even if they don't have an output.yarn workspaces foreach now supports a --from <glob> flag, which when combined with -R will target workspaces reachable from the 'from' glob.yarn patch-commit can now be used as many times as you want on the same patch folder.yarn patch-commit now supports a new -s,--save flag which will save the patch instead of just printing it.yarn up now supports a new -R,--recursive flag which will upgrade the specified package, regardless where it is.yarn config unset is a new command that will remove a setting from the local configuration (or home if -H is set).yarn exec got support for running shell scripts using Yarn's portable shell.yarn plugin import can now install specific versions of the official plugins.yarn plugin import will now download plugins compatible with the current CLI by default.yarn unlink has been added which removes resolutions previously set by yarn link.yarn install inside a Yarn v1 project will now automatically enable the node-modules linker. This should solve most of the problems people have had in their migrations. We still recommend to keep the default PnP for new projects, but the choice is yours.bigint, and fstat.@yarnpkg/esbuild-plugin-pnp. We use it to bundle Yarn itself!exports field - regardless of the Node version.node: protocol (new in Node 16)plugins configuration property.The resolution pipeline got reimplemented. We previously used a multi-pass approach where we performed SAT optimization between each pass, but after investigating it turned out the SAT optims had little impact and added performance bottlenecks. We now run the resolution using a much simpler and more efficient algorithm.
Linkers can now define custom data to cache between Yarn invocations. The builtin linkers new use those new capabilities to cache package information that can't change between runs. In practice, this translates into much faster recurrent installs (when running an install that adds few new packages, if any).
Warnings are now reported when packageExtensions rules are either unused or redundant with the original package definition.
Potentially breaking, but it was intended this way from the start: the packageExtensions field cannot be used to replace dependencies anymore (only to add missing ones). Prefer using the resolutions field to replace existing ones.
Progress bars are rendered less often, which should help performances on some terminals.
Aliased packages no longer include themselves in node_modules installs
The upgrade-interactive command will now only show upgrade suggestions for packages that have available upgrades (rather than all of them).
The upgrade-interactive command has received UI improvements that should make it easier to look at.
The yarn workspaces focus command will now only run the postinstall scripts for the focused workspaces.
A new yarn npm audit command lets you query audit information from the npm registry.
The yarn workspaces foreach command has a new flag, -R,--recursive, which will run a command on the current workspace and all others it depends on.
A new --skip-builds option on yarn install will let you skip the build scripts without impacting the generated Yarn artifacts (contrary to enableScripts, which would also stop unplugging the packages that would otherwise be unplugged due to containing build scripts).
It's now possible to run dependency binaries when using the node-modules linker even if one of your other dependencies is reported as incompatible with your system.
By default Windows automatically requests for administrator rights before spawning any binary whose filename contains "install", "setup", "update", or "patch" (it thinks they are installers). We now explicitly opt-out of this behavior in the binary jumpers we use on Windows.
By default, arguments passed to MinGW-compiled programs are automatically expanded by a basic glob pattern engine. We now explicitly opt-out of this behavior in the binary jumpers we use on Windows.
The Windows binary jumpers will now report the right exit code.
Using empty fallbacks in Yarnrc environment variables (${VAR:-}) will now work.
You can now use the new logFilters setting to turn warnings into either errors or info, or to hide them entirely. Note that we plan to significantly improve the peer dependency warnings in the next release, so perhaps don't silence them just now even if you have a bunch of them.
No matches found, Bad file descriptor, Unbound variable, Unbound argument) will now be recoverable errors that make the shell continue on to the next command in the chain instead of hard crashes. Fixes cases such as rm -rf ./inexistentFolder/* || true.Some patches went missing for TypeScript <4. This is now fixed.
Calling fs.exists(undefined) won't crash anymore.
TypeScript import suggestions should now be correct even when the imported module is deep within a workspace.
TypeScript in watch mode (both using -w and within VSCode) will now detect new dependencies as you add them.
Some particular multi-dependency-trees setups will be better supported on Plug'n'Play installs.
Using ctrl+click on imports in VSCode won't take you to virtual packages anymore (require an SDK update).
yarn tag set of commands has been ported over from Yarn Classic as yarn npm tag.yarn info will now print many information about your dependencies. Various options are available to tweak the output, including --json. Plugin authors can provide their own information sections via the fetchPackageInfo hook.yarn stage with the -r,--reset flag will now unstage all changes that seem related to Yarn.yarn add -h to see an example).Terminate batch job (Y/N)? prompts when invoking dependency binaries.The following changes only apply to the pnp linker (which is the default install strategy):
pnpapi module now exposes a new function called getAllLocators allow you to access the list of all locators in the map without having to traverse the dependency tree. This method is considered a Yarn extension, so you should check for its existence if you plan to use it in your code.The following changes only apply to the node-modules linker:
node_modules/.bin folder as their corresponding dependencies are removed.nmHoistingLimits has appeared. It replaces what was previously known as nohoist in Yarn 1.node-modules linker, and that the strictly correct behavior can only be obtained by using the default Plug'n'Play linker.$$ and $PPID
yarn constraints --fix command will now properly persist the changes on disk.yarn unplug command will now work when used on packages with peer dependencies.yarn stage command will now allow to stage files when called without the -c,--commit flag.yarnPath setting.publishConfig.executableFiles field in their manifests to indicate which files should keep the executable flag once packed in the archive. This is important as for portability reasons Yarn strips the executable flag from all files during packing (otherwise yarn pack would yield different outputs when run on Posix vs Windows). Files listed in the bin field are assumed executable by default, so you don't need to explicitly list them in executableFiles.yarn pack will properly include main/module/bin files, even when not explicitly referenced through the files field.git+file: protocol.workspace field will now be processed correctly.workspace: protocol to start with ./
yarn add and yarn up
cd and exit without arguments|& pipelineyarn add and yarn up will now respect the preferInteractive configuration option.yarn config set now supports the -H,--home flag, which causes it to update the home configuration instead of the project configuration.immutablePaths setting allow you to specify paths that must not change when running Yarn with the --immutable flag set. You can use it to detect unforeseen changes to your install artifacts, be it .pnp.js or node_modules files.$RANDOM variable as well as simple calculations using +, -, *, / and () inside $(())
{echo foo}) to execute a command in the context of the current shell (without creating a subshell like in the case of (echo foo)).pnpIgnorePatterns
fs module from within a Webpack browser bundle)."preferUnplugged": true field in the manifest. This will hurt the experience of your users (your project will be the only one that will require hard installs), so please refrain using this field unless there's no other choice.yarn search will open a rich interface to search for packages to install (requires the interactive-tools plugin).yarn npm logout will remove your credentials from your home directory.yarn plugin import from sources will allow you to build plugins from the master branch of the our repository.yarn workspaces focus will only install the current workspace, plus any other workspace it might depend on. The --production flag will only install their production dependencies.yarn exec will execute the specified command at the root of the current workspace (reintroduced from the Classic branch).yarn create is now an alias to yarn dlx (with the create- prefix.)yarn init will now generate an EditorConfig file, and run git init on the resulting folder.yarn init now supports a -i flag which will automatically pin the Yarn version in the project.yarn init will now inject the settings from the initFields configuration setting when generating the initial manifest (future release will remove the now deprecated initVersion and initLicense settings).yarn init will now initialize a workspace project if given the -w flag.yarn workspaces foreach now support glob patterns in --include and --exclude.yarn set version now as an alias called yarn policies set-version (will be deprecated in 3.x).yarn run now supports the --inspect and --inspect-brk switches for binaries (for example yarn run --inspect-brk jest).yarn remove and yarn up now support glob patterns.yarn dlx now respects the local project configuration (particularly the configured registries). This is still experimental and will be further improved in the next months.yarn dlx now properly exits with an exit code when the underlying command returned an exit code too.yarn config get (and set) can now access nested configuration values (for example, yarn config get npmScopes.foo.npmRegistryServer will tell you which server is configured for the given server, if any).yarn config get will now hide its secrets (or rather yours) from the rest of the world. A new --no-redacted option will toggle off this behavior if needed.yarn config set now has a --json option that will let Yarn know it should interpret the given value as a JSON object (useful to set server configuration, etc).yarn workspace foreach will now exit with the expected status code if there's an error.${name} syntax (strict by default; use ${name:-default} to provide a default value).changesetIgnorePatterns setting can be used to ignore some paths from the changeset detection from yarn version check (changes to those paths won't be taken into account when deciding which workspaces need to fresh releases).changesetBaseRef setting can be used to change the name of the master branch that yarn version check will use in its changeset heuristic.httpTimeout and httpRetry settings allow you to configure the behavior of the HTTP(s) requests.preferTruncatedLines setting allow you to tell Yarn that it's ok if info and warning messages are truncated to fit in a single line (errors will always wrap as much as needed, and piping Yarn's output will toggle off this behaviour altogether).compressionLevel. If you don't use Zero-Installs, using a value of 0 may yield speed improvements at little cost.owner/repo#workspace=name syntax (which you can mix with branch names as usual).core.autocrlf so that the builds lead to deterministic results. Generally speaking, improvements have been made to avoid freshly built packages from generating different results.npm pack if we detect a package-lock.json).exec: protocol has a different API. In particular, builtin modules can now be accessed without having to actually require them.**/* in your workspaces field will now detect all child packages as workspaces.pnpMode: loose setting). Under this mode, Yarn will compute the list of packages that would have been hoisted under the node_modules linker, and let the application code access them with only a warning. This mode will however not become the default - warnings cannot be caught by the application code, and as a result the output of the loose mode can be quite verbose, often being more confusing than the strict mode.yarn upgrade-interactive has been revamped to reintroduce some elements that had been omitted when porting the command from the v1 to the v2.lutimes support into Node itself, since it was otherwise impossible to implement perfect copy mechanisms (the copied symlinks would end up with different mtime than their originals)..vscode/pnpify to .yarn/sdks.echo {foo,bar} won't work expect if there's actually a file named foo and/or bar..cjs extension has been added to multiple files in order to make it easier to use "type": "module".Remember that a migration guide is available to help you port your applications to Yarn 2.
Using yarn link will now properly resolve peer dependencies based on the package that requires the linked package rather than the dependencies installed in the linked project folder.
Packages will now only be built when one of their dependencies is changed in some way. Note that this includes both direct dependencies and transitive dependencies, which might trigger unintuitive rebuilds in some case (for example, since node-sass depends on lodash.assign, upgrading lodash.assign will trigger a rebuild). This will be improved in a later release by introducing a new runtime field for the dependenciesMeta object that will exclude the package from the build key computation (feel free to start setting this flag as of now, even if it won't have any effect until then).
Registry hostnames finally aren't part of the lockfile anymore. It means that you can switch the registry at any time by changing the npmRegistryServer settings. One unfortunate limitation is that this doesn't apply to registries that use non-standard paths for their archives (ie /@scope/name/-/name-version.tgz). One such example is NPM Enterprise, which will see the full path being stored in the lockfile.
The --immutable option (new name for --frozen-lockfile) will now properly report when the lockfile would be changed because of entry removals (it would previously only reject new entries, not removals).
We dropped support for Node 8, which has reached its end of life in December.
Accessing registries through http is now forbidden by default (Yarn will throw an exception and require to use https instead). This can be overruled on a per-hostname basis by using unsafeHttpWhitelist.
The meaning of devDependencies is slightly altered. Until then dev dependencies were described as "dependencies we only use in development". Given that we now advocate for all your packages to be stored within the repository (in order to guarantee reproducible builds), this doesn't really make sense anymore. As a result, our description of dev dependencies is now "dependencies that aren't installed by the package consumers". It doesn't really change anything else than the name, but the more you know.
Running <package> will be added as a dependency of your active workspace (using the new portal: protocol). Apart from that the workflow stays the same, meaning that running yarn link somewhere will add the local path to the local registry, and
resolution entry and run yarn install again.The Yarn configuration has been revamped and will not read the .npmrc files anymore. This used to cause a lot of confusion as to where the configuration was coming from, so the logic is now very simple: Yarn will look in the current directory and all its ancestors for .yarnrc.yml files.
.yarnrc.yml and thus are expected to be valid YAML. The available settings are listed here.The lockfiles now generated should be compatible with Yaml, while staying compatible with old-style lockfiles. Old-style lockfiles will be automatically migrated, but that will require some round-trips to the registry to obtain more information that wasn't stored previously, so the first install will be slightly slower.
The cache files are now zip instead of tgz. This has an impact on cold install performances, because the currently available registries don't support it, which requires us to convert it on our side. Zero-Install is one way to offset this cost, and we're hoping that registries will consider offering zip as an option in the future.
package.json)
To see a comprehensive documentation about each possible field, please check our documentation.
Two new fields are now supported in the publishConfig key of your manifests: the main, bin, and module fields will be used to replace the value of their respective top-level counterparts in the manifest shipped along with the generated file.
typings and types fields will also be replaced if you use the TypeScript plugin.Two new fields are now supported at the root of the manifest: dependenciesMeta and peerDependenciesMeta (peerDependenciesMeta actually was supported in Yarn 1 as well, but dependenciesMeta is a new addition). These fields are meant to store dependency settings unique to each package.
Both of these new fields, and all settings the support, are entirely optional. Yarn will keep doing what you expect if they're not there - they're just a mechanism to expose more fine-grained settings.
Some of those settings can only be declared in the project top-level manifest and will be ignored anywhere else (for example built), while others will have a per-package effect (for example optional). As a rule of thumb, dependenciesMeta settings are always project-wide (and thus are only taken into account in the top-level package.json) while peerDependenciesMeta settings are package-specific.
The dependenciesMeta field covers dependencies declared in either of the dependencies and devDependencies fields.
The dependenciesMeta field accepts two types of keys: either a generic package name (lodash), or a specialized package version ([email protected]). This later syntax only works for the top-level manifest and will thus be ignored when seen in a dependency / transitive dependency.
The dependenciesMeta[].comment field is expected to be a string field. Even though it isn't actually used anywhere at the moment, we suggest you to write comments regarding the reason why some packages are used here rather than anywhere else. This might prove useful for plugin authors.
The dependenciesMeta[].built field is a boolean flag; setting it to false will cause the package manager to ignore this package when considering the list of packages that need to be built. If the project uses enable-scripts: false, the warning that would have traditionally been emitted will be downgraded into a simple notice. This settings is project-wide.
The peerDependenciesMeta[].optional field is a boolean flag; setting it to true will stop the package manager from emitting a warning when the specified peer dependency is missing (you typically want to use it if you provide optional integrations with specific third-party packages and don't want to pollute your users' installs with a bunch of irrelevant warnings). This settings is package-specific.
The resolutions field no longer support the glob syntax within its patterns, as it was redundant with its own glob-less syntax and caused unnecessary confusion.
{
"resolutions": {
- "**/@babel/core": "7.5.5",
+ "@babel/core": "7.5.5",
}
}
Workspaces can now be referenced using the special workspace: protocol. This protocol accepts either a relative path to the workspace, or a semver range that will be compared against the version fields from candidate workspaces.
Workspaces don't have to specify a version anymore. If referenced through the workspace: resolver, the engine will assume that they have the version 0.0.0 (which makes workspace:* a good way to say "shut up and take my workspace").
workspace: protocol will see their referenced changed at pack-time if the target workspace defines a version. An error will be thrown otherwise and the package won't be packable.Workspaces can now contain sub-workspaces. This follow the same restriction than before, meaning that any workspace that wishes to expose sub-workspaces must be declared private: true.
The npm-specific commands (such as yarn login or yarn publish) have been moved into a specific namespace (yarn npm login / yarn npm publish). This doesn't affect the yarn pack command which is considered generic enough for the top-level.
Running add command into the location pointed by <path>. This is true for any command. The only limitation is that <path> must be either be ., .., or must contain a slash (in order to disambiguate with script and command names).
Running * by default instead of resolving a new range for <package>. This change only affects peer dependencies (-P), and can be disabled by manually specifying the range (yarn add -P lodash@^4.0.0).
Running preferInteractive to true in your settings.
Running yarn foo:bar will run the foo:bar script regardless of what workspace declares it as long as only one workspace declares it. This change only affects scripts whose names contains at least one colon.
Running <package> from all the dependency sets from all your workspaces, regardless of what your cwd is.
Running
Running <package> in all of your workspaces at once (only if they already use the specified package - those that don't won't see it being added). Adding the -i flag will also cause Yarn to ask you to confirm for each workspace.
Running yarn config --why will tell you the source for each value in your configuration. We recommend using it when you're not sure to understand why Yarn would have a particular settings.
Running yarn pack will no longer always include nested README, CHANGELOG, LICENSE or LICENCE files (note that those files will still be included if found at the root of the workspace being packed, as is usually the case). If you rely on this (somewhat unintended) behavior you can add those files manually to the files field of your package.json.
The yarn upgrade-interactive command has been moved into a plugin that needs to be installed through yarn plugin import interactive-tools. It's also been rewritten, and we'll keep improving over time.
A new protocol is now supported, portal:. Portals are very much like link: in that they directly point to a location on the disk, but unlike links they also take into account the dependencies of the target location (whereas links don't care about these). To give you a better idea, portals are what you use when you want to target a package, whereas links are what you use when you want to target a non-package folder (for example your src directory, or similar).
A new protocol is now supported, patch:. The patch protocol can be used to automatically apply changes to the sources of a package. It's very similar to patch-package, but is directly integrated within Yarn (including its cache and checksum systems).
© 2016–present Yarn Contributors
Licensed under the BSD License.
https://yarnpkg.com/advanced/changelog