DEV Community

adam klein
adam klein

Posted on

package-lock.json - in GIT or not?


  1. Put it in GIT
  2. Commit it every-time it changes
  3. Never delete it

What is version locking and why we need it?

You write your software, commit it, push it, test it and if everything works well - deploy it to production.

But how do you know that what you tested locally is the same code that is tested on the CI, and is the same code that is being deployed to production?

Your code is inside GIT (or some other version control). If you pull the repository at the exact same commit, you will have the same code.

But your application does not consist only of your own code. It uses external packages as well. One solution for this problem is to commit the node_modules folder to GIT, which includes all of the code your application uses. This creates a problem by itself because then every npm install will create thousands and more changes, and will make it impossible to maintain your repository.

BUT, you don't really need the entire code of the packages you are using, only their versions. Every time you pull the same version from NPM repository you will get the same code.

So, a lock file keeps the version of all our dependencies, and whenever someone runs npm install, they will get the exact same version of your application, including external dependencies.

Why not just keep exact versions in package.json?

Your package.json only points to the versions of your direct dependencies. If they have dependencies too (and they do), these versions won't be locked.

Why not delete package-lock.json?

Think about it, if you delete package-lock and re-install, you are forcing the latest versions of all packages in the dependency tree. Meaning, you are changing the behavior of (potentially) the entire application.

What are you really trying to do? If you have some weird npm-related problem, simply remove node_modules and run npm install again. Removing package-lock.json is never the solution.

Why commit package-lock.json?

If you don't commit it, then the version of the application everyone else will get is different than what you are running locally. This means that things might work for you, but break on the CI/production/other local machines

Hope it helps to understand. And if you are still not certain about the explanation, just follow the 3 rules in the tl;dr section blindly. That's better than nothing

Discussion (0)