-
Notifications
You must be signed in to change notification settings - Fork 23
Dependency updates
Vyacheslav Matyukhin edited this page Feb 3, 2024
·
4 revisions
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
- example:
- is it a patch, minor or major-level update? do you know if the updates for this package are usually smooth?
- examples:
codemirror
andeslint
are quite stable and backward-compatbible;next
sometimes break things in minor releases
- examples:
- 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.
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 ofworkspace:*
versions that we use inversioned-components
- PNPM bug thread recommends
link-workspace-packages=deep
, but it doesn't help in our case
- PNPM bug thread recommends
- sometimes
pnpm up -i
is not enough and you'll have to dopnpm up -i --latest
instead