Nothing Prevents Misery


    7.0.1 • Public • Published


    Up'em updates your dependencies to latest, so you don't have to.


    • Pipe npm outdated --json through upem.
    • When it's done npm install and re-run your automated quality checks.
    • Done.


    You can e.g. set up some npm scripts so you can npm run upem and watch cat videos in the mean time:

      "scripts": {
        "check": "npm-run-all --parallel lint lint:archi test",
        "lint": "eslint src test",
        "lint:archi": "depcruise --validate -- src test",
        "lint:fix": "eslint --fix src test",
        "test": "jest",
        "upem": "npm-run-all upem:update upem:install lint:fix check",
        "upem:update": "npm outdated --json | upem",
        "upem:install": "npm install"

    A similar approach in a Makefile, gulpfile.js or Gruntfile would do the trick as well.


    If you want to keep versions untouched by up'em, put an upem section in your package.json with a policies key, listing the stuff you don't want to upgrade. It supports thes policies:

    • pin - to keep the dependency on exactly the specified version),
    • wanted - so it respects any version ranges you specified in the *dependencies fields) and
    • latest` - where it takes the most recent version, regardless what is specified in *dependencies fields.

    latest is also the default - that's what you'll get when no policy is defined or when there's no upem section in package.json.


      "upem": {
        "policies": [{
          "package": "glowdash",
          "policy": "pin",
          "because": "version >2 of glowdash doesn't support node 6 anymmore, but we still have to"

    So what's this opinionated 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 ^ and ~ in place as per your npm config settings, though.

    If 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

      "midash": "^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-exact and save-prefix npm config settings, just like npm --save and npm --save-dev would do:

    • when save-exact = true and the dependency doesn't have a range prefix it will pin the version.
    • when save-exact = true and the dependency does have a range prefix it will retain that prefix. In the above example it will set the version of midash to ^2.0.1.
    • if save-exact = false it will look at save-prefix in your npm config:
      • if save-prefix = '^' or save-prefix isn't specified, it'll caret-prefix the version: ^2.0.1
      • if save-prefix = '~' it'll tilde-prefix the version: ~2.0.1

    If you want to be sure of npm's 'default' behaviour over all machines and collaborators, use this one:

    save-exact = false
    save-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 (>=3 or >=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 peer dependencies.

    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...



    Build Status Maintainability Test Coverage npm stable version MIT licensed


    npm i upem

    DownloadsWeekly Downloads






    Unpacked Size

    19.8 kB

    Total Files


    Last publish


    • sverweij
    • foureightone