Codementor Events

Get Rid of that NPM package-lock.json

Published Dec 01, 2017Last updated Feb 17, 2019
Get Rid of that NPM package-lock.json

When Node.js v8 was released, it came with the latest version of npm at the time.

As someone who loves having the latest features, I upgraded my version of Node to the current version, which in turn updated npm. After using npm v5 on one of my personal projects, I noticed the package-lock.json file that was newly introduced.

At first, I had no issues with the file until I worked with a team on a project. We quickly realized that it was causing unnecessary problems after we committed the file to version control.

It was a frustrating moment — we had to delete the file and add it to .gitignore. I want to take some time to show how to stop npm from creating the package-lock.json file.

What is package-lock.json?

Quoting from npm:
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.

If you don't like having the package-lock.json file around, then continue reading. Otherwise, you can stop reading now.

Disable package-lock.json locally

You can tell npm not to create a package-lock.json file for your current project. To do this, you need to create a .npmrc file at the root of the project and add the line package-lock=false to it.

Windows users may use:

echo package-lock=false>.npmrc
echo package-lock.json>.gitignore

Unix/Linux users may use:

echo 'package-lock=false' >> .npmrc
echo 'package-lock.json' >> .gitignore

Disable package-lock.json globally

You could also decide to completely disable package-lock.json, thereby preventing it from been created. To do this, you would need configure it globally by typing the following in your terminal:

npm config set package-lock false

I tend to prefer disabling it globally, as I might not remember doing it for all of my projects. You choose the method that works for you and stick to it.

On another note: I love having this file in my projects for one specific reason that is version differences and I will explain that in a bit.
Imagine a situation where a specific version of a package was pulled from NPM and fails when you try installing same. This failing package is not a direct dependency of your project otherwise you could just update it. It is a dependency of another package your project is using. How do you find this package?
The short answer is: package-lock.json.

That brings us to the end of this article, I hope you enjoyed it and learned something new. Please like the article if it helped you or if you learned something new.
Finally, I hope you do not just conclude to exclude this "important" file without weighing in on its use.

I'm on Twitter!

Discover and read more posts from Kennedy
get started
post comments11Replies
Peter Shaker
5 years ago

This file is intended to be committed into source repositories, and serves various purposes…
https://github.com/npm/npm/blob/v5.0.0/doc/files/package-lock.json.md

Jack Murphy
6 years ago

I highly suggest:

$ echo -e "\n package-lock=false" >> .npmrc && \
echo -e "\n package-lock.json" >> .gitignore

This will leave any existing entries in both .npmrc and .gitignore intact. It will also ensure the entry is on a newline.

The code in the article will overwrite the existing files.

Chris Weed
7 years ago

package-lock.json is hell on earth. I’ve run into 1000s more issues having it in a project than without. We selectively “lock” packages by removing the ‘carrot of trust’ (^) from our dependency versions in the actual package.json file. When it’s time to upgrade we simply upgrade them selectively and make sure everything works…

Ben Sorohan
7 years ago

You should know this will work for your immediate dependencies, but it won’t lock your transient dependencies (the dependencies of your dependencies). So you’re still susceptible to upstream changes breaking your project.

Show more replies