How We Manage Dependency Updates

GitHub Workflows

When we paused this project, 3 workflows were disabled. To re-enable them, find the NPM Dependency Report yamls under .github > workflows and uncomment lines 4 and 5 about the scheduled cron job. There is a workflow for E2E, Backend, and Frontend.

These workflows will generate a report in the Issues tab of GitHub every Tuesday morning detailing which dependencies have updates available.

---

Managing Patch and Minor Updates

We had started 3 week sprints, so at the beginning of our sprint we would add 3 tickets as follows:

Patch/Minor Dependency Updates (Week 1)
Patch/Minor Dependency Updates (Week 2)
Patch/Minor Dependency Updates (Week 3)

Every Tuesday after the reports came out, one member of the team would pick up the ticket and start updating patch and minor dependencies.

It is up to the developer how to group dependency updates. Generally we group by Prod vs Dev dependency updates, but similar packages can be grouped together such as updates to eslint and eslint supporting packages.

After updating a group of packages we rebuild the app, check that there is no console or build errors, and test any features that were updated. For eslint and prettier updates, just check that style checks still happen in your code editor and that there is no new build errors.

After completing tests on a group of updated packages, commit the changes and update any remaining groups of packages.

---

Managing Major Updates

Once a month we meet to create tickets for each of the major dependency updates. We will discuss if any of hem should be grouped together, how many story points to assign to each one, and which ones to prioritize.

We add these tickets to the next sprint and they usually do not take long, but it's important to be aware that major updates usually include breaking changes and it's a good idea to look up a changelog or release note for the package you're updating.