autoMigrate on a package rule was resolved into ResolvedEffects and aggregated by mergeGroupEffects. Nothing read either.
analyzeGroupMajors passed the repository-wide setting:
...(settings.autoMigrate !== undefined ? { autoMigrate: settings.autoMigrate } : {}),So a rule opting one package into the migration — or out of it — did nothing.
Per package, not per group
That loop already runs once per major, and the documented reading argues for it:
autoMigrateresolves the other way — one package opting in is enough, since migrating what can be migrated leaves everything else exactly as it would have been.
That's a case for deciding each package on its own, not for letting one opt-in carry the rest. A rule wins over the global in both directions; the global stays the default for anything no rule covers.
ai.majorUpgrades.packages still gates which majors get analysed at all — a rule's autoMigrate decides what to do with one that is, so the glob filter stays the outer boundary rather than something a rule can reach past.
The family is closed
| Rule effect | Status |
|---|---|
minimumReleaseAge | #1419 ✅ |
autoMerge | #1422 ✅ |
autoMigrate | this ✅ |
All three were resolved into effects no consumer read — which is why all three validated cleanly and were reported as migrated by the Renovate importer while doing nothing.
A note on the test fixture
A BreakingChange needs a description and an action, and normalizePlan silently drops one missing either. A plan whose changes are all dropped reports analysis-only — the same status as a plan that was never asked to migrate.
So my first fixture made the feature look correctly wired when it wasn't. Worth knowing for anyone testing this path: assert on the migration agent actually running, not on the returned status.
Tests
2092 → 2098.
Lint ✓ · typecheck ✓ · check:docs ✓ · 0 fail
🤖 Generated with Claude Code