Try this: npm i -g npm@latest

If this doesn't fix your issue, try to restart your pc.

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!

to overcome this issue, running the command

npm i -g npm@latest

globally and running the command

npm i npm@latest

in the project file helped me resolve the issue.

I encountered the same problem today. I am working on a project with a developer having a different version of npm (>7) and i ran into the same issue. I simply upgraded my npm version to the latest version which was being used by the other developer as mentioned above. Following are the steps to upgrade your npm (for windows):

First, ensure that you can execute scripts on your system by running the following command from an elevated PowerShell. To run PowerShell as Administrator, click Start, search for PowerShell, right-click PowerShell and select Run as Administrator.

Next execute following commands:

Set-ExecutionPolicy Unrestricted -Scope CurrentUser -Force

Then, to install and use this upgrader tool, run the following command (also from an elevated PowerShell or cmd.exe). Note: This tool requires at least Node v8

npm install --global --production npm-windows-upgrade
npm-windows-upgrade

Want to just install the latest version? Sure:

npm-windows-upgrade --npm-version latest

Now you can select the version which you want to install from the command line.

https://github.com/felixrieseberg/npm-windows-upgrade

The above link is the tool which I've used. This tool is both for Linux/Windows. I hope it will help.

As far as I can see the npm docs say that npm v6 will work with version 2 lockfiles in spite of the warning, so you don't need to do any of the things suggested in the accepted answer and can safely ignore the warning message.

In the npm 7 release notes they said:

One change to take note of is the new lockfile format, which is backwards compatible with npm 6 users. The lockfile v2 unlocks the ability to do deterministic and reproducible builds to produce a package tree.

In the npm docs it says (my emphasis):

lockfileVersion

An integer version, starting at 1 with the version number of this document whose semantics were used when generating this package-lock.json.

Note that the file format changed significantly in npm v7 to track information that would have otherwise required looking in node_modules or the npm registry. Lockfiles generated by npm v7 will contain lockfileVersion: 2.

• No version provided: an "ancient" shrinkwrap file from a version of npm prior to npm v5.
• 1: The lockfile version used by npm v5 and v6.
• 2: The lockfile version used by npm v7, which is backwards compatible to v1 lockfiles.
• 3: The lockfile version used by npm v7, without backwards compatibility affordances. This is used for the hidden lockfile at node_modules/.package-lock.json, and will likely be used in a future version of npm, once support for npm v6 is no longer relevant.

This is why they can automatically upgrade lockfiles from v1 to v2, which you mention, without breaking anything.

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

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 app@1.0.0 No description
npm WARN app@1.0.0 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.