🚀 Breaking changes for Yarn 3

[arcanis]

This issue is just there to keep track of which changes we might want to do once we'll get to the next major release. Doesn't mean it'll be anytime soon, the current plan is early 2021 🙂

• Important: Deprecate implicit node-gyp dependencies and builds. Prefer explicitly listing node-gyp in your dependencies, and setting node-gyp build in your postinstall script.

• Important: Deprecate the implicit unplug detection based on the package content (for example if the package contains *.jar or *.node libraries). Prefer explicitly setting the preferUnplugged field in your package instead. This won't affect packages with postinstall scripts, which will still be unplugged by default.

Those two changes put together will allow us to make the install faster by not having to read the package archive at each and every install just to know whether we need to run build scripts or not. They'll also make the ecosystem easier to work with, as third-party tools will just have to look at a package metadata to know whether they would trigger postinstall scripts, or would be written on disk. Currently, there isn't any good way apart from running an actual install and see what happens, or reimplementing the exact same heuristics.

• Add dependency injection to our hook system

• Remove support for initLicense and initAuthor, since they got replaced by initFields which does the same thing plus extra. (fix: fix initFields issues #2264)

• Refactor the hooks to avoid the proliferation of arguments (instead pack them into a single object argument).

• Refactor the hooks to use reducers where it would make sense (e.g. beforeWorkspacePacking).

• Should yarn workspaces foreach execute on all workspaces by default (currently -a) and be scoped with an option? Rational:

  "I never saw monorepo that have packages that contained other packages so having -a enabled by default could be a sensible proposal"

• Merge build-state.yml into install-state.gz (perf!: move build state into install state #2574)

• Remove the yarn policies set-version alias. (Migrates to Clipanion 3 #2370)

• Remove all the environment-specific overrides in yarn install.

• Remove the "default protocol" concept. It was initially meant to allow building Yarn as package manager for other languages, but even once we get there it's unlikely anyone will change the default protocol (nor that it would be a good idea).

• Stop supporting TypeScript for version older than 4.0. Building their repository is a huge PITA because they somehow seem to be anti-lockfile, so you cannot install the dependencies they were using at the time. We're currently trying to support the whole 3.x branch, but we still have some holes were we can't find commits that actually build.

• Always use .pnp.cjs (instead of .pnp.js), even when not using "type": "module". (refactor(plugin-pnp): always generate .pnp.cjs #2286)

  Motivation, quoting @bgotink.

  Right now we store the PnP file as `.pnp.js` for regular workspaces, and as `.pnp.cjs` for workspaces marked `type=module`. There are some downsides to this approach:
  
   - This leads to quite a bit of if-checks in yarn itself (generation fo the pnp file, the NODE_OPTIONS environment variable and pnpify).
   - If there are external tools that depend on the `.pnp.js` file, they will need to also check for `.pnp.cjs`.
   - This makes switching from one to the other more painful than it needs to be, because you need to run `yarn && yarn pnpify --sdk` and reload your IDE.
  
  Always using `.pnp.cjs` removes these downsides.
  

• Remove warning and stop deleting the old PnPify SDK folder - .vscode/pnpify (refactor(pnpify): remove old sdk folder removal #2281)

• Make Yarn imply --immutable when used on CI (feat: make enableImmutableInstalls default to true on ci #2530)

• Rename master into main

• Remove the -a flag from yarn workspaces foreach (deprecated in favour of -A) (refactor(plugin-workspace-tools): remove legacy -a flag #2282)

• Change packageExtensions so that it doesn't, by default, replaces existing entries (so for example, if you add lodash as dependency to webpack, if webpack actually lists lodash, then we'll prefer using the range it originally requests). However, if you set !important at the end of the range, we'll use your range over the original one.

• Make portals only connect the regular dependencies, not the dev ones (perhaps add support for the dev ones with a protocol flag, like portal:path/to/dir#dev?) (remove dev dependencies in portal packages. #1971)

• Make all settings mergeable, and provide a reset: true syntax when they need to be a full override.

• Look at how settings are inherited from the global scope to the local one. ([Feature] Support setting npmAlwaysAuth with npm login command #2106, refactor(plugin-npm): improve evaulation of npm auth configuration #2116)

[crubier]

Just found this, looks really good! One remark though on this:

Refactor the hooks to avoid the proliferation of arguments (instead pack them into a single object argument).

That makes sense from a yarn dx point of view. But from a runtime / installtime performance if might cause problems. On large monorepos it seems like these functions might be called a lot and passing single object arguments means allocating a lot of single-use objects, creating a lot of GC churn. Not sure of the real life impact, but from my point of view, runtime performance of yarn is an important aspect to keep in mind

[jdanil]

@arcanis, would the v3 release be a good opportunity to drop support for node 10, which will be EOL at the end of the month?
https://github.com/nodejs/Release#release-schedule
I'm not sure whether the engines field in the root package.json is supposed to indicate node version support for the binaries.

[merceyz]

We already did in #2373 but seems we didn't update the engines field

[jdanil]

Ah great. Thanks @merceyz. I just noticed in another project CI checks were failing for yarn with node 10, so I wasn't sure if support needed to be dropped (based on the engines field) or if berry should be patched to make it compatible.

[merceyz]

Closing as Yarn 3 has been released

[rtrembecky]

@merceyz Have you moved the list of not-yet-addressed topics somewhere? Will there be a plan to fix them in Yarn 4 or so?

[arcanis]

We don't have a topic for the breaking changes we plan to make in Yarn 4 yet. The items we haven't worked on are mostly split into the "too disruptive for too little gain" and "not enough time to work on them in a reasonable timeframe"; the later will probably be addressed in the next major, the former isn't decided yet.