Learn more about npm! In the previous chapter, we have learned Node and package manager, and even installed Node and npm and became familiar with Node version manager (nvm). The next part of this npm beginner's guide will introduce what you might care most about: Installing the npm package .
We can install our first package using the npm install command (or abbreviated as npm i ) and the package name to add to the project. For example, Sass' Node package is simply called "sass", which means we can add it to the project like this (make sure you first are in a new folder created for this small project):
npm install sass
That's it! After entering this command, npm will start working immediately:
What happens behind the scenes is that npm tries to look for a package named sass in the npm package registry. If the package is found (it does) npm installs it into the automatically generated node_modules folder in the project (more on it later) (located in the project root folder), including everything that the package needs to run. (That's why you see npm adding 16 packages and reviewing a total of 17 npm packages instead of just the Sass package itself - it also has dependencies!)
After running the installation command, you may notice that you don't see anything called "sass" in the project folder, which is different from what you might expect. Strangely, however, we do see three new projects in the project folder: two JSON files named package.json and package-lock.json , and a brand new node_modules folder.
What are these? We require npm to install Sass, not all of this stuff. This is not part of Sass… right? Yes, this is correct, but there is a good explanation for why these new projects are generated in the project folder. Let's see what just happened.
When installing (or uninstalling or updating) a package, npm does most or even all of the following four things:
package.json file in the project as needed;package-lock.json file (called "lock file") with all technical details;node_modules folder); andLet's introduce it one by one.
These two JSON files work together to ensure accurate logging of all dependencies in the project (and all their dependencies, all their dependencies, and so on). The difference between the two is a bit technical, but simply put: the lock file is an in-depth, precise snapshot of the project's dependency tree, while package.json is a high-level overview that can contain other things. The main package you installed may be listed in package.json , but package-lock.json is where you track the entire dependency tree.
The lock file should not be updated manually either; it can only be updated by npm. Therefore, be sure to avoid confusing lock files with package.json files.
When you share or collaborate with others on a project, npm knows the source of the project and what is installed in the project through these two files. Thanks to this information, it can accurately copy the environment on any other person's machine. Both files should be submitted to your Git repository and serve as a dependency blueprint for your project. This way, when another developer on your team clons the repository and runs the npm install command, npm knows exactly which packages to install, keeping you and your colleagues in sync.
If you open package.json you won't see much, but it's worth a look and see what's going on:
{
"dependencies": {
"sass": "^1.43.4"
}
} You may not see the exact version number (because the package has been updated since this article was written), but you should see sass inside the JSON dependencies object. The number itself (in this case 1.43.4) indicates a specific version of Sass that has been installed.
As a short but important side note: the off-character (^) at the beginning of the version number allows npm to install minor updates to the package. In other words, it tells npm that the installed Sass package must be at least version 1.43.4, but can be any higher version 1.xx as long as it is still below 2.0.0. npm usually chooses the latest stable version when installing the package, but this is added to allow non-destructive updates. This part is called "semantic versioning", which is itself a blog post topic, but is not unique to npm.
Anyway, these are these two JSON files. Next let's discuss the node_modules folder.
node_modules is where all the actual package code is located ; this is where the Node packages that have been installed and everything that makes them run. If you now open the folder while following the instructions, you will find a sass folder, but there will be several other folders as well.
The reason for other folders is that when the package is installed, it may require other packages to function properly (Sass obviously requires). Therefore, npm automatically completes the work of finding and installing all these dependencies. As you might guess, these dependencies may also have other dependencies of their own, so the process will be repeated and so on until we finish crawling the dependency tree to its furthest branch and everything we need is installed (or until we get some sort of error, though hopefully not).
Therefore, projects usually have hundreds or even more node_modules subfolders that accumulate rapidly in terms of disk space. node_modules usually become very large.
If you want to know how to submit a large folder like node_modules to a project's repository, note that unlike JSON files, node_modules folder should not be committed to Git , and should not even be shared. In fact, the example of almost every .gitignore file (which files that tell Git which ones should be skipped when tracing a file) contains node_modules to ensure that Git never touches or tracks it.
So, how do other people on your team get these packages? They run npm install (or abbreviated as npm i ) from the command line to download dependencies directly from the source. This way, there is no need to commit large amounts of data to or extract from the original repository.
This huge network of dependencies and its distant relative dependencies can cause this situation: Some kind of utility library that provides useful services may be adopted by many other packages, which in turn will be used by many other packages until the original code is finally quietly installed on a large portion of the site and application.
You may actually let a lot of other things in during the installation of a package, which may sound weird (if not very scary). It feels like inviting a new friend to your family party and the friend shows up with 20 uninvited guests. But this doesn't seem so strange or terrifying for the following reasons:
Of course, in any environment where arbitrary code can be installed and executed, it is a good idea to be cautious. Please don't get me wrong. I would lie if I said the bad guys never successfully exploited this system. But know that there are many processes that can prevent things from going wrong. If in doubt, stick to the most popular bags so you're OK.
Also note that npm will run an automatic security audit for you, which takes us to the last point in this section.
When we installed sass before, we saw the following message when the terminal was finished:
<code>found 0 vulnerabilities</code>
However, you may see some warnings – like my old project below. I decided to start it and run npm install ( npm i ) after it was idle for at least a few years. Let's see how it performs:
npm audit indicates packages with known vulnerabilities , and the audit will run automatically when you install the package. If you see news like this, don't worry too much ; many vulnerabilities, especially those in the "medium" category, bring very low actual risks and may only be related to very specific situations. (For example, it may be possible that only one method in a package will make it vulnerable when used in a specific way.)
Nevertheless, it is better to solve the problem we can solve, which is what npm audit fix command does. Adding fix at the end will tell npm to continue and update a new minor version of any package with some known vulnerability. The "Minor Version" section is important; the minor version should not contain major changes, but should only include updates. This means that updates should be run safely in this way without risk of breaking the project.
If raising the package's version number by a minor version number does not work, you can add the --force flag to the original command:
npm audit fix --force
However, this is a dangerous operation. Granting npm "Use Force" permission means it can now install major version updates to resolve vulnerabilities - meaning it may make significant changes or introduce incompatibility. I do not recommend this unless there are critical vulnerabilities that npm audit fix cannot solve and you are willing and able to spend a lot of time troubleshooting afterwards (if necessary).
A final note on this topic: Sometimes you can fix some unexpected problems in your npm project by removing node_modules and rerunning npm install . This is the "repeated switch" method of npm, and I have done it many times myself.
Now that we have thoroughly explored the rabbit hole that works behind npm, let's go back to the actual operation , okay?
← Chapter 6 Chapter 8 →
The above is the detailed content of How to Install npm Packages. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
