Is there any way to fix package-lock.json lockfileVersion so npm uses a specific format?

Question

If two different developers are using different versions of node (12/15) & npm (6/7) in a project that was originally created using a package-lock.json "lockfileVersion": 1, when the developer using npm 7x installs new packages it seems that the package-lock.json is re-created using "lockfileVersion": 2.

This seems to cause issues for the developer using npm v6, as it tries to work with the lockfileVersion 2, but it ends up producing new diffs.

npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!

Is there any way to specify to newer versions of npm to only use "lockfileVersion": 1? Or do we just have to get all devs on the same version of npm?

Answer 1

Is there any way to specify to newer versions of npm to only use "lockfileVersion": 1? Or do we just have to get all devs on the same version of npm?

I will advise you to pin the Node/NPM version and align it across your environments (development, staging, and production).

you can leverage nvm for managing Node version by adding to your project .nvmrc file (don't forget to store it in your source control).

for instance, .nvmrc will look like:

$ cat .nvmrc
14.15.0

then, you can use nvm install && nvm use to use the pined version of Node.

NPM also supports engines:

You can specify the version of node that your stuff works on:

{ "engines" : { "node" : ">=0.10.3 <0.12" } }

And, like with dependencies, if you don't specify the version (or if you specify "*" as the version), then any version of Node will do.

If you specify an "engines" field, then npm will require that "node" be somewhere on that list. If "engines" is omitted, then npm will just assume that it works on Node.

You can also use the "engines" field to specify which versions of npm are capable of properly installing your program. For example:

{ "engines" : { "npm" : "~1.0.20" } }

Unless the user has set the engine-strict config flag, this field is advisory only and will only produce warnings when your package is installed as a dependency.

When utilizing the engines field and make npm fail when the version constraints are unmet, set engine-strict=true (since it is false by default) in .npmrc file or as an npm_config_engine_strict=true environment variable

If set to true, then npm will stubbornly refuse to install (or even consider installing) any package that claims to not be compatible with the current Node.js version.

This can be overridden by setting the --force flag.

Another approach is to use a Docker container as a runtime environment for development and execution, which implies that you neither need to install Node, nor NPM. e.g.

$ mkdir my-project
$ cd my-project
$ docker run --rm -it -v $PWD:/app --entrypoint /bin/bash --workdir /app node:14.15.0
root@4da6ee3c2ac0:/app# npm init -y
Wrote to /app/package.json:

{
  "name": "app",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}


root@4da6ee3c2ac0:/app# npm install
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

up to date in 1.694s
found 0 vulnerabilities

root@4da6ee3c2ac0:/app# exit
exit
$ ls -x1
package-lock.json
package.json

As you can see, with neither Node, nor NPM:

1. Created a new directory for a fresh project
2. Spun up a Node Docker container, which comes with Node and NPM
3. Created a new project (npm init -y)
4. Exited the Docker container
5. Listed the files within the working directory, where the container was spun

Since the docker run command above is long, you might wish to leverage docker-compose for a more streamlined workflow.