Packages upgrade examples
And upgrading any package, even to a
patchversion, can result in a completely broken app.
In order to reduce risks associated with packages, we've made some very opinionated decisions about how to handle our dependencies, by default.
Those decisions are based on years of experience with production systems, and are meant to avoid breaking production apps unexpectedly.
First of all, we only install fixed versions.
"@amplitude/react-amplitude": "1.0.0", the
"1.0.0" is a fixed version, it won't change unless we manually/expressively do it.
We don't use any automation like
Also, we configured NPM/Yarn to always install fixed versions by default using
npm config set save-exact true
This alone reduces the risks tremendously. Coupled with
yarn.lockfile, it makes your deployments much safer.
In order to simplify packages upgrade, we provide a small utility tool (which is nothing more than an alias to a
yarn command that too few people know about).
The main advantage of upgrading your packages this way is that it's interactive.
You can go through all packages using up/down keyboard arrows, and select those you want to update by pressing the space bar.
And then, commit each change independently, and push them independently too.
This alone, will save you tons of time if any package creates a regression, because even if you don't catch the regression immediately (it may only affect part of your UI/workflow that isn't covered by any automated test).
Then you'll still have the ability to compared each deployment afterwards, and figure out when did the regression occur first, and thus know which package caused it.
Doing this will definitely save you hours of digging around compared to a easy massive upgrade of all deps at once.
To save up some time, we recommend grouping related packages upgrade together. For example, we usually upgrade all apollo-related packages at once.
Not only it reduces the amount of commits/pushes/deployments, but also it makes sense because sometimes those related package are meant to be updated together.
It's usually the case with eslint, react, typescript, etc. In the end, it's up to you to learn what feels right to group together.
If you look at the above PR, you'll notice we did some 31 commits to update 39 packages in total.
We ran into very tough bugs (crossed regression caused by 2 different packages, one of them through a
patchversion upgrade) and it would have been very hard (not to say impossible) to figure out the root cause if we had upgraded everything at once.