Node 10 isn't supported anymore.
Plugins can't access yup anymore (we migrated to Typanion as part of Clipanion v3).
- To upgrade workspace-tools, remove it from your .yarnrc.yml, upgrade, then import it back.
The enableImmutableInstalls will now default to true on CI (we still recommend to explicitly use --immutable on the CLI).
- You can re-allow mutations by adding YARN_ENABLE_IMMUTABLE_INSTALLS=false in your environment variables.
The initVersion and initLicense configuration options have been removed. initFields should be used instead.
Yarn will now generate .pnp.cjs files (instead of .pnp.js) when using PnP, regardless of what the type field inside the manifest is set to.
The virtual folder (used to disambiguate peer dependencies) got renamed from $$virtual into __virtual__.
The -a alias flag of yarn workspaces foreach got removed; use -A,--all instead, which is strictly the same.
The old PnPify SDK folder (.vscode/pnpify) won't be cleaned up anymore.
The --skip-builds flag from yarn install got renamed into --mode=skip-build.
The bstatePath configuration option has been removed. The build state (.yarn/build-state.yml) has been moved into the install state (.yarn/install-state.gz)
The cache files need to be regenerated. We had to change their timestamps in order to account for a flaw in the zip spec that was causing problems with some third-party tools.
@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
The --clipanion=definitions commands supported by our CLIs will now expose the definitions on the entry point (rather than on .command)

API

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.

Installs

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:
- Projects that make use of such dependencies will have to be run with the --preserve-symlinks Node option if they wish to access their dependencies.
- Because Yarn installs will never modify files outside of the project due to security reasons, sub-dependencies of packages with 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 hardlinks
- hardlinks-local - standard node_modules layout with hardlinks inside the project only
- hardlinks-global - standard node_modules layout with hardlinks pointing to global content storage across all the projects using this option

Bugfixes

Yarn now has a proper governance model.
The node-modules linker will now ensure that the generated install layouts are terminal, by doing several rounds when needed.
The node-modules linker will no longer print warnings about postinstall scripts when a workspace depends on another workspace listing install scripts.
Peer dependencies depending on their own parent are now properly hoisted by the node-modules linker.
Boolean values will be properly interpreted when specified inside the configuration file via the ${ENV_VAR} syntax.
Should any of preinstall, install, postinstall fail, the remaining scripts will be skipped.
The git: protocol will now default to fetching HEAD (rather than the hardcoded master).
The SIGTERM signal will now be propagated to child processes.
The PnP linker now schedules packages to be rebuilt if their unplugged folder is removed
yarn config unset will now correctly unset non-nested properties
The TypeScript SDK now
And a bunch of smaller fixes.

Settings

Various initFields edge cases have been fixed.
The preferAggregateCacheInfo flag will now also aggregate cleanup reports.
A new enableMessageNames flag can be set to false to exclude the YNxxxx from the output.

Commands

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.

Builtin Shell

The shell now supports background jobs, with color-coded output.
It now also supports redirections from file descriptors.

Compatibility

Running 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.
The patched filesystem now supports file URLs, bigint, and fstat.
An official ESBuild resolver is now provided under the name @yarnpkg/esbuild-plugin-pnp. We use it to bundle Yarn itself!
PnP projects can now use the Node exports field - regardless of the Node version.
The PnP hook now supports the node: protocol (new in Node 16)
The Prettier SDK does not use PnPify anymore since it was its only remaining use, and was fairly invasive; as a result, the Prettier plugins must be specified in Prettier's plugins configuration property.
Zip terminal links can now be clicked from within VSCode
Builtin patches that fail to apply will no longer cause an error (they'll emit a warning and the original sources will be used instead).
- Remember that patches are a problem for our team too, and that we only do this because we don't have any other option available to us right now - if you wish to help, consider upvoting the relevant pull request in the TypeScript repository or, if you work at Microsoft, perhaps mention to your TypeScript team next door that fixing this would benefit you.

Miscellaneous

Reporting for HTTP errors has been improved, which should help you investigate registry issues.

2.1.0

Diff

yarnbot

published 2.1.0 • 7 months ago

Changelog

Source

2.1.0

yarn set version 2.1.0

Ecosystem

Packages can now declare they they need to be unpacked in order to be functional using the new "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.

New commands

Running yarn search will open a rich interface to search for packages to install (requires the interactive-tools plugin).
Running yarn npm logout will remove your credentials from your home directory.
Running yarn plugin import from sources will allow you to build plugins from the master branch of the our repository.
Running 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.
Running yarn exec will execute the specified command at the root of the current workspace (reintroduced from the Classic branch).
Running yarn create is now an alias to yarn dlx (with the create- prefix.)

CLI

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.

Configuration

Registry auth settings can now be declared per-scope (they previously had to be per-registry). This will be handy with the GitHub Package Registry model, where each scope may have different access tokens.
The configuration file now interpolates the values with the environment variables using the ${name} syntax (strict by default; use ${name:-default} to provide a default value).
The new 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).
The new changesetBaseRef setting can be used to change the name of the master branch that yarn version check will use in its changeset heuristic.
The new httpTimeout and httpRetry settings allow you to configure the behavior of the HTTP(s) requests.
The new 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).
The cache compression level can now be configured through compressionLevel. If you don't use Zero-Installs, using a value of 0 may yield speed improvements at little cost.
Plugins are now loaded from the location of the RC file.

