Support for Yarn auto-migrations

[lsrocha]

The Yarn project is using auto-migrations as a strategy for preventing breaking changes in minor releases. New default configuration values are shipped and existing projects, based on the existence of yarn.lock, have their .yarnrc.yml files modified to preserve the previous behavior. This approach was recently used in versions 4.14.0, which disables postinstall scripts by default, and 4.15.0, which sets a default minimum release age gate.

Since Corepack is the recommended way for managing Yarn installations, any Yarn updates in packageManager should result in the yarn binary being triggered to perform any possible migrations, and the .yarnrc.yml should then be committed.

Renovate currently only touches the .yarnrc.yml when Yarn is managed via yarnPath. If the version is only declared in packageManager, the package.json is the only updated file.

To prevent introducing breaking changes into the project I maintain, I had to disable Yarn upgrades.

[RahulGautamSingh]

How do we trigger the yarn binary? (sorry, yarn noob here). If you could explain with more details like the commands we might have to run then it'd be helpful.

[lsrocha]

After bumping packageManager: yarn@<semver> in package.json, it requires a simply yarn install:

$ yarn install --mode=update-lockfile

➤ YN0087: Migrated your project to the latest Yarn version 🚀

➤ YN0000: · Yarn 4.14.0
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed in 0s 887ms
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0073: │ Skipped due to mode=update-lockfile
➤ YN0000: └ Completed
➤ YN0000: · Done with warnings in 0s 900ms

The --mode=update-lockfile flag is to avoid performing a full installation: prevents the link phase, as described in the yarn install documentation.

As a result, it updates both .yarnrc.yml (project-level configuration) and yarn.lock (increments the lock file version):

diff --git a/.yarnrc.yml b/.yarnrc.yml
new file mode 100644
index 00000000000..e652f1bdf83
--- /dev/null
+++ b/.yarnrc.yml
@@ -0,0 +1,4 @@
+approvedGitRepositories:
+  - "**"
+
+enableScripts: true
diff --git a/package.json b/package.json
index 05a3eb1d819..a2678cc7c04 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
 {
   "name": "test-yarn-migration",
-  "packageManager": "yarn@4.13.0",
+  "packageManager": "yarn@4.14.0",
   "dependencies": {
     "semver": "^7.8.5"
   }
diff --git a/yarn.lock b/yarn.lock
index 155c62d2b30..282fd9b1eb3 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -2,7 +2,7 @@
 # Manual changes might be lost - proceed with caution!
 
 __metadata:
-  version: 8
+  version: 9
   cacheKey: 10c0
 
 "semver@npm:^7.8.5":

Alternatively, the same result can be reached by running corepack use yarn@<semver>, which will update the packageManager field in package.json and then perform a full installation. The only downside is that it doesn't accept extra parameters to limit the installation mode.

[RahulGautamSingh]

Alternatively, the same result can be reached by running corepack use yarn@

We already do corepack use, but only run it incase the manager's version string has a hash in it.

renovate/lib/modules/manager/npm/artifacts.ts

Line 69 in df7aa7b

// Execute 'corepack use' command only if the currentValue already has hash in it

There are disucssions around removing it though, cause it leads to unwanted cases like this one.

We will need to add this under a flag so users can optout