Skip to content

Dependency updates

Vyacheslav Matyukhin edited this page Feb 3, 2024 · 4 revisions

With Dependabot

We use dependabot.

Right now it's configured to run monthly.

Rules of thumb for deciding whether merging a dependabot PR is safe:

  • is the update for dev-only dependency? merge without checking if tests are passing
    • example: jest, @types/* packages
  • is it a patch, minor or major-level update? do you know if the updates for this package are usually smooth?
    • examples: codemirror and eslint are quite stable and backward-compatbible; next sometimes break things in minor releases
  • read through release notes (or go to the original repo if dependabot failed to extract the notes) to see if there's anything important
  • failing tests: investigate
  • estimate the risks: if the update is for something minor that will be detected during CI and deployment, then it might be fine to merge and then fix later even if tests haven't passed yet
  • if it looks like a PR could affect visual styles or component behavior, go to Vercel deployment and redeploy (Vercel deployments for dependabot PRs are disabled by default), then check manually

Merge order tip: try to bulk-merge multiple easy PRs first (things such as @types/*), then dependabot will rebase the remaining PRs on top of new main faster.

Manual updates

Sometimes it's easier to do updates manually, by running pnpm up -i in each package and then submitting a bulk PR with all changes.

Notes:

  • pnpm up -i -r at the monorepo root should be possible but it's blocked by this PNPM bug because of workspace:* versions that we use in versioned-components
    • PNPM bug thread recommends link-workspace-packages=deep, but it doesn't help in our case
  • sometimes pnpm up -i is not enough and you'll have to do pnpm up -i --latest instead
Clone this wiki locally