PACKAGE-LOCK.JSON NIGHTMARE

[wayofthefuture]

Let's talk about the purpose of package-lock.json.

Supposedly, it is so we stop having the "works on my machine" problem, right? I can't figure out though, when I commit a package-lock.json file to the repo, then the other developer does an "npm i," all of the sudden he has a NEW package-lock.json file he has to commit. He hasn't made any changes to the package.json, he has only installed the project. Now, he has a package-lock.json that he has to commit to the repo, then the next developer has to do the same thing and the never-ending loop continues. It begs the question, what is the state of the lock file? Who knows, lets rm -rf node_modules and the lock file and get this thing clean again.

Now, we can't switch between branches and update to that branches package-lock.json because every time we try to npm i to mimic that lock, a new lock file is created. Then, we have to either reset the branch to get rid of it or git rm the lock file to remove the changes.

I think anyone who has spent some time working with multiple developers and having to switch between branches that may temporarily have different package.json configurations will totally understand the problem.

If I update package.json then install and create the lock file, then subsequent npm installs where package.json has NOT been modified should NOT cause a new package-lock.json file to be created. There should be no differences. My two cents.

Thanks

[Butterfly]

First, my current disclaimer that I'm still 100% newbie at both git and this whole npm and nodejs thing so sometimes I say very naive things. :smile:

I started a comment on a different npm/npm issue yesterday but then left my comment unsent to ponder some more. It was about package.json with my impression being that things are sometimes not being flushed out properly or something as people go about work on their projects. Hence where people find if they delete, sometimes even uninstall/reinstall, things then start working as expected again.

What you're saying here... actually kind of sounds similar. It kind of sounds like maybe you're hitting on something that better explains the experiences of others. Even when people are working their projects solo, they're still... working on "branches"... with npm or other packages being their partner also working on "branches". Every step affords that chance where some glitch is happening within the package.json family part of the equation.

I hope that made some kind of sense. It does on my brain's end.. GRIN

Does anyone have time to elaborate on the exact methodology of @wayofthefuture 's observation? Mostly meaning the interaction between what's referenced there, e.g. what files could we look at? A link somewhere that we can use to self-educate ourselves would be great (teach us to fish, yada-yada). If we're exposed to the exact mechanics, maybe someone among us will spot where things need tweaked..

[Butterfly]

Again, still coming in from the naive angle, part of what I was trying to gel in my brain for yesterday's intended comment was how to bring in that maybe clean or npm-clean or something like those would help take a... byte... out of what's going on. Those might not be the right packages to reference, but maybe they'll tickle someone's memory of something else similarly different.

This is one of those online activities where a bunch of us are jumping in (newbie) feet first without walking things through methodically. There are surely steps that some of us are missing that long time experienced players do instinctively and therefore possibly take for granted all other users are doing, too... when all other users actually are not... simply because they were not aware it's a necessary step.

[Butterfly]

Issue #18144 just got bumped. Problems with locking not locking gets a mention.

AND it references Issue #18375 , TOO. You all are possibly on your way to fixing a biggie this weekend. :smile:

A comment in 18144 says:

Thankfully the simple fix (for now) is to move our package-lock.json to npm-shrinkwrap.json... npm seems to obey that more strictly.

Is #18144 possibly talking the shrinkwrap package (which has no current readme explanation)? I've seen that package referenced before but have no other take regarding its usage.

So what would npm-shrinkwrap.json be doing that package-lock.json is potentially overlooking?

PS And cleaning gets a mention. I'm just not sure what gets cleaned. I've seen some users balk at cleaning because that command might wipe out a something that's needed in singular use-by-use cases..

[Butterfly]

Found another issue purely because it was also bumped today:

• Issue #17161

The original post talks about npm changing some line endings which then cause issues. Am attaching it here because it does reference package.json/package-lock.json:

When having a checkout of a package.json + package-lock.json on a Windows machine with git "core.autocrlf=true", then all files will have CRLF line endings. Now, when running "npm install", then npm thinks that the line endings of package.json + package-lock.json should be replaced with pure LF. This is bad, as git now thinks there are changes to the files, while in fact there are none (only line endings):

That won't explain away all cases, but it sounds reasonable for why some package-lock.json files might be forced to change when they seemingly should not have done so.

Yeah, maybe not, but it sure sounds really good. AND maybe this isn't the only personalized value/declaration that is causing similar actions....... too.

[Butterfly]

One more... Especially with that last one in mind, I wonder if doing a diff type comparison of affected users' personalizations would help Developers? Maybe those changes turn out to be all over the board, but then again, maybe certain similar changes keep showing up with respect to this issue....

[wayofthefuture]

I'm just gonna add package-lock.json to .gitignore and forget about the thing. npm 5.3 is straight up broke and npm 5.4.2 is un-upgradable on windows.

[Butterfly]

@wayofthefuture That's interesting about being not upgradeable. You're the first user I've read saying that on here. Do you have any error messages that you can share here for Developers to read?

Maybe there's some kind of tweak you can do. Or maybe it needs Windows to be upgraded somehow. Having worn your very Shoes, it would be nice to eventually hear that something small and easily accessible is all that would be needed to gain success here. :)

[wayofthefuture]

https://github.com/coreybutler/nvm-windows/issues/300 and https://github.com/npm/npm/issues/17781

Those two issues combined are the perfect paradox.

[Butterfly]

I took a peek at those issues. I'm starting to fall face first out of my newbie pay grade, but I did see someone mention MacOS. That's good news/bad news. That means it's not just Windows, but it's also not an answer, either.

About the only last thing that comes to mind is to wonder if it's somehow about mixed permissions. Users are being told they're not allowed to do something on their computers so that implies a potential permissions issue.

And now I see I wasted a LOT of time mulling silly things because I missed an important detail. I'm looking at @kuncevic 's comment:

c:\Program Files\nodejs\node_modules\npm\node_modules

Isn't that one like hardcore admin territory? For everyone who is trying to delete something sitting under that "Program Files" directory, do they have the proper permissions?

One thing I'm not understanding is where that comment says to just remove something if you get a deletion refusal. I'm not grasping how you do that if it doesn't work the first time. :smile: Reading more into their comment, maybe you have to play around with timing of deletion attempts.

What I'm reading into that is that maybe deletion refusals are about some kind of activity "lock" that goes into effect. That's something that occurs with Linux installation commands.

With Linux installations and uninstallations, e.g. while using apt-get, a [directory-path-to]/lock file (by only that "lock" name) appears to somehow come into play. When that happens, some activities become inaccessibly locked down while a command is in operation then they're freed back up again afterward. I don't know if that applies to file deletions in Linux, but maybe a similar concept of lockdown does apply to Windows and MacOS?

If this is about that "Program Files" directory's permissions and not some kind of lockout, are users going through the proper method of attack to work under that directory? In playing with Windows this week for the first time in a long time, I was quickly reminded that you had to track down administrative tools to perform certain tasks. This might not be one of those tasks, but I figured it wouldn't hurt to check it off the list of possible causatives....

[alexkreidler]

See https://github.com/npm/npm/issues/18286 for the addition of a --from-lock-file (or similar) flag.

[joe-lynn]

@Butterfly If you have nothing of value please move along. The paragraphs are irrelevant nonsense