Automate regular updates to browserslist

Feature Description

Browserslist is industry-standard to set target browsers for web projects.

The database of browsers it references needs to be upgraded on a regular basis in order to get the most benefit.

From https://github.com/browserslist/browserslist#browsers-data-updating

npx browserslist@latest --update-db updates caniuse-lite version in your npm, yarn or pnpm lock file. This update will bring data about new browsers to polyfills tools like Autoprefixer or Babel and reduce already unnecessary polyfills.

You need to do it regularly for three reasons:

1. To use the latest browser’s versions and statistics in queries like last 2 versions or >1%. For example, if you created your project 2 years ago and did not update your dependencies, last 1 version will return 2 year old browsers.
2. Actual browsers data will lead to using less polyfills. It will reduce size of JS and CSS files and improve website performance.
3. caniuse-lite deduplication: to synchronize version in different tools.

One option might be to leverage a GitHub action to run on a schedule and open a PR automatically, e.g. https://github.com/marketplace/actions/browserslist-update-action

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• There should be a GitHub Action set up to run that automatically updates browserlist—say every week, preferably on a weekend when commits are not likely to be made by the team.

Implementation Brief

• Hook up an action like https://github.com/marketplace/actions/browserslist-update-action to run on an automated schedule using GitHub Actions. The existing ${{ secrets.GITHUB_TOKEN }} used in other actions should be sufficient here to run this action, I think.
  • If not, a developer with admin repo access will need to create a new repo secret with the scopes required by that action.
  • ~To help with review/visibility, we should add this PR to the ZenHub board, specifically to the Merge Review column, using an action like https://github.com/marketplace/actions/zenhub-move-card. This will require creation of a ZenHub token that can move the card over to the Merge Review column.~ This section is no longer to be implemented, see: https://github.com/google/site-kit-wp/pull/5883#issuecomment-1290866177
  • Doing this will reduce the chances of us missing these PRs, so while it marginally increases complexity, I think it’s worth it. 🙂

Test Coverage

• No new tests needed.

QA Brief

• No QA needed, aside from verifying the PR is created. This should be checked Monday morning or later by an engineer (Monday October 31). This workflow can also be manually run here.
• On every workflow run, verify that if there is an existing branch with the name update/browserslist-db, it is deleted and any PR associated with it is closed (if open).

Changelog entry

• N/A

[felixarntz]

@techanvil @nfmohit @tofumatt @aaemnnosttv Providing an update here: Per Google policy we will not be able to use code “authored” by the github-actions user. We will have to create a Google-owned bot account (e.g. something like site-kit-bot) and configure that one with the GitHub repository. There are internal instructions available for how to do that.

@aaemnnosttv will open a follow up issue to track that work. Most of it will have to happen internally, but the final bit will require changes in the plugin codebase (GitHub action). I will close this issue now as by itself it works as expected (except of course for the above, which however was not part of this issue’s definition).

For now, this means the caveat is that we shouldn’t merge/accept those automated PRs for the time being. If we prefer to not get the “noise” of those PRs for now, we could also deactivate the action for now until we have addressed the above.

[techanvil]

Hey @nfmohit, taking looking at this in lieu of @tofumatt - seems to me your proposed PR solves the problem well enough without needing to make the branch name unique.

If we do run into a situation where the static branch name is a problem we have a good idea of how to address is. But I think we can hold off for now and see how we get on.