Skip to content
This repository has been archived by the owner on Aug 11, 2022. It is now read-only.

no possibility to update just the package-lock.json beside deleting, and recreating it #17487

Open
1 of 4 tasks
mechanoid opened this issue Jun 28, 2017 · 0 comments
Open
1 of 4 tasks

Comments

@mechanoid
Copy link

mechanoid commented Jun 28, 2017

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?

As already mentioned by @eamodio here there seems to be a misconception in how updates of the dependencies are handled right now. Or at least, there is a valid (IMHO the most valid) scenario, that is currently not supported.

In my opinion, if you've created a semver range-declaration (eitherway if it is done manually or automatically) for a dependency, you would like to update the dep-reference inside of the package-lock.json according to your semver-rules from time to time.

So for example lets take a package declaration like this for is-promise, which exists in a greater version of 2.1.0 at this moment.

package.json

"dependencies": {
  "is-promise": ">=2.0.0" 
}

package-lock.json

"is-promise": {
   "version": "2.0.0",
   ...
}

Running npm update --no-save, will

  • install the new version 2.1.0 to the node_modules folder
  • not update the package-lock.json (which I think is wrong)
  • not update the package.json (which is as expected)

Calling npm update --save (or npm install is-promise --save) will

  • install the new version 2.1.0 to the node_modules folder
  • package-lock.json (which I consider right)
  • will update the semver-range inside of package.json to the latest version (which I consider right for --save)

So --save is definitely doing what it should, but --no-save in my opinion is definitely not.

While that may be a wanted solution for some people too, to install libs, they don't want to be referenced in the package-lock.json at all, this behaviour is really a missing peace. Maybe it is necessary to introduce a new config-option to not break the former behaviour.

How can the CLI team reproduce the problem?

create the initial dependency settings:

npm install is-promise@2.0.0 --save

try to update only the package-lock.json

npm update --no-save
# or
npm update is-promise --no-save

Afterwards, the package-lock.json still references is-promise@2.0.0, but the node_modules-Folder contains is-promise@2.1.0.

supporting information:

  • npm -v prints: 5.0.4
  • node -v prints: v8.0.0
  • npm config get registry prints: https://registry.npmjs.org/
  • Windows, OS X/macOS, or Linux?: OS X
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant