package-lock.json file not updated after package.json file is changed

I'm opening this issue because:

npm is crashing.
npm is producing an incorrect install.
npm is doing something I don't understand.
Other (see below for feature requests):

What's going wrong?

clean project with some deps in package.json.
you run npm i
modules are installed and package-lock.json file is created.
say you update module A in package.json file.
you run npm i. I would expect this updates the package-lock.json file but it doesn't. which results in module A not being updated.

How can the CLI team reproduce the problem?

any project. see description above.

supporting information:

npm -v prints: 5.x.x
node -v prints: 7.x.x
npm config get registry prints: private one
Windows, OS X/macOS, or Linux?: macOS
Network issues:
- Geographic location where npm was run:
- I use a proxy to connect to the npm registry.
- I use a proxy to connect to the web.
- I use a proxy when downloading Git repos.
- I access the npm registry via a VPN
- I don't use a proxy, but have limited or unreliable internet access.
Container:
- I develop using Vagrant on Windows.
- I develop using Vagrant on OS X or Linux.
- I develop / deploy using Docker.
- I deploy to a PaaS (Triton, Heroku).

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.

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

@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

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

@Maziar-Fotouhi don't forget a npm cache clean --force in there too.

what is the point if you don't use the lock file

I only do this because updating 'individual packages' was removed. I can't: npm update @me/myCustomDep anymore.

@zkat

Glad we were able to sort that out, but I feel really bad for those coming from Google and seeing this mess of (mostly true) information on package locks. @zkat or another maintainer might consider locking this issue.

Removed `package-lock.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?

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

It already works that way. Scroll up to my first comments to see an example of this.

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

@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

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

Navigation Menu

Repository navigation

package-lock.json file not updated after package.json file is changed #16866

I'm opening this issue because:

What's going wrong?

How can the CLI team reproduce the problem?

supporting information:

99 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

package-lock.json file not updated after package.json file is changed #16866

Description

I'm opening this issue because:

What's going wrong?

How can the CLI team reproduce the problem?

supporting information:

Activity

JamesMessinger commented on Jun 1, 2017

yomansk8 commented on Jun 1, 2017

gyszalai commented on Jun 2, 2017

falsandtru commented on Jun 3, 2017

treadingwell commented on Jun 9, 2017

hyposimon commented on Jun 9, 2017

jakeNiemiec commented on Jun 9, 2017

legodude17 commented on Jun 9, 2017

fxck commented on Jun 12, 2017

chrisui commented on Jun 12, 2017

jakeNiemiec commented on Jun 12, 2017

99 remaining items

jakeNiemiec commented on Aug 8, 2017

scottmas commented on Sep 27, 2017

jakeNiemiec commented on Sep 27, 2017

scottmas commented on Sep 28, 2017

jakeNiemiec commented on Sep 28, 2017

vikrantsingh47 commented on Oct 2, 2017

nathan-charrois commented on Oct 5, 2017

jakeNiemiec commented on Oct 6, 2017

alexkreidler commented on Oct 6, 2017

FrancescoBorzi commented on Oct 26, 2017

aervin commented on Nov 24, 2017

smithaitufe commented on Dec 15, 2017

zkat commented on Dec 16, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions