-
Notifications
You must be signed in to change notification settings - Fork 3k
why is package-lock being ignored? #17979
Comments
Is anyone able to give me some help with this please? I am using npm 5.3.0 and I need my production environment to be the same overtime, which is why I was originally using the package-lock.json. Please can someone give me some information on how I should now have my project set-up as package-lock.json is now updated every time and not locked at all. |
The concept of the This document states that npm would install dependencies as they are specified in the lock file. However, as you observed, this is not true at all and I can reproduce the exact same behaviour with npm 5.3.0. As a current workaround, I pin my dependencies in @jakeNiemiec instead of just voting this question down it would be nice if you would provide any helpful explanation or guidance instead. Lock files are anything else then transparent at the moment and infact behave fundamentally different as they do on other platforms, such as PHP/composer for instance. The confusion here is more then understandable. |
Btw., see this Stack Overflow discussion, which also raises more questions than it solves: https://stackoverflow.com/questions/45022048/why-does-npm-install-rewrite-package-lock-json |
Thank you @jotaen, I have been trying to highlight this issue for over a week now. Currently I have had to rollback to npm 5.0.3 as this issue doesn't seem to occur there. I looked at the change log and saw that when npm 5.1.0 was released it allowed the package.json to trump the lock file, so it seems suspicious that the issue started happening after that. |
Thanks for pointing to the Changelog: the root cause is #16866, which is the proof that the current behaviour is indeed intended. There was already a lengthy discussion happening in this PR, however, I doubt that the documentation was properly updated after the change being applied. In my eyes #16866 is not a good decision, because the introduced behaviour is not predictable and transparent to the user. Also apparently, the naming I doubt that this design decision is reverted, so I guess we now have to deal with it (or switch to yarn or whatever). At least the documentation should be updated properly to allow users to understand the current behaviour. Last note: #16866 is a breaking, non-backward compatible change, which shouldn’t have been introduced as minor version upgrade. |
@jotaen this is indeed what I have been trying to highlight with this question here and my posts on the other feed. The fact that now the lock file no longer locks means it has no purpose in terms of locking packages. A suggestion to have an additional flag (i.e. npm install ---lock-file) to enforce an installation ONLY from the lock file is a decent one, but I do not know where to officially make this request. |
@kidd3 This might be helpful: I am neither a collaborator, nor an employee of npm. But based on my experience you can either:
So your best chance might be to make the changes in the code yourself, reference it in this issue, and hope the PR is accepted. P.S: Just as a pointer, you will want to start with making your changes to this file, if you decide to go with the DIY option: |
Thanks for pointing that out. The only thing that is a bit unfortunate though, is that such a PR would basically be a revert of #16866, which makes it quite unlikely to be accepted. This whole topic has already been discussed back and forth in that PR. The missing bit for me is now to update the documentation accordingly, which is misleading if not incorrect. On the page about package locks it says:
This is not true, as the generated module tree might be (as of v5.1.0) a combined result of both Also the documentation should point out a way how to perform truly reproducible builds. That was the reason why package locks have been introduced in the first place and that was also what a lot of people obviously had relied on since |
@jotaen Very true. That exact part of the documentation is a bit misleading. It might be a good idea to change that as well. |
@Maziar-Fotouhi that makes sense, thanks for clarifying. Maybe it’s an idea to extract the outcome of the discussion here into separate issues. I doubt that this issue here deserves the right attention, since the title is rather suggesting a support request. I opened #18103 for changing/updating the documentation. @kidd3 Maybe you could also open a new issue in which you present the idea of introducing some sort of CLI option. (Or, if you have the time and feel confident, you could directly work on a PR.) If you think that your needs are covered thereby, this issue here could be closed then. |
@Maziar-Fotouhi thanks for the information, but unfortunately I don't have enough time right now to attempt to fix this issue myself, I have already had to rollback to v5.0.3 to continue my own work. |
I wouldn’t go so far and term it “completely unusable” (it somehow used to work prior to npm 5 as well). But it’s definitely a big problem and also a regression that I don’t think people are aware of enough. Doesn’t it do the trick for you to pin your dependencies in Regarding your idea of the additional CLI option I think it’s still worth it to open a separate issue with a feature request specifically asking for that. Maybe that’s heard better by the community or the maintainers. |
Strange that the other thread doesn't have the simplest solution... Which updates package.json and package-lock.json
The change in 16866 broke my CI builds today... |
I thought I was getting this problem but when I try and reproduce it in isolation (
At this point
This makes no changes: If I change the version in
Now the lock file and installed package get updated to This is all as I would expect. Provided Am I missing something? |
@tamlyn Yes, what you describe is exactly the way it currently works. However, it’s not the way it used to work prior to 5.1.0 and it’s also not the way that is currently documented. The difference between you and the issue creator is This wasn’t the case prior to npm 5.1.0, where |
Wow. Every time a developer does |
Hey y'all, here's some notes:
|
Thanks for responding @zkat. Your list is exactly how I expect the lock file to work. What I've been seeing is a lot of churn just from I'll give 5.4.0 a shot and see if that resolves what we're seeing. I really do appreciate the update on the state of things. |
@greggb if you're on different platforms, you'll have to wait a wee bit because we're still pending a patch to make lockfile generation consistent across them. |
Ah, got it |
So |
@laserus Ok, that's weird. I thought I had reproduced this with a new clean project, but apparently I haven't. So I looked a bit closer at the project that consistently has this issue (i.e. delete Thank you for trying to reproduce this. |
I think the best path forward is to install according to the lock file except for in a few different scenarios.
Notably this is how Bundler and CocoaPods work. The |
There should be an option to install, but not update the package-lock.json. As it stands I can't do a deploy and be sure that the deps installed are the same ones I have. |
@markwellis |
@SleepWalker that only doesn't update the package-lock.json file, it does not make sure that the versions installed are the ones declared in package-lock.json i think |
@daften correct. It's the equivalent of doing |
@ameenross but if you'll use the exact versions in package.json, it will, actually install the correct versions and won't mess up your package-lock.json in deploy environment. So in dev environment you are using: It won't install wrong dependencies. |
@SleepWalker The reason why every package manager has 2 separate files and uses semver is so you wouldn't need to put exact versions in the main dependencies file. Using a package.json with exact numbers defeats the purpose in a large part. Package locking on npm is just broken, and we're switching to yarn because of this. |
@SleepWalker well that might scratch this itch, but introduces other problems. If you then want to upgrade your dependencies you have to change all of the version definitions in |
My original issue was when there are ranges specified within the package.json file, as running a npm install causes the package-lock.json file to be automatically updated every time a newer version of a package gets released, meaning there was no control over what gets installed and impossible to keep it "locked" (for which the lock file, by it's name, should be doing). |
I'm with @daften here. I think there's a lot of value in going with the path of least surprise and emulating the behaviour of other package managers in other ecosystems that use the manifest/lock file approach. See
|
@shellscape nah I was wrong. npm behaves as I expect it to: The following should modify the lockfile: |
@kidd3 That is literally what the newest versions fix. I'm going to close this as the now current behavior is AFAIK correct:
You can see 3 in action if you use a package-lock locally but don't commit it. When you do a pull, you'll get an updated On the horizon is cipm which will only read your If you do run into a case where (I'm also locking this issue because comments on closed issues are by-and-large not seen by the npm team. This doesn't mean we don't want to hear from you, in fact, the opposite. We want you to talk to us in a way we can hear, which is why I'd like you to either open a new issue or chat with us over at WeAllJS's #npm channel.)) |
I'm opening this issue because:
I had been using npm version 5.0.3 in my project and the package-lock.json file had been working exactly as I expected. However, upon updating my npm version to 5.3.0, my package-lock.json no longer works.
Example:
package.json:
"Package-A": "^v1.0.0"
package-lock.json:
"Package-A": { version: 1.0.0 }
When I have no node_modules folder and I attempt to do a fresh npm install, previously in npm version 5.0.3 this would install version 1.0.0 (as this is what the lock file states). However, now on npm version 5.3.0, a fresh install will cause any version from the range ^v1.0.0 to be installed, completely ignoring the lock file.
I want my project to be installed identical every time based on the lock file, this surely is what a lock file is supposed to do?
How can I make my project useable in a projection environment to ensure that the lock file is the only point of reference for npm install?
The text was updated successfully, but these errors were encountered: