dwyl / dwyl/learn-node-js-by-example

package-lock.json ? Necessary or Noise?

Open
#36 0 comments 0 reactions 0 assignees View on GitHub
question
Dominant language
HTML
Stars
48
Forks
11
PR merge metrics
No merged PRs in 30d

Description

The purpose of the `package-lock.json` file is to "lock" the list of dependencies for a Node.js project beyond simply _listing_ the dependencies in a `package.json` file.

Here is an example of a `package-lock.json` being added to a project:
![image](https://user-images.githubusercontent.com/194400/56280957-4d3ab500-6103-11e9-92e8-fcfddfa8f4ab.png)

GitHub (_obviously_) does not _show_ the full 10k lines of JSON because it's a _massive_ file.

When we attempt to expand on this list we see an _ocean_ of dependencies and versions:
![image](https://user-images.githubusercontent.com/194400/56281059-8ffc8d00-6103-11e9-82d9-7d0f54f0adeb.png)
What does this information tell us?
It tells us the _precise_ versions of all the dependencies that are being used in the project at this point in its' history. That is a _good_ thing right...?
Well, on the _surface_, yes, it _is_ a good thing to have a _precise_ control of the dependencies, that's incontestable.

The question is: will having a `package-lock.json` file _save_ you from a "bad" dependency update? or is the file simply creating _clutter_ and _noise_ in your project?

As much as I _hate_ the _noise_ of a `package-lock.json` file having _hundreds_ of lines updated each time a dependency is updated, on balance I feel it's a _necessary_ evil for _some_ projects that don't have _complete_ end-to-end testing. When an app does not have good testing and continuous integration, `package-lock.json` can be a good "fallback".

There is no _substitute_ for having _full_ test coverage when upgrading versions of a dependency.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.