Automate dependency upgrades within SemVer range

[jelhan]

This configures RenovateBot to

1. manage all dependencies,
2. upgrade all dependencies within SemVer range at once weekly by recreating yarn.lock,
3. merge such upgrades within SemVer range automatically if tests are passing and
4. group all upgrades of Ember types into one single merge request.

RenovateBot will continue to create separate merge requests for every dependency upgrade, which requires a change to the SemVer range. Such dependency upgrades need to be reviewed and merge manually.

This also helps to avoid running into a bug of RenovateBot, which causes yarn.lock files with missing resolved and integrity members for a dependency: renovatebot/renovate#13804

Ignoring Ember dependencies is not needed anymore. This was needed earlier because Ember CLI Update determined the version of the blueprints to upgrade based on the ember-cli dependency version in the project. This has been replaced by an ember-cli-update.json, which contains information about latest blueprint upgrades. Also compatibility of dependencies with different Ember version has been improved a lot in the last years. No need to upgrade all of them with Ember CLI Update. The latest versions work very well in my experience even if SemVer ranges in blueprints are not yet upgraded to use them.

Relevant parts from RenovateBot documentation for used presets and configuration options:

lockFileMaintenance

This feature can be used to refresh lock files and keep them up-to-date. "Maintaining" a lock file means recreating it so that every dependency version within it is updated to the latest.

https://docs.renovatebot.com/configuration-options/#lockfilemaintenance

:maintainLockFilesWeekly

Run lock file maintenance (updates) early Monday mornings

https://docs.renovatebot.com/presets-default/#maintainlockfilesweekly

:preserveSemverRanges

Preserve (but continue to upgrade) any existing SemVer ranges

https://docs.renovatebot.com/presets-default/#preservesemverranges

[gilest]

Seems reasonable. Slightly nervous about the auto merging but I'll get used to it. It's not like releases are being cut automatically.

Feel free to merge when ready.

compatibility of dependencies with different Ember version has been improved a lot in the last years

This has been my experience too.

[jelhan]

Seems reasonable. Slightly nervous about the auto merging but I'll get used to it.

I know that feeling. But do you review changes in yarn.lock after running yarn upgrade or recreating the lock file? Me not. If CI passes, I hit the merge button. Maybe I read the changelog for direkt dependencies. But also only from time to time and just out of interest. At least my workflow does not provide any additional safety compared to automerge. 🙈

[gilest]

But do you review changes in yarn.lock after running

💀

Maybe I read the changelog for direkt dependencies. But also only from time to time and just out of interest.

I mostly read the changelogs. Only other "safety" I can think of is that I often use ember-cli-dependency-lint.

[jelhan]

@gilest How is your experience with this configuration so far? Wondering if it should be proposed for other addons as well.

[gilest]

manage all dependencies,

I'm considering:

• Disabling auto update of ember-cli. Because I'd like to run ember-cli-update to generate a new blueprint on any minor/major version update. It's not easy to include this in the renovate branch as it can rebase the PR and overwrite my changes
• Disabling ember-source as I'd rather keep the local version close to the minimum supported version and update it manually. I know we have ember-try running but I'd prefer to get that feedback in development before it goes to CI.

upgrade all dependencies within SemVer range at once weekly by recreating yarn.lock,

This is great.

merge such upgrades within SemVer range automatically if tests are passing and

Not sure any of these have been automerged yet – I might be too quick. I need to add a test suite that at least boots the new docsite. There's some PRs right now with passing tests that totally break it which I don't want to be merged.

Never mind – it only automerges the lockfile updates

group all upgrades of Ember types into one single merge request.

Haven't tried to update these packages, but a single PR is definitely better. Similar problem to above where I'd like to include additional changes in the dependency update branch. Not sure what best approach is here.

[gilest]

@jelhan further update to this.

Now that the addon is almost completely "modern" and up to date with its dependencies this system is working very well.

I would recommend it to addon authors 👍🏻