Do I commit the package-lock.json file created by

Question

npm 5 was released today and one of the new features include deterministic installs with the creation of a package-lock.json file.

Is this file supposed to be kept in source control?

I'm assuming it's similar to yarn.lock and composer.lock, both of which are supposed to be kept in source control.

Answer 1

I don't commit this file in my projects. What's the point ?

1. It's generated
2. It's the cause of a SHA1 code integrity err in gitlab with gitlab-ci.yml builds

Though it's true that i never use ^ in my package.json for libs because I had bad experiences with it :)

Regards.

Answer 2

To the people complaining about the noise when doing git diff:

git diff -- . ':(exclude)*package-lock.json'

what I did was use an alias

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json'"

Answer 3

Disable package-lock.json globally

type the following in your terminal:

npm config set package-lock false

this really work for me like magic

Answer 4

Yes, the best practice is to check in

I agree that it will cause a lot of noise or conflict when seeing the diff. But the benefits are:

1. guarantee exact same version of every package. This part is the most important when building in different environments at different times. You may use ^1.2.3 in your package.json, but how can u ensure each time npm install will pick up the same version in your dev machine and in the build server, especially those indirect dependency packages? Well, package-lock.json will ensure that. (With the help of npm ci which installs packages based on lock file)
2. it improves the installation process.
3. it helps with new audit feature npm audit fix (I think the audit feature is from npm version 6).

Answer 5

Yes, package-lock.json is intended to be checked into source control. If you're using npm 5, you may see this 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(5), 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.

Answer 6

Yes, it's intended to be checked in. I want to suggest that it gets its own unique commit. We find that it adds a lot of noise to our diffs.