Dependency updates with Renovate

[stephenwade]

Hi folks! I've noticed that several dependencies are out of date, sometimes causing warnings when running npm install.

I noticed that you already use Snyk at open-wc. Snyk has the ability to automatically keep dependencies up-to-date. Can we use this to keep dependencies up-to-date in open-wc/open-wc and modernweb-dev/web?

I don't see any documentation about whether Snyk works with monorepos. If Snyk doesn't work, Dependabot works with monorepos according to their website. I like Dependabot due to using it on a Ruby project I help maintain.

I think we should use something to keep dependencies up-to-date, and I would prefer it to be automated since there are so many individual packages.

---

updates available as of 2020-10-26

$ npx npm-check-updates
Checking /Users/stephen/temp/web/package.json
[====================] 35/35 100%

 @changesets/cli                    ^2.9.2  →   ^2.11.1
 @rollup/plugin-node-resolve        ^8.4.0  →    ^9.0.0
 @rollup/plugin-typescript          ^5.0.2  →    ^6.0.0
 @types/chai                       ^4.2.11  →   ^4.2.14
 @types/node                       ^14.6.0  →  ^14.14.5
 @types/sinon                       ^9.0.4  →    ^9.0.8
 @typescript-eslint/eslint-plugin   ^3.7.0  →    ^4.6.0
 @typescript-eslint/parser          ^3.7.0  →    ^4.6.0
 alex                               ^8.1.1  →    ^9.0.1
 concurrently                       ^5.2.0  →    ^5.3.0
 eslint                             ^7.5.0  →   ^7.12.0
 eslint-config-prettier            ^6.11.0  →   ^6.14.0
 husky                              ^1.0.0  →    ^4.3.0
 lint-staged                       ^10.3.0  →   ^10.5.0
 mocha                              ^8.1.1  →    ^8.2.0
 prettier                           ^2.0.5  →    ^2.1.2
 prettier-plugin-package            ^1.0.0  →    ^1.2.0
 remark-cli                         ^8.0.1  →    ^9.0.0
 remark-lint                        ^7.0.1  →    ^8.0.0
 remark-preset-lint-recommended     ^4.0.1  →    ^5.0.0
 rollup                            ^2.20.0  →   ^2.32.1
 rollup-plugin-terser               ^6.1.0  →    ^7.0.2
 sinon                              ^9.0.2  →    ^9.2.0
 ts-node                           ^8.10.2  →    ^9.0.0
 typescript                         ^4.0.0  →    ^4.0.5

npm@7 output when running npm install

$ npm i
npm WARN deprecated @types/vfile@4.0.0: This is a stub types definition. vfile provides its own type definitions, so you do not need this installed.
npm WARN deprecated @hapi/topo@3.1.6: This version has been deprecated and is no longer supported or maintained
npm WARN deprecated @hapi/bourne@1.3.2: This version has been deprecated and is no longer supported or maintained
npm WARN deprecated har-validator@5.1.5: this library is no longer supported
npm WARN deprecated flat@4.1.0: Fixed a prototype pollution security issue in 4.1.0, please upgrade to ^4.1.1 or ^5.0.1.
npm WARN deprecated @hapi/address@2.1.4: Moved to 'npm install @sideway/address'
npm WARN deprecated rollup-plugin-babel@4.4.0: This package has been deprecated and is no longer maintained. Please use @rollup/plugin-babel.
npm WARN deprecated @types/globby@9.1.0: This is a stub types definition. globby provides its own type definitions, so you do not need this installed.
npm WARN deprecated smartwrap@1.2.5: Backported compatibility to node > 6
npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated @hapi/hoek@8.5.1: This version has been deprecated and is no longer supported or maintained
npm WARN deprecated @web/dev-server-cli@0.0.3: This packages is merged into @web/dev-server
npm WARN deprecated @hapi/joi@15.1.1: Switch to 'npm install joi'
npm WARN deprecated popper.js@1.16.1: You can find the new Popper v2 at @popperjs/core, this package is dedicated to the legacy v1
npm WARN deprecated core-js@2.6.11: core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
...

[abdonrd]

I recommend use the official GitHub Dependabot:

