DEV Community 👩‍💻👨‍💻

Devin Rhode
Devin Rhode

Posted on

Great node version management

Here's a package.json:

  "...": "...",
  "engines-comment": [
    "When new node/yarn versions are released, you may see these errors:",
    "  engine \"yarn|node\" is incompatible with this module.",
    "Just bump version numbers below:"
  "engines": {
    "node": "16.13.x",
    "yarn": "1.22.15"
  "node-version-rationale": [
    "Give some flexibility by ignoring patch updates",
    "but otherwise force developers to update node every couple 1-4 months"
  "yarn-version-rationale": [
    "Exact yarn version helps us produce consistent yarn.lock files"
Enter fullscreen mode Exit fullscreen mode

Our pipeline is set always try and use the latest lts.

Our pipeline will run:

# Always run install+build:ci with latest LTS, to see output
# But verify engines at very end
yarn config set ignore-engines true

yarn install --frozen-lockfile

yarn build:ci

yarn config set ignore-engines false
yarn verify-node-and-yarn-versions-against-package-json-engines
Enter fullscreen mode Exit fullscreen mode

So, we always use latest node LTS in our pipelines. BUT, we don't let a major version bump just fly by - as safe as node releases are - we will require explicit acknowledgement from a developer to use new major version of node LTS.

Now, why use node 16.13.x?
If you want to be strict - by all means set an exact version number. Based on node LTS release history, I estimate you'll need to update package.json engines version every 1-4 weeks.

But if you specify only an exact minor version, you'll only need to update package.json engines version about every 1-4 months.

v14 LTS was cut 10/27/2020
minor version bumps happened on: 9/28, 5/11, 2/23, 10/27
4 months, 3 months, 4 months

v12 LTS was more turbulent (probably due to es modules): 3/30, 2/23, 11/24, 10/6, 6/2, 5/26, 2/11, 2/5, 12/17
1 month, 3 months, 2 months, 4 months, 1 week, 3 months, 1 week, 2 months

v10 LTS: 2/23, 10/27, 7/21, 3/26, 2/5, 12/17, 10/22, 5/28, 12/26, 11/27, (10/30-first v10 lts)
4 months, 3 months, 4 months, 2 months, 2 months, 2 months, 5 months, 7 months, 1 month, 1 month

On mac and linux, if you use NVM, you should setup a bash or zsh profile script to automatically set node version when you cd into a project with a .nvmrc file.

We set out .nvmrc file to: lts/* which means "latest lts" - this is the same as our ci/cd pipeline.

This means, every time you cd into a project, nvm will use the latest lts. (I am assuming nvm does a network call at some point to see what lts/* should map to)

However, if some developers have not setup this zsh/bash script, or are using windows, or maybe they just simply don't want to automatically update node – Then the package.json engines check will force them to at least update every 1-4 months.

Updating the node minor version every 1-4 months feels like a great cadence to maybe update dependencies in your package.json.

Tangent: I need to do some digging on, it may be the only option for some developers using windows.

Top comments (0)

Build Anything...

Use any Linode offering to create something for the DEV x Linode Hackathon 2022. A variety of prizes are up for grabs, inculding $1,000 USD. 👀

Join the Hackathon <-