I also find this behavior problematic. For now I'm working around it by changing my npm install command to rm -f package-lock.json && npm install. Obviously, that's not an elegant solution, and somewhat defeats the purpose of having a lockfile in the first place.

Same problem here with npm 5.0.0 and node 7.3.0 on macOS.
Each time I add a dependency in my package.json file, I run npm i and I've got this :

$ npm i 
removed 3 packages in 5.953s

My new dependencies are not installed after this. I had to delete the package-lock.json and re-run npm i and this time my new dependencies are correctly installed.

If you run npm update package-lock.json gets updated and the new dependency is installed.

I think adding npm update command's new option to update only package-lock.json will be a better solution. And then npm install would be better to throw an error or show alerts of the conflicts of the two files.

npm update does not solve it for me.
For some reason it keeps thinking that some package versions are invalid when I try to use npm update.
This is super annoying and a huge downside to npm@5. I'm really disappointed at npm!
npm should not be that hard to use. It was much better when a simple npm install did the job.
Now I have a good reason to switch to yarn!

Yea, this has been causing me serious grief the last couple of days. The "speed up" isn't worth the constant requirement to delete my package-lock file every time I need to update a dependency... Changing my package.json never updates my package-lock, and npm update after changing the version doesn't update it either.

@zone-ghost thats exactly my point

we are updating our dependencies automated every moring ... since two days we have a up-to-date package.json file ... but we dont get the new npm cuz the package-lock.json points to the wront version.

to delete the package-lock.json is an absolute useless step ... but fix it.

is there a way to update the package-lock.json??

Put "preinstall": "npm config set package-lock false" in your scripts to disable package-lock.json.

If we wanted yarn, we would have used that. This half-hearted attempt helps no one.

Edit: I merely wanted to highlight that npm should not try and be yarn at the expense of npm. They are both solid package managers built to solve different problems.

@jakeNiemiec It helps the people who had their builds sped up by whole minutes due to package-lock.json

I don't get it. So what are you supposed to do after you update your package.json? Run npm update? I'm getting the same "invalid" messages as @Maziar-Fotouhi does when I try that.

Do we just need a npm lock command like we had npm shrinkwrap?

This just generates the shrinkwrap with current dependencies (so has the effect of updating the lock if you've added a new dependency to package.json).

It seems to me that there's a lot of differing use cases and personal preferences for the package lock file. Generally people like it, but the default behavior doesn't work for everyone. I'm highly doubtful we'll ever be able to find a default behavior that works for everyone.

So why not make the package lock configurable and manually controllable?

For example, why not have a configurable field in .npmrc that lets users disable package-lock? Or another option that you require explicit updates to package-lock.json? (this latter approach is my personal preference)

And then provide devs tools to manually run the package-lock algorithm. Like

npm update-lock mycoolmodule

Those of us who opt non-default behavior will still need a way to configure our package-lock to our liking.

What do you think of this two pronged proposal?

1. Make package-lock configurable via .npmrc or some other way
2. Provide low level commands to update and set package-lock

Oh, good point that package-lock.json can already be turned off in .npmrc. But that is the only configuration possible. On or off. It needs to be more tunable. For instance, a setting to make package-lock only update when explicitly updated:

package-lock=explicit-only

And then commands to tune the package lock, such as:

npm update-lock mycoolmodule

Tldr, the fact that .npmrc lets us turn package-lock on or off doesn't get us nearly close enough to making the package-lock workflow customizable.

@scottmas please see this comment #17979 (comment) by @iarna.

should we turn off the package-lock in .npmrc or not to avoid install errors?

Has there been any consensus here? I participated in this thread months ago but today got completely ass-bitten by package-lock. Are there any behaviour changes between npm 5.0.x and 5.5.x?

@NathanCH It looked like things were fixed in 5.4.x

What happened?

See #18286 for the addition of a --from-lock-file (or similar) flag that would install only from the package-lock.json without modifying it.

I can confirm that clearing the package lock file, the issue is solved

If anyone needs to support Windows, this appears to work for our team:

{
  "scripts": {
    "clean": "rm -Rf node_modules/ && rm -f ./package-lock.json && npm cache clean -f",
    "clean_windows": "IF EXIST node_modules rd /s /q node_modules && IF EXIST package-lock.json DEL package-lock.json && npm cache clean -f",
    "rebuild": "npm run clean && npm i",
    "rebuild_windows": "npm run clean_windows && npm i"
  }
}

After running npm i <some-package>, those on Windows machines use npm run rebuild_windows to ensure the application's dependencies are actually updated.

I understand that manually updating package.json won't update package-lock.json.

It is for issues like this that we need package-lock.json removed. Yarn uses yarn.lock and won't stand in our way if we modified package.json

Manually updating a package.json should be updating package-lock.json as of several versions ago. If you're not seeing these updates, please first update to the latest npm version before submitting a new issue with specifics. In the meantime, I'm going to lock this thread because I think it'll only be confusing to others if there's folks saying otherwise due to misunderstanding or older versions.