By Kostas Bariotis
Translation: Crazy geek
Original text: blog.logrocket.com/why-you-sho…
Reproduced without permission
In this article, we’ll look at why package-Lock. json is important and how it can be used with the NPM CLI.
history
NPM V5 introduced package-Lock. json as a mechanism for capturing the exact dependency tree installed at any given moment.
This helps to collaborate in different environments, where you want everyone to get the same dependency tree for a particular version of the project.
Package. json uses semantic versioning to define the required dependencies and their respective versions. But semantic versioning can be tricky.
Consider a dependency expressed as “Express “: “^4.16.4”.
The publishers of this module (not using package-lock.json) will install Express at version 4.16.4 because they have installed the latest version.
If Express releases a new version when I download the module and try to install the dependencies, I can download the latest version.
This information can be accurately told by careT symbols.
The problem above is that if the 4.17.x version has an error, my local Settings will fail, but the publisher’s version will continue to work fine on the older version.
The same thing can happen in a production environment, and you don’t know why it failed.
Before NPM V5, you need to use ShrinkWrap. It is different from package-lock.json because it can be published to the NPM registry with modules, whereas package-lock.json is not allowed.
If all members can use NPM+5, it is best to use package-lock.json for unpublished projects.
However, if you are developing a module and intend to release it, you need to consider whether you want the client to install the exact dependency tree you specify, or whether you want to be flexible. Here is a more detailed version of this topic.
Therefore, package-lock.json will describe the exact dependency tree of the current installation. This format is described in the NPM documentation.
By committing it to your VCS (which you absolutely should), you can return to the history and copy the exact dependency tree.
Be sure to always commit package-lock.json to your VCS to track the exact dependency tree at any given time.
It will ensure that all clients that download your project and try to install dependencies get exactly the same dependency tree. This also ensures that you can check out previous commits and copy the dependency state of each commit.
package.jsonwithpackage-lock.json
Make sure you don’t change package-lock.json directly. This will be handled automatically by NPM. It reflects changes to package.json to package-lock.json and keeps it up to date.
But this only happens when changes are made using NPM’s CLI. If you change package.json manually, don’t expect package-lock.json to update. Always use CLI commands, such as install, uninstall, and so on.
How to use NPM CLI
When you first use NPM in a new project, it automatically generates package-lock.json.
Then, you can use NPM normally.
NPM install (using a specific module as a parameter)
You can use Install with the name of the module to install, which changes package.json and package-lock.json as the dependency tree changes.
Consider the following example:
npm install express body-parser cors
Copy the codeNPM install (no parameters)
Install will attempt to install all dependencies related to package-lock.json.
The key here is that you can change package-lock.json if the install registration has expired.
If someone manually changes package.json (for example, they removed a package because it was just a row removed), then the next time someone runs NPM Install, it will change package-lock.json to reflect the previous package deletion.
This can be tricky. Imagine pulling the latest version of a project, only to find a lot of meaningless changes in the tree when you run NPM Install to get the latest information.
The changes in your tree are likely to be meaningless to the person reviewing your code changes.
npm uninstall
Similar to install, but with the name of the module to be removed as an argument. This will change both package.json and package-lock.json.
npm update
Update will read package.json to find all dependencies that can be updated. It then constructs a new dependency tree and updates package-lock.json.
Remember semantic versioning? Suppose we have a dependency in package.json with a status of ^1.4.5.
The character ^ tells NPM to check for newer versions in the 1.x. x range and install if so. Similarly, the ~ character will only appear on hotfixes or 1.4.x.
You can also omit the special characters and keep the fixed version, which makes package-lock.json less helpful (but not useless).
npm ci
Ci will install all dependencies related to package-lock.json, similar to install. The main difference here is that package-lock.json is not changed in any case.
It is intended to be used in environments such as automatic installation when building a server.
conclusion
Keep the following key points in mind when using package-lock.json:
Do not use NPM install to get dependencies without arguments, so use NPM CI instead. You can use NPM Install to install specific dependencies.
NPM CI can be used everywhere only when a local dependency tree is required, even in a local development environment.
Do a repetitive task for updating your dependencies, such as once a month. (Alternatively, you can use a dependabot or something, but make sure you have good test coverage.)
This way, you can ensure that your dependencies are up to date and avoid technical debt.
More reference
npm install和npm ciThe difference between:Stackoverflow.com/questions/5…- NPM CLI source code: github.com/npm/cli/blo…
- The semantic versioning: blog.npmjs.org/post/162134…
Welcome to pay attention to the front end public number: front end pioneer, free front-end engineering utility kit.
