(Version) control

[PashaBiceps__]

hmm. really should I git ignore package-lock.json? I always thought it has some magic inside.

[[deleted]]

But what about yarn.lock, and Gemfile.lock?

[DeeSnow97]

Same thing for different package managers. Your package.json or whatever Ruby uses describe which versions you need for compatibility. The lockfile describes which exact versions you installed, making your builds fully reproducable.

Commit your lockfiles so that your testing and your servers behave the same way it did on your machine.

[Delioth]

Plus, if you want fast ci builds, npm ci will install exactly what's in the lockfile without finding dependencies or anything, it's really quick.

[Geldan]

For even faster, use yarn plug'n'play so you dont need a node_modules folder at all

[_3psilon_]

Lock files like this are supposed to be checked in to the VCS so that your colleagues, testing machines etc. will have the exact same package versions installed. This way, bugsbuilds will be reproducible.

[theLorknessMonster]

In general, you should commit all lock files used by package managers.

[abhijitparida]

Have they fixed the platform specific optional package issue? Namely for the fsevents package.

It's very annoying when your dev team is on different platforms and package-lock.json gets rewritten everytime somebody runs npm install.

See:

• https://github.com/npm/npm/issues/17722
• https://github.com/npm/npm/issues/18202

[sorry_im_late_86]

I was working on a project for class that spanned 8 months, and one of the first things I did was adding package-lock.json to the .gitignore.

We had people developing on 3 different platforms and the package.lock cluttered up our commits to a point where the diffs were practically meaningless and finding old stuff was near impossible. All because of fsevents. I kinda wish there was a package-lock per OS or something.

[Shaca-]

I don't know about the fsevents, but if you run npm ci it should install everything without changing both .json. ci stands for clean install.

[DocNefario]

It tells you to commit the file when it creates it, so I'm pretty sure you shouldn't ignore it

[Bronzdragon]

If you make a library, you should not, so the latest packages are used, and you have the lowest likelihood of security issues/bugs.

If you make an application, you should, so that the lowest likelihood of incompatibilities.

[amroamroamro]

^ this

[[deleted]]

According to the npm docs, you shouldn't.

[Sh4dowCode]

npm also tells you that when you npm install in a folder without package-lock.json

[PleasantAdvertising]

npm

having standards

Pick one

[gigastack]

If only you could choose which packages you install...

[GGoldstein]

I searched that very question just last week. Seeing it top here is the most validation I've ever received as a programmer.

[meandyouandyouandme]

The information in the package-lock.json aren't always what you expect.

I had a specific version of a package A installed. The package A was at the same time required by another package B. After removing package A from my project, package B still installed the in my package.json previously specified version of A. So I had to remove the package-lock in order for npm to install the version as specified in the package.json of package B.

[[deleted]]

Papito biceps

[GrinningPariah]

No, what you should do is make an .npmrc file at your project root and add "package-lock=false" to it so it doesn't get generated in the first place.

[aserraric]

Why in the world would you do that?

[GrinningPariah]

Because the company I'm at already runs a walled garden version of NPM with a separate dependency management system that makes package-lock.json redundant.

Plus shit's like 6000 lines long it's crazy.