Dependency Updates

We use yarn to manage dependencies and rely on Renovate for automatic updates.

Automatic update PRs

Currently Renovate is configured to run on both main and develop branches and will update the following:

develop

• Direct dependencies referenced in the package.json
• Github actions dependencies
• Docker images found in the Dockerfile
• Security vulnerabilities of direct dependencies

main

• Github actions dependencies
• Docker images found in the Dockerfile
• Security vulnerabilities of direct dependencies

Note that security vulnerabilities of subdependencies are not automatically fixed by renovate. Instead we rely on Github's Security tab and using dependabot to create lockfile updates or manually applying them ourselves. (See below)

Merging package updates

1. Check the PR itself - Treat it as a normal code review, but pay particular attention to the changelog listed (Sometimes you may have to go looking at the packages repo to find a proper changelog). You may also want to tell the PR to rebase by ticking the checkbox if it has been a while, or you think other updates may have been merged recently that could effect it.
2. Check the CI - Does it pass on its own? If it doesnt and its just snapshots update the snapshots. Otherwise for more major versions try and find a migration guide and follow it.
3. Run it locally - For very minor updates seeing the CI passes can be enough, especially for Github actions PRs. Others we recommend running locally after pulling and doing a yarn install to ensure everything is working.
4. Request a review if there were any changes or if the PR has major changes others need to be aware of
5. Once happy merge the PR

Finding and fixing security vulnerabilities

1. Finding vulnerabilities:

Most security vulnerabilities are automatically detected by Github by dependabot and can be found under the Security tab. Those that effect direct dependencies should automatically have PRs opened by Renovate.

2. Determining if they effect production:

Most alerts are usually caused by dev dependencies. To check this you can look at the effected package, and use

yarn why <package> -R

To learn more about where a package has been included from. If they root dependencies are found in the devDependencies in the package.json then they will only be installed during development and so do not effect production.

Even if a package is present in the dependencies and so does get used in production, many may not effect it. It is a judement call of whether you believe it does or not by looking at the specific details of the vulnerability. E.g. If it is a vulnerability of server side rendering, and we dont use it, then it doesnt effect production. If unsure it is best to consult with others to determine or else treat it as effecting production anyway.

3. Determining if an immediate release is needed

If the update doesnt effect production, then any change can be safely merged to develop. Being merged into main is optional. For those that are thought to effect production it is a judgement call on how severe it is. Those with minimal impact can be delayed to the next planned release otherwise they should be released immediately. Again if unsure its best to be safe.

Where an immediate release is required it is easiest to merge any dependency PRs into the relevant release branch or otherwise will require updating the release branch separately (e.g. by cherry picking). See (Release Process)[Release-Process] for more information.

4. Updating the effected packages

If found using Renovate, it is safe to treat it like any other package update and follow the steps in Merging package updates. For others, particularly those found in subdependencies by dependabot there are follow one of the steps below before following the same steps:

1. Use dependabot to create a security update - Clicking the button in the security tab will create a PR that will update the lockfile.
2. Update manually using yarn up <package(s)> -R and create a PR with the changes. This is particularly useful when there are many updates and will update the lockfile to use the latest allowed versions.

You can check the updated versions by either looking at the lockfile or using yarn why like above. This also gives a good indication if something is unable to be updated any further due to other packages. E.g.

yarn why qs -R
└─ inventory-management-system@workspace:.
   ├─ cypress@npm:14.5.4 (via npm:14.5.4)
   │  └─ @cypress/request@npm:3.0.9 (via npm:^3.0.9)
   │     └─ qs@npm:6.14.0 (via npm:6.14.0)

Indicates that qs is being pinned to 6.14.0 by @cypress/request which is in turn pinned by cypress so to update this any further, Cypress needs to be upgraded (in this case to v15).

4. Making releases (If needed)

See Release Process for the release process.