Auto Hide IP V5.4.0.2 With Patch
Donnell Simon
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).
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).
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.
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.
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 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).
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.
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).
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.
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.
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).
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 yarn link now has a semi-permanent effect in that 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 will add a dependency to the previously linked package.
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.
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.
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.
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 accepts two types of keys: either a generic package name (lodash), or a specialized package version (lod...@1.2.3). 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.
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").
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 yarn add ... will run the add command into the location pointed by . This is true for any command. The only limitation is that must be either be ., .., or must contain a slash (in order to disambiguate with script and command names).
7fc3f7cf58