There should be a way to align package.json from package-lock.json (fully offline)

[jakub-g]

• I have read the list of known issues before filing this issue.
• I have searched for similiar issues before filing this issue.

• node version: 12.6.0
• npm version: 6.9.0
• npm-check-updates version: 4.0.1

---

Context

I ran ncu in our project and compared the output with npm outdated and noticed that ncu outputs way more things.
Looking closer, the issue is in the following situation:
package.json

    "node-bourbon": "^4.2.3",

package-lock.json

    "node-bourbon": {
      "version": "4.2.8",

In this situation ncu tells me to update to 4.2.8 because it's oblivious that I'm already on that version thorough package-lock.json entry (this can happen if in the past package-lock was deleted and regenerated from scratch via npm install, which unfortunately doesn't update package.json; quite an annoying "feature" of npm to be honest).

Anyway, my point is not that this is wrong, but that the output mixes "updates that really need to happen" vs "updates that are no-ops because you already have new version of dependency, but just package.json lies to you".

Proposal

It would be nice to have a switch like --alignFromLockFile which will work fully offline and the only thing it would do would be finding updates to package.json based on contents of package-lock.json.

So for example:
input:
package.json: foo: ~4.2.3
package-lock.json: foo: 4.2.8

output:
package.json: foo: ~4.2.8

With this thing in place, a developer confronted with a huge list of updates can do two commands:

• first, just do the "no-op" updates ncu -u --alignFromLockFile which do not need any testing, because they just update package.json to reflect the status quo
• then rerun ncu to see what are actual updates to be done and tested

The general point is, when there are 50 deps to update, it's good to split the work in a few phases and know how much attention should be paid to each dep update (which ones require testing and checking CHANGELOG etc.) to minimize the risk.

[raineorshine]

Thanks for the clear explanation. Makes sense. Interestingly, a similar behavior (antedating package-lock.json) was default in v2, but was changed in v3 because it was confusing and unexpected for many users. Since then npm-check-updates has adhered to the simple but clear behavior of always upgrading all updates regardless of package-lock or installed dependencies. This is in alignment with the purpose of npm-check-updates to actively ignore version constraints and force latest versions.

That said, if a user knows what they are doing, there is no harm having this functionality available on a flag. I wish that there were active contributors to npm-check-updates, but until that happens, I'm more than happy to provide guidance on a PR.

[jakub-g]

For info, for now I opened this PR: npm/lock-verify#7
I will think in the coming days what would be the best solution to the problem (should this change be incorporated into ncu at all, and how).

[paulh-adion]

This issue is why I keep using version 2.14.0 and refuse to upgrade.

[raineorshine]

Closing with the revive-me tag for interested contributors. See #484.