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