- Put it in GIT
- Commit it every-time it changes
- Never delete 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.
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.
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.
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