https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/enabling-and-disabling-version-updates#enabling-github-dependabot-version-updates

[LarsDenBakker]

Would be useful to do something here. We used renovate in https://github.com/modernweb-dev/example-projects and that's working out well. Although it's quite a lot of noise, that's why we opted out of it in the past. Perhaps we can configure it to only do security updates.

[daKmoR]

thx for the suggestion and now we should actually be able to do something for it...

In the past, we opted out of it as every change to package.json would trigger a release... but now with changeset we can control this better... so yes we should set something up... renovate seemed to work fine in the past... but dependabot being there out of the box might be a "better/simpler" choice?

let's evaluate

[stephenwade]

I like the look of Renovate after researching it, and it would be good to be consistent between projects. I'll play around with Renovate this week and propose a config for this repo in a PR.

[abdonrd]

but dependabot being there out of the box might be a "better/simpler" choice?

Yeah, you have it in the same GitHub UI: https://github.com/modernweb-dev/web/network/updates

And we just need one file: #801

[stephenwade]

I think we should use Renovate. One weakness of Dependabot is that it creates one PR for each sub-project for each dependency, which will be even more noise. Renovate will create one PR for each dependency that will update all the sub-projects.

See dependabot/dependabot-core#1190 (comment) for an example.

[abdonrd]

I think we should use Renovate. One weakness of Dependabot is that it creates one PR for each sub-project for each dependency, which will be even more noise. Renovate will create one PR for each dependency that will update all the sub-projects.

See dependabot/dependabot-core#1190 (comment) for an example.

You are right about that!

[stephenwade]

I created #804 to propose a Renovate config file.

As a side note, we should fix the BrowserStack and Sauce Labs actions before moving forward with this. Renovate can automatically merge PRs that pass the test suite, and it looks like those tests are failing most of the time.

[vlilloh]

Nowadays Dependabot also create one PR for each dependency that update all the packages in a monorepo. If that was the only reason I would bet on Dependabot.

[stephenwade]

My status:

I copied this repo to a test repo to try out Renovate. Based on @vlilloh's comment, I'll create a similar one for Dependabot so I can compare them.

Another other thing I've seen as a recommendation for Renovate is that it will update all packages from known monorepos at the same time (for example, install all babel packages or all remark packages at the same time). I'm curious to see if Dependabot does that as well.

I've discovered that the tests are flaky. Renovate created a total of 81 update PRs on my copy of the repo. Out of the 72 PRs that passed tests, at least 12 of them failed with timeout errors and had to be recreated before they passed. I want to look into these tests and see if I can figure out how to make them more reliable. (Is it as simple as increasing the timeout?)

Renovate test repo:
https://github.com/stephenwade/web-test-renovate/pulls

[LarsDenBakker]

One concern I have is that we will generate a lot of version bumps when our dependencies change. This will happen especially if we use locked versions. Are we able to keep using semver so that we get minor updates at least?

[stephenwade]

The Renovate config I proposed will keep using semver. It'll bump the minimum version to whatever the latest is, but it won't pin exact versions. We also have the option to only update the package.json on major versions and leave it alone otherwise, which would be less noise.

You can see all our update strategy choices here:
https://docs.renovatebot.com/configuration-options/#rangestrategy

However, I think that with changeset, the dependency updates shouldn't trigger new versions unless you manually add a changeset entry to the PR, so even with the config I proposed we shouldn't be getting version bumps every time a dependency update happens. The workflow I imagine is:

• Renovate is configured to automatically merge any minor version bumps (as long as tests pass). These wouldn't have changeset entries, so they wouldn't trigger a release, but any changes would be included in the next release.
• Renovate will not automatically merge major dependency updates. This will allow us to add a changeset entry before merging if we want the update to trigger a version bump.

[LarsDenBakker]

That sounds like a good approach 👍

[stephenwade]

Re: @vlilloh and @abdonrd suggesting Dependabot

While testing Dependabot, I discovered that the new Dependabot (native to GitHub) does not support automatically merging packages. I don't know how long the legacy version of Dependabot (which supports auto-merging) will still be around, so I wouldn't want to use it here. This is a huge strike against Dependabot, and I think we should move forward with using Renovate.

dependabot/dependabot-core#1973 (comment)