Npm-check-updates: ncu doesn't update package-lock.json

[falsandtru]

• node version: v8.0.0
• npm version: v5.0.0
• npm-check-updates version: v2.11.2

---

package.json will be updated, but package-lock.json is not. Then these two files conflict, and new versions won't actually be installed.

[p3x-robot]

delete the lock

[falsandtru]

I'm using the workaround: https://github.com/falsandtru/spica/blob/v0.0.79/gulpfile.js#L154-L156 https://github.com/tjunnone/npm-check-updates/issues/360#issuecomment-307005141

[p3x-robot]

npm-check-updates is a package.json updater, the lock is different, i dont think ncu should care about the lock, that is our responsibility. you can remove and that's it, same with yarn. (yarn.lock)

besides npm install like 50% slower than yarn.

[falsandtru]

ncu makes invalid states with node 8, it is not acceptable as a standard behavior.

[p3x-robot]

that's true, i will ask as well.

[karanjthakkar]

@falsandtru Like @p3x-robot said, at the moment, we are a package.json updater. We will tell you which modules are out of date and need to be updated. Optionally, we will also update the package.json file for you. package-lock.json cannot be updated by ncu because the lockfile also contains details about the dependencies of your dependencies. This is not something ncu is aware of. An ideal flow would be for you to:

1. Use ncu -u to update your package.json to the latest package versions
2. Run npm install to update your package-lock.json file

That being said, if you can provide any more info on what invalid states or conflict it makes with node 8, I would be happy to look into that for you.

[falsandtru]

Thanks for the response.

invalid states or conflict

When we do the steps you said, you expect the update of package-lock.json by npm install. But package-lock.json won't actually be updated.

For exampe, when package.json and package-lock.json have a dependency which version is 1, ncu -u updates the dependency version of package.json to 2. After running npm install you expect the update of package-lock.json, but the dependency version of package-lock.json and node_modules are still 1. package.json has the different version from package-lock.json and node_modules. So they have the invalid states by the conflict.

[falsandtru]

repro:

1. checkout v3.10.3 https://github.com/falsandtru/pjax-api
2. npm i
3. [email protected] was installed.
4. ncu -u
5. spica 0.0.77 → 0.0.79 (or higher).
6. package.json was updated to [email protected].
7. npm i
8. package-lock.json and node_modules were not updated, still have [email protected].

[raineorshine]

I agree that leaving the lock file in an invalid state is a problem.
package-lock.json didn't exist before, so it wasn't a concern. Now it must
be determined if it is within the scope of ncu or npm.

It is similar to the package.json in the sense that it is checked into
source control. It is similar to node_modules in the sense that it is
connected to the installation rather than the version specification. This
latter point makes me think that it is outside the scope of ncu. Just like
one must run npm update to install newer versions that were added to the
package.json, one must do something to update the package-lock.json. At the
very least ncu should inform the user of these additional required steps.

Is the package-lock.json format something we can rely on? Will it change
with new minor/patch versions of npm? This would also determine whether
it's possible to have an integrated solution.
On Thu, Jun 1, 2017 at 8:37 AM falsandtru [e-mail] wrote:

Thanks for the response.

invalid states or conflict

When we do the steps you said, you expect the update of package-lock.json
by npm install. But package-lock.json won't actually be updated.

For exampe, when package.json and package-lock.json have a dependency
which version is 1, ncu -u updates the dependency version of package.json
to 2. After running npm install you expect the update of
package-lock.json, but the dependency version of package-lock.json and
node_modules are still 1. package.json has the different version from
package-lock.json and node_modules. So they have the invalid states by the
conflict.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tjunnone/npm-check-updates/issues/360#issuecomment-305513109,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAtyxF8fZtYzBxUFKWB5UNph24OR3o3sks5r_syagaJpZM4NscOT
.

[falsandtru]

Maybe this problem should be resolved on upstream(npm). But I'm not sure about it.

[p3x-robot]

it is the same with yarn, i have to remove, but it is nothing, i understand cannot ncu do everything for free :)

but i think ncu works with the package.json, not the cache. so it is the request is invalid for me.

i guess if someone can do it it is cool, but just someone i want this and that, that is weird.

