Background:

The amphtml repo has >150 dependencies in package.json. We use renovate to keep them up to date.

Advantages:

• Allows us to use the latest open-source tools
• Allows our node environment to be auto-updated (see Discussion to avoid node version incompatibility with LTSs #19050, Upgrade node from ^10.0.0 to ^12.0.0 #25161 (comment), Use renovate to auto-update Node versions in package.json files #25209, and 📦 Update Node.js to 12 #28123)
• Helps us avoid security vulnerabilities (🏗 Enable package updates for E2E and visual diff tests #23427 (comment), 🏗🐛Manually update build-system/tasks/visual-diff/yarn.lock to address security vulnerabilities #23789 (comment), 🏗 Manually upgrade transitive validator dependencies with security vulnerabilities #25445 (comment), 🏗📦 Switch renovate updates for amphtml from opt-in to opt-out #27692 (comment)).

Disadvantages:

• We need to manually merge a large number of renovate PRs each week
• Most amphtml PRs come from renovate
• AMP release notes are filled with noise (example)
• Test speed-ups are less effective because of frequent cache busting
• There are no clear guidelines around what kind of dependencies we can / can't add (Clarify processes or guidelines around introducing devDependencies #24550)

Purpose of this issue:

To identify a way to reduce the number of PRs while continuing to keep dependencies up to date.

Some ideas:

1. Reduce the number of amphtml dependencies: This is easier said than done. We do frequent clean-ups of unnecessary packages, but our toolchain is large, and rewriting the functionality natively is not an option.
2. Merge all upgrades at night: Today upgrades that pass Travis are merged manually, so we can't rely on the presence of a developer during non-working hours. Also, this doesn't reduce the PR count.
3. Allow upgrades that pass Travis to be auto-merged at night: This will require giving write permissions to renovate, which we've been hesitant to do. This too doesn't reduce the PR count.
4. Consolidate all MINOR and PATCH upgrades into a single PR per day: This will reduce the number of PRs, but can substantially increase the trouble involved in debugging and fixing a breaking change. It can also require frequent auto-rebasing by renovate.
5. Find some other meaningful grouping of package upgrades: Renovate has some native grouping functionality, but it isn't clear how we can use it.

Other ideas?