Package-lock.json and things you may not know yet

Introduce

For nodejs developers in particular and web developers in general, it is not uncommon to see a project named package.json . Okay, simple to say, package.json is a file containing information to help you know which modules are needed to operate the project. It is possible to consider modules as the power of nodejs with a huge open source code as well as a strong community so every few minutes there is a new module. Wait, what about package-lock.json? This article will share my little knowledge about the file that I thought about this useless =)). The article I refer to is written in medium with 9.4k claps, you can refer here: Everything You Want To Know About package-lock.json But Were Too Afraid To Ask

In brief

The main sections let everyone review the package-lock.json:

• package-lock.json will automatically be created when you use npm from version ^ 5.xx
• Should keep the package-lock.json file to ensure compatibility between dependencies
• Should COMMIT package-lock.json to the code management system you use (Git, SVN, …)
• Do not delete package-lock.json just to run npm install and generate it again
• From version ^ 5.1.x, package.json has higher authority than package-lock.json (source of truth)

Knowledge should be grounded

Semantic Versioning (semver)

You can temporarily understand that this is a set of rules to regulate versioning for a module. You still report dependencies this way:

You can clearly see that each module is described as XYZ version, or more accurately MAJOR.MINOR.PATCH . You can read more about this section here: https: // semver. org / . In the framework of the article, I just explain the basic so that you can understand what these 3 indicators mean to the modules:

• MAJOR: Change (also known as breaking changes) when older APIs are no longer compatible. For example , call 2.0.0 when api from 1.0.0 version is no longer available.
• MINOR: Change when adding new features, but previous version APIs can still be used in this version. Example : Version 1.1.0 adds some features but the APIs from version 1.0.0 are still preserved
• PATCH: Version changes with bug fixes for previous versions and APIs are still fully compatible with older versions.

Package management

The dev should not be strange for the npm modules manager . Thanks to npm, managing project dependencies is much easier. Imagine that a project of yours can contain hundreds of dependencies, in those dependencies that contain other dependencies => dependencies hell => quite a headache. But thanks to the management of module packages like npm , we will only have to worry about it: declaring dependencies to package.json and npm install

There is one thing to note when installing packages with the symbol ^ , the dependencies manager will automatically install the latest version with MAJOR version . Eg

npm will automatically download version 2.3.0 or upgraded versions of MINOR or PATCH

Share the source code

The source code shared on the github platform (especially javascript projects) you can see there is usually a package.json file to define the necessary dependencies to run the project successfully. The theory is that but there are exceptions, below is one of the possible cases:

In the project, we define a dependencies in package.json file as follows:

As explained above, with the prefix ^ , npm will automatically install the latest version as long as it is in the same MAJOR version . A scenario can occur here: the owner of the redux-thunk package version project is as above, but when you clone and run npm install , the redux-thunk package will be updated with a patch and current. is in 2.3.1 . Of course, your npm clone version will automatically download the latest version. And somehow, unfortunately with this version and this conflicts with the functions that are in use, and the running results of 2 versions 2.3.1 and 2.3.0 will be different then

package-lock

Purpose

The purpose of package-lock.json is to prevent the features described above: Install dependencies from the same package.json but lead to 2 different install versions

Format

Open up package-lock.json so you can see that it looks like something very much like package.json but much longer. Here is a list of express dependencies:

The idea here is to use package-lock.json instead of package.json to install modules by package-lock.json that specify the version, location, integrity integrity code for each module and each dependencies of it => Its settings will always be the same regardless of when you install it.

Discuss

From the above ideas, package-lock.json can be seen to be able to solve common problems but the top searches on Google often ask how to disable it and ask about its effect.

Before npm 5.xx version, package.json is considered a “source of truth” for the project. All that is defined in package.json will be automatically installed. Devs are quite responsive to this model. However, when package-lock.json was introduced, it did not work as expected by many people. The change in package.json is not reflected in package-lock.json . In the following two cases, it is clear why the package-lock.json has made the user a bit disappointed:

Case 1: Package A has 1.0.0 version in package.json and package-lock.json, but in package.json is manually edited to version 1.1.0, if the user still believes package.json is “source of truth”, they will hope that version 1.1.0 will be installed but the truth is that version 1.0.0 is something that can be instaall

Case 2: A module does not exist in package-lock.json, but it exists in package.json. As a user who views package.json as “source of truth”, the module will be installed. However, because the module is not included in package-lock.json, it is not installed and the code fails because the module cannot be found.

Therefore, users do not understand why their dependencies are not installed correctly and so they try to delete package-lock.json and then reinstall or find a way to disable it.

However, in PR # 17508 , Npm maintainers added a change that caused package.json to override the package-lock.json if package.json was updated. Now in both cases, the packages that the user expects to install will be installed correctly.

Conclude

Above are the knowledge I have consulted as well as learning about things that are still commonly used but quite a few people know why they use them. In this article I mainly talk about the npm package manager , but in terms of good ideas it is quite similar to other package managers like yarn , gem , … Hopefully the article can be helpful for you. friend.

Source : ITZone via Viblo