Up'em updates your dependencies to latest, so you don't have to.
npm outdated --jsonthrough
- When it's done
npm installand re-run your automated quality checks.
You can e.g. set up some npm scripts so you can
npm run upem
and watch cat videos in the mean time:
A similar approach in a
do the trick as well.
If you want to keep versions untouched by up'em, put an
package.json with a
donotup key, listing the stuff you don't
want to upgrade e.g.
So what's this opionated and respectless business?
Latest is best
up'em does not respect your current version preferences.
they all get updated to the latest version. It will leave the
in place as per your
npm config settings, though.
npm outdated says:
Package Current Wanted Latest Location midash 1.8.2 ^1.8.0 2.0.1 your-golden-package
With the default
npm config, running
npm outdated --json | upem will
set midash' version to ^2.0.1
There's no warning system for major version upgrades. I've found the most reliable way to find out if nothing breaks is to run your automated QA after updates.
Still respecting save-exact and save-prefix
Up'em does respect the
save-prefix npm config
settings, just like
npm --save and
npm --save-dev would do:
save-exact = trueit will pin the version. In the above example it will pin
save-exact = falseit will look at
save-prefixin your npm config:
save-prefix = '^'or save-prefix isn't specified, it'll caret-prefix the version:
save-prefix = '~'it'll tilde-prefix the version:
If you want to be sure of npm's 'default' behaviour over all machines and collaborators, use this one:
save-exact = falsesave-prefix = '^'
Whatever your preferences: commit a
.npmrc at the root of all your repos so
npm, yarn and upem behavior is the same accross all machines and collaborators.
Not updating peerDependencies
As of version 5.0.0 Up'em leaves peerDependencies alone. Typically you'll use
ranges for peerDependencies (
>=1.0.0 <3.0.0). Those have different
requirements from your regular dependencies. They can either be more lenient,
or more strict.
An example where you might want to be more lenient is when in your devDependencies
want to use latest TypeScript, but you still might want to support TypeScript 3
and up. In that case you will want to keep the
"typescript": ">=3" in your
An example where you might want to be more strict is setting an upper limit to
your peer dependencies version e.g. because you don't support beyond that version
or don't know whether you can (
"typescript": ">=3.0.0 <6.0.0").
I've been a happy user of npm-check-updates for a long time. It's getting out of date, though. It's using npm 3 (which has not caused troubles yet, but it might) and its dependencies have serious security issues. I have been looking into jumping into fixing it, but I soon found out it would take a serious commitment to do so.
I realized I used only a subset of npm-check-updates' capabilities, and rolling my own would only take a sunday afternoon...
- If you're using yarn and its lock feature you should probably look into using the yarn upgrade --latest or yarn upgrade-interactive --latest commands.
- npm-check-updates - use that if you need something more feature rich and less opinionated and don't mind the outdated (/ insecure) dependencies.
- npm-check - never used but has a lot of stars & downloads, so probably legit. Feature rich.
- Cloud services (like greenkeeper and renovate) will be happy to do this trivial task for you as well.