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, Yarn updates in packageManager should result in the yarn binary being triggered to perform required migrations, and the .yarnrc.yml should then be committed.

Renovate currently touches the .yarnrc.yml only 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

[lsrocha]

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

In most cases, running corepack use is overkill. npm and pnpm don't do auto-migrations, or at least they haven't done one recently:

npm: No auto-migration at all. When npm deprecates or stops recognizing .npmrc keys, it just emits a warning (e.g. since npm v11.2.0, unknown .npmrc keys trigger a warning rather than being silently rewritten or errored on). You're expected to manually update .npmrc.

pnpm: Closer to migration tooling, but it's opt-in, not automatic. For the v10→v11 config overhaul (which moved most settings out of .npmrc/package.json#pnpm into pnpm-workspace.yaml, and split .npmrc into "auth/registry only" vs. everything else), pnpm ships a codemod you have to run yourself:

pnpx codemod run pnpm-v10-to-v11

If dropped, running yarn install would be enough for Yarn updates, besides giving you more control over the execution (accepts inline parameters).

⚠️ On the other hand, package managers' major releases may introduce lock file changes. If Renovate doesn't update the lock file along with the packageManager bump, it may result in pull requests with CI failures. Most CI scripts force a deterministic dependency installation (via --frozen-lockfile or similar), making the installation exit with a non-zero code in case a lock file change is required. This is more likely to happen in pnpm and Yarn.

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

Agreed.

[lsrocha]

@RahulGautamSingh Today I did some tests and found out that I was wrong. Renovate does execute yarn after a packageManager update, even in pull requests where yarn is the only dependency updated.

Based on that, I was able to achieve the desired behavior by adding a no-op post-upgrade task only to force Renovate to stage the .yarnrc.yml file:

{
  "allowedCommands": ["^bash -c 'true'$"],
  "packageRules": [
    {
      "matchManagers": ["npm"],
      "matchDepTypes": ["packageManager"],
      "matchDepNames": ["yarn"],
      "postUpgradeTasks": {
        "commands": ["bash -c 'true'"],
        "executionMode": "update",
        "fileFilters": ["**/.yarnrc.yml"]
      }
    }
  ]
}