Spike on renovate - extension, mobile, maybe core too?

[desi]

Please don't spend more than 2 to 3 days on this spike.

Outcome of the spike should be a POC that lets us define an actual issue to be worked that can be brought into mobile, and extension

There are 3 use cases we'd want to verify are possible using renovate:

1. Automated updating of Internal packages (@metamask/ and @lavamoat/ scoped packages) - Single PR and created as soon as possible.
2. Automated updating of external packages (in range bump) - see full details below
3. Automated updating of external package breaking changes - see full details below

So for the above the POC would hopefully prove that we could target specific packages with specific rules to cover each of the cases above.

For reference see this issue: https://github.com/MetaMask/MetaMask-planning/issues/39 For reference see this slack thread: https://consensys.slack.com/archives/C04BLA0LEQZ/p1718387191293879

Full thread copied here for ease:

We can use Renovate to automate dependency updates. But that raises the question, when do we want to update dependencies and why? When I was working on this, I split it into three different scenarios.

1. Internal packages (@metamask/ and @lavamoat/ scoped packages) We typically want these updated as soon as possible. If we release a package, presumably we intend to use it.

• A single PR per update
• Create the PR as soon as possible

2. External package in-range bumps This would be anything in the range we're asking for, e.g. patch and minor bumps for dependencies with a ^ range, or just patch bumps for ~ ranges like TypeScript.

Typically we want our dependencies to be up-to-date, so that we benefit from bug fixes and features that we may not know about. However we're not in any rush, and updating early increases risk of falling victim to a supply chain attack. We also don't want to waste our own time reviewing countless dependency updates every week for no benefit. So for these, I'd recommend that instead of updating ASAP, we:

• Batch updates together into a single PR
• Only include updates that have been in-production for 4 weeks
• Only create these batch PRs one per week or so. We don't need to do these batch updates frequently.

4 weeks is an arbitrary time period I chose; long enough that any blatant supply chain attacks would have been discovered, but short enough that we're usually still getting updates soon enough to be useful.

3. External package breaking changes Similarly for #2, we usually want to stay up-to-date but we're in no rush, and similar risks apply. One difference is that batching doesn't really make sense, because each breaking change will need special consideration. So for these, I'd recommend:

• A single PR per update
• Only include updates that have been in-production for 4 weeks"

Additionally, we might want to create special rules for grouping breaking changes together when they relate to each other. Or grouping all updates of certain types together. For example, when I worked on this, I found it useful to group all ESLint config updates together.

Sample config that Mark has used previously: https://github.com/Gudahtt/prettier-plugin-sort-json/blob/main/renovate.json5