Protocols

The Git protocol has been improved, and now supports multiple patterns that were missing.
The Git protocol can now clone any workspace from a given repository. To do this, use the owner/repo#workspace=name syntax (which you can mix with branch names as usual).
The repositories cloned using the Git protocol will now automatically disable 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.
Packages fetched using the Git protocol will now be built using either of Yarn 1, Yarn 2, npm, or pnpm. The choice will be made based on the content of the sources (for example, we will pack the project using npm pack if we detect a package-lock.json).
The exec: protocol has a different API. In particular, builtin modules can now be accessed without having to actually require them.

Installs

Deprecation warnings are now shown during installs.
The out-of-file PnP data generation has been fixed (it allows to generate the PnP data in a JSON file separated from the JS loader itself).
An edge case in the virtual instances deduplication has been fixed; packages with the same effective peer dependencies now always share the exact same instance.
The heuristic we use to locate zip files within paths has been improved. As a result, running ESLint on our repository now takes 28s instead of 57s.
Yarn will now exclude the node_modules folder from the workspace detection. As a result, listing **/* in your workspaces field will now detect all child packages as workspaces.
The cache names have changed in order to make the cache content-addressed. In particular, this mean that in the event where we need to fix a bug in the fetch steps, we won't need to bump a global cache key anymore.
The PnP linker now features an additional loose mode (optional, and enabled through the 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.
Because we're aware of no incorrect hoisting bug on the v2 (but have discovered a few in the v1), and because its performances are about the same, the node_modules linker from Yarn 2 is now deemed more stable than the one from the v1, and we recommend users to migrate to it even if you don't want to use Plug'n'Play. More improvements are to come, but they'll mostly be in the user experience (for example to mix PnP and nm into a single install).

Rendering

Rendering on small terminals (or terminals which didn't expose their size) could lead to failed assertions. This is now fixed.
The output of yarn upgrade-interactive has been revamped to reintroduce some elements that had been omitted when porting the command from the v1 to the v2.
Error codes are now hyperlinks on compatible terminals.

Third-party integrations

The PnP hook will now display the list of packages that broke the peer dependency chain (it previously only showed the name of the package that wasn't provided the peer dependency, but not the name of which ancestor was responsible).
We have added 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).
The SDK files have been moved from .vscode/pnpify to .yarn/sdks.
Improvements have been made in the VSCode integration. In particular, the PnP support is now good enough that it started to fix some longstanding issues that VSCode had with properly naming workspaces.
We have contributed to VSCode support for third-party protocols with TypeScript. As a result, zip archives now properly support the "Jump to definition" workflow (this requires the ZipFS extension to be installed).
The SDK output has been migrated to the same standard as the other commands.
The SDK can now prepare the development environment for both VSCode and Vim. More third-party tools have been added, such as the Svelte extension. Note: the SDK is only needed for editor integrations; you don't need it if you just want to author JavaScript on basic text editors.

Miscellaneous

Scripts can now use glob patterns, which will be resolved regardless of the underlying shell (so it'll work on Windows as well as Linux). Note that this only covers file globbing - using something like echo {foo,bar} won't work expect if there's actually a file named foo and/or bar.
Sending SIGKILL (or other signals) to the Yarn process wasn't causing the child processes to stop. Yarn will now forward the signal, and wait for its children to exit.
Some temporary folders weren't properly cleaned up; this has been fixed.
Support for the .cjs extension has been added to multiple files in order to make it easier to use "type": "module".
The bundle has received various size and startup time optimizations.

2.0.0

Diff

yarnbot

published 2.0.0 • 9 months ago

Changelog

Source

2.0.0

yarn set version 2.0.0

Remember that a migration guide is available to help you port your applications to Yarn 2.

Notable fixes

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

Notable changes

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.
- One particular note is that you cannot install production dependencies only at the moment. We plan to add back this feature at a later time, but given that enabling Zero-Installs would cause your repository to contain all your packages anyway (prod & dev), this feature isn't deemed as important as it used to be.
Running yarn link <package> now has a semi-permanent effect in that <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 yarn link <package> will add a dependency to the previously linked package.
- To disable such a link, just remove its 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.
- Note that the configuration files are now called .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.
- We chose zip because of its perfect combination in terms of tooling ubiquity and random access performances (tgz would require to decompress the whole archive to access a single file).