1

I'm reading the NPM docs about package-lock.json and my interpretation is that a committed change to it can never cause issues in the deployed version.

During the roll-out we run npm install which creates (or overwrites) the lock file anyway. In my mind, the lock file is more of a receipt of the state of the concurrent world while installing, rather than a pointer on how the installation should be performed.

However, I haven't been successful convincing my team that it is so. They feel uneasy relying on the statement above (not contradicting it nor arguing against it, just not entirely convinced to the degree that they would bet a testicle on it).

Is it at all possible that package-lock.json might affect the actual installation?

Since I'm new with the company, my track record of 10+ years has limited impact. And I'm myself humbly considering that even though the lock file never caused me any issues before, my experience might be irrelevant if the local environment is configured in a way I'm not familiar with yet. So I'm too cautious to bet my reputation as we're about to make a very important release.

Konrad Viltersten
  • 36,151
  • 76
  • 250
  • 438

1 Answers1

3

In my mind, the lock file is more of a receipt of the state of the concurrent world while installing, rather than a pointer on how the installation should be performed.

Maybe I am interpreting your statement wrong but package-lock is a pointer for future installations in a way. See the general documentaion on lock files (different link than the one you shared), following statement from the above doc might be helpful:

This file describes an exact, and more importantly reproducible node_modules tree. Once it’s present, any future installation will base its work off this file, instead of recalculating dependency versions off package.json.`

A read on following discussion on this topic might be helpful to you too. Thanks!

Mamoon Raja
  • 487
  • 3
  • 8
  • So, would you say that it's a good practice to commit *package.json* and omit *package.lock.json*? Or would you say that committing and checking in both of them is a good practice? – Konrad Viltersten Nov 14 '18 at 17:42
  • 1
    Committing and checking both of them is a good practice, that way all the people working on the project will have the same dependency structure. And if you want to change a module you can update `package.json` and do `npm install` and `package-lock` will be updated, and then you can commit that for everyone else in your team to use. – Mamoon Raja Nov 14 '18 at 18:56