4

I have a deployment process where I check code into a git repository, and via web hooks a deployment script is run on the production server. On that server, I connect to git using ssh and a .pem key, pull from git, npm install, build webpack and restart the service process.

I never intend to commit anything from the prod servers - they should be able to deploy automatically. However, this does not work, because the package-lock.json file is frequently updated when I run npm install, and so the next time I deploy, the git pull step fails, saying that I conflict with existing package-lock.json file because it has changes that are not committed.

My current solution is to .gitignore the package-lock.json file. But that defeats its purpose, to provide builds that are identical to the ones on my dev machine.

What would be the right way to handle package-lock.json?

Joachim Bøggild
  • 614
  • 5
  • 15

1 Answers1

1

There's a helpful StackOverflow Question/Answer about why your package.lock is changing. The closest most useful answer seems to reference an NPM bug that's seeing much activity here in October 2017.

But currently, package.json overrides package-lock.json, meaning if you use ~2.1 and there's a 2.2 version of that package, your production deploy will get upgraded.

Assuming you're not from the future, there's two different ideas here:

  1. Use only non-prefixed, specific version numbers (2.1 vs ~2.0) in your package.json. (This is not great)
  2. npm install --no-save... which doesn't solve the underlaying issue of lock files getting ignored, but I think will keep the package-lock.json from being updated.
RyanWilcox
  • 13,890
  • 1
  • 36
  • 60
  • 1
    Could you say a bit about why #1 is "not great"? Especially when reproducibility of builds is very important, and package-lock doesn't lock. – eflat Jan 04 '18 at 19:28