[karanjthakkar]

@falsandtru I was able to repro this bug locally with node 8 and npm 5.0.0 and 5.0.1. It does indeed seem like an issue with npm to me. It is already reported here: https://github.com/npm/npm/issues/16866

[falsandtru]

Sounds good.

[raineorshine]

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

If this is true, we may not need any change. This is exactly what ncu says to do.

[falsandtru]

npm update may unexpectedly update package.json again. We should use npm install to update only package-lock.json. https://github.com/npm/npm/issues/16866#issuecomment-305973216

[raineorshine]

npm update may unexpectedly update package.json again.

@falsandtru As far as I know, npm update will never modify the package.json. Do you have documentation of this?

[falsandtru]

I ran npm update now. Oddly, package.json was updated with no options. Anyways, whether their options, I think there is no way to expectedly resolve the conflicts using npm install or npm update for now.

[falsandtru]

FYI, now I'm using npm i --no-shrinkwrap after removing package-lock.json instead of updating package-lock.json to avoid this problem.

[RinkAttendant6]

Yes, npm install --no-shrinkwrap will update the lockfile based on package.json. However this may have the consequences of updating more than the changed stuff in package.json as npm is now disregarding the lockfile, the purpose of which is to ensure deterministic installs.

[karolyi]

+1, waiting for a resolution, until then I'll have to remove the package-lock.json to install deps from package.json.

[raineorshine]

Thanks, I'm going to mark this as a dependency bug until we get more decisive answer on npm/npm#16866.

This is not to say that npm-check-updates doesn't need to be changed to handle this better. It is just unclear the best solution until we know whether npm will have an official way to upgrade the lock file.

[kud]

I've got the same problem and I think ncu -u should remove package-lock.json but maybe via another command like --force?

I didn't understand the first time when I ncu -u && npm installed that my modules didn't update. It's a bit confusing.

[karanjthakkar]

For anyone still facing this issue, please update npm. This issue is now solved in https://github.com/npm/npm/releases/tag/v5.1.0 via https://github.com/npm/npm/pull/17508

Since your ncu workflow should now work as it did with npm4, I'm going to close this.

[nickmccurdy]

I am using [email protected] and [email protected]. ncu -u only changes package.json, not package-lock.json. However, package-lock.json appears to be updated correctly if I follow the command with npm install.

Is this intentional? If so, can ncu -u be modified to follow up with npm install automatically?

[raineorshine]

Hi! ncu will only change package.json. The package-lock.json is outside the
scope of ncu since it is related to exact installs. ncu is just concerned
with dependency specifications.
On Sun, Sep 3, 2017 at 9:00 PM Nick McCurdy [e-mail]
wrote:

I am using [email protected] and [email protected]. ncu -u only changes
package.json, not package-lock.json. However, package-lock.json appears
to be updated correctly if I follow the command with npm install. Is this
intentional or is it a regression?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tjunnone/npm-check-updates/issues/360#issuecomment-326855709,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAtyxFbpLQkGpjttYYr3LPC86pq4_epLks5se2fUgaJpZM4NscOT
.

[nickmccurdy]

Thanks, I wanted to make sure. I understand if this shouldn't be default behaviour, but could a flag be added that runs npm install automatically? In retrospect it makes sense that ncu doesn't touch the lock, but advertising a flag would be convenient and could make the default behavior more obvious as well.

[raineorshine]

Thanks! I will consider that change for the next version.

On Mon, Sep 4, 2017 at 1:58 PM Nick McCurdy [e-mail]
wrote:

Thanks, I wanted to make sure. I understand if this shouldn't be default
behaviour, but could a flag be added that runs npm install automatically?
In retrospect it makes sense that ncu doesn't touch the lock, but
advertising a flag could make it more obvious as well.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/tjunnone/npm-check-updates/issues/360#issuecomment-327021486,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAtyxJkvoKZO7MGWG-y_9JUzXCTUrTs0ks5sfFZegaJpZM4NscOT
.

[raineorshine]

This was fixed in npm v5.1.0. npm install now looks to the package.json as the source of truth.

https://github.com/npm/npm/pull/17508