should you ignore package-lock.json code example

Example 1: what is package.lock.json

It could be you, or another person trying to initialize the 
project on the other side of the world by running npm install.

So your original project and the newly initialized project are 
actually different. Even if a patch or minor release should 
not introduce breaking changes, we all know bugs can 
(and so, they will) slide in.

The package-lock.json sets your currently installed version 
of each package in stone and npm will use those exact 
versions when running npm install.

This concept is not new, and other programming language 
package managers (like Composer in PHP) use a similar 
system for years.

The package-lock.json file needs to be committed to your 
Gitrepository, so it can be fetched by other people if 
the project is public or you have collaborators, or if 
you use Git as a source for deployments.

The dependencies versions will be updated in the 
package-lock.json file when you run npm update.

Example 2: gitignore package-lock.json

Yes, package-lock.json is intended to be checked into source control. If you're using npm 5+, you may see this notice on the command line: created a lockfile as package-lock.json. You should commit this file. According to npm help package-lock.json:

package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.

This file is intended to be committed into source repositories, and serves various purposes:

Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.

Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself.

To facilitate greater visibility of tree changes through readable source control diffs.

And optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.

One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package. It shares a format with npm-shrinkwrap.json, which is essentially the same file, but allows publication. This is not recommended unless deploying a CLI tool or otherwise using the publication process for producing production packages.

If both package-lock.json and npm-shrinkwrap.json are present in the root of a package, package-lock.json will be completely ignored.