Automate browserslist DB update

[adamstankiewicz]

We are moving towards a shared browserslist config (https://github.com/edx/browserslist-config) to use across our JS repositories to maintain consistency in browser support across applications while ensuring it is easy to maintain with future changes (i.e., change once, impacts all consumers).

However, the browserslist browsers database can get stale as new usage data and browser versions come out. As such, occasionally we see warnings like:

Browserslist: caniuse-lite is outdated. Please run next command npm update caniuse-lite browserslist

To fix this, running npx browserslist@latest --update-db updates the caniuse-lite version in package-lock.json files.

This issue is to find a way to automate this update process for our repositories that rely on browserslist, e.g., perhaps adding a Github action to each relevant repository that runs on a cron once a week (?) to do the following:

• Runs npx browserslist@latest --update-db to update the package-lock.json file to pull in updates.
• Opens a PR with the resulting changes and auto-merges, or commits directly to default branch.

PRs

This is the pre-requisite:

• feat: added a shared workflow to auto update browserslist in the MFEs .github#29

These need to be updated after the above one gets merged:

• Automate Browserlist DB Update frontend-app-account#642
• Automate Browserlist DB Update frontend-app-publisher#783
• Automate Browserlist DB Update frontend-app-gradebook#274
• Automate Browserlist DB Update frontend-app-admin-portal#869
• Automate Browserlist DB Update frontend-app-profile#615
• Automate Browserlist DB Update frontend-app-ecommerce#221
• Automate Browserlist DB Update frontend-app-payment#646
• Automate Browserlist DB Update frontend-app-learning#987
• Automate Browserlist DB Update frontend-app-program-console#64
• Automate Browserlist DB Update frontend-app-course-authoring#357
• feat: auto update browserslist DB frontend-app-library-authoring#73
• Automate Browserlist DB Update frontend-app-learner-record#100
• Automate Browserlist DB Update frontend-app-enterprise-public-catalog#261
• Automate Browserlist DB Update frontend-app-communications#92
• Automate Browserlist DB Update paragon#1664
• feat: Automate browserlist DB Update frontend-platform#381
• feat: Automate browserlist DB update frontend-template-application#484

[mamankhan99]

Hi @adamstankiewicz , we can simply use dependabot to update the browserslist. I would appreciate your thoughts on it.

[adamstankiewicz]

@mamankhan99 Can you go into more detail around how we might use dependabot to update the browserslist?

My understanding of dependabot is that it helps upgrade dependency versions (e.g., v4.0.5 -> v4.1.0), but it wouldn't necessary be able to run a command like npx browserslist@latest --update-db in each repo on a regular (e.g., weekly) basis.

This isn't really so much a package upgrade, but more running the above command on a regular basis.

When I wrote this issue, the general idea I was thinking was potentially to create some sort of Github Action that runs npx browserslist@latest --update-db on a recurring basis, like a cron, and auto-merges its resulting package-lock.json changes in the repo.

We have some prior art in terms of creating shared Github Action workflows that repositories can take advantage of, e.g.:

• https://github.com/openedx/frontend-app-admin-portal/blob/master/.github/workflows/lockfileversion-check.yml
  • This Github Action workflow utilizes a shared workflow file defined in edx/.github/.github/workflows/.
  • The shared workflow file is implemented here.

This way, the workflow logic is defined once, and repos can opt in to use it, similar to our other shared Github Action workflows: https://github.com/openedx/.github/tree/2675600a7a2efd1df81d1ad1e550a3a9efc0a7bb/.github/workflows

In terms of running a Github Action on a recurring basis, it may be configured similar to this prior art:

on:
  workflow_dispatch:
  schedule:
  - cron: "0 14 * * *" # daily (Github Actions works with UTC)

[mamankhan99]

@adamstankiewicz sorry for the delay, I did some more research and I believe you are right dependabot works fine with npm updates but can not run a command using npx.

This is a test script I created to test chron job ( I will configure it io run once a week ) other than that I want to know do we need some sort of Private Access Token as used below or not ( if yes do I need to ping the owner of every repo to get it or we use a standard ). I will appreciate suggestions if you need any thing changed or a particular format of commits.

Documentation: https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md

name: Update Dependencies
on:
  schedule:
    - cron:  '*/5 * * * *'
jobs:
  update-dep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '16.x'
      - name: Update dependencies
        run: |
          npm install redux@4.2.x
      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v4
        with:
            token: ${{ secrets.PAT }}
            commit-message: 'chore: update browserslist'
            title: Update browserslist
            body: |
              - Dependency updates
  
              Auto-generated by [create-pull-request][1]
  
              [1]: https://github.com/peter-evans/create-pull-request
            branch: update-browserslist

[adamstankiewicz]

@mamankhan99 Apologies for the delayed response...

I think we should be able to use the shared Github config setting of SEMANTIC_RELEASE_GITHUB_TOKEN which should already be accessible by all repos without any extra effort (example)

If that doesn't work, then we'll have to get a bit more creative :)

[arbrandes]

Can we think of any way to unlock progress, here? I see only the account MFE merged the change.

[abdullahwaheed]

As discussed, all of these PRs need to be updated for create-pull-request action rather than edx's testeng-ci. This PR is pending for review, once its merged, i will update rest of PRs and they will be ready to merged

[hurtstotouchfire]

Do you guys need any reviews from maintainer teams on this? I'm fine just letting FED-BOM make the call and merge things, but we do have a couple of the open PRs sitting on https://github.com/orgs/openedx/projects/23/views/1 and I don't know how to triage them.

[arbrandes]

@hurtstotouchfire, right now this is pending @abdullahwaheed addressing reviews on this other PR. Once that is fixed up and merged, all the current open PRs linking to this issue will be refactored based on that outcome, and only then we'll be able to push this forward.

[arbrandes]

@abdullahwaheed, can you confirm we are now just waiting for the downstream PRs to merge?

[adamstankiewicz]

Happy to chime in here :) @arbrandes Yes, the shared Github Action workflow appears to be working as expected. I recently merged in the downstream PR for the Paragon repo and it worked great!

We are indeed waiting on the downstream PRs to merge as this point. Personally, I feel this change is small enough / trivial that FED-BOM could safely go ahead with merging the open PRs, unless the desire was to leave this as an opt-in choice to the owning team (though, that would slightly defeat the purpose of the intent of this work).

cc @abdullahwaheed

[abdullahwaheed]

@arbrandes we are waiting for owning teams to merge these PRs. If its good to go, we can merge these

[arbrandes]

As far as I'm concerned, this is totally good to go!

[arbrandes]

@abdullahwaheed, could it be? Are we finally done here? 😅

[abdullahwaheed]

yes i think we can close it now