This course has been updated! We now recommend you take the Introduction to Node.js, v3 course.

Check out a free preview of the full Introduction to Node.js course:
The "npm" Lesson is part of the full, Introduction to Node.js course featured in this preview video. Here's what you'd learn in this lesson:

Scott gives an overview about how to select reputable modules, what dependencies and devDependencies are in a package.json file, how to install a single node module, and most common use cases.

Get Unlimited Access Now

Transcript from the "npm" Lesson

>> Scott Moss: So now we're gonna talk about NPM. Nobody really knows what NPM stands for, I mean you can google it but it's just node package manager. But you ask somebody else and it's like no, i not, it's not node package manager. It's like a troll, it's like something else like, its node package manager and that's what's doing.

[00:00:16] But basically it's a CLI to manage remote modules. It's that thing that I said we needed. It ships with Node. So you all have it. So if you go to your terminal right now and type NPM, or which NPM, you'll see that. You'll get that NPM. If you installed it with NVM, you'll see it's an NVM version.

[00:00:34] If you installed Node the other way, it'll be there, but you'll have it. You can also type NPM version, or not versions. What version? Version. There we go. I have 6.20, which is the latest. NPM is a company. They have nothing to do with Node. But [LAUGH] Node ships with NPM.

[00:00:55] How did that happen? I don't really know. But they're a company in the Bay Area. And they're basically a remote repository of modules, that's it. They're a repository full of modules and a tool to help manage them. That's basically it. It ships with Node. It allows you to publish, download, and update modules.

[00:01:13] So if I have a module that I'm creating and I wanted to export it to world, I could publish it with NPM. If I want to download a module for my app, I can download and install it. If I wanted to update modules and their versions, I could update them.

[00:01:24] That's what NPM's job is. It is not like Git. You might be thinking, why does that sound like Git? Why don't we just put this stuff on GitHub? It's not. You still put this code on GitHub, but the versions and things that you release, and the access to those things, are gonna be on NPM.

[00:01:38] And that's because GitHub has no idea about how a package.json works, which we'll talk about in a little bit, or how the Node module folder works. It doesn't know anything about that, although it could. There's nothing stopping GitHub from doing that. That's just not their job. That's NPM's job, and it hooks into Node specifically, in its environment and its runtime.

[00:01:56] So you still have to host these things on GitHub, but then you also release them to NPM. So the live code, the latest code is always on GitHub, and all the development stuff, but whenever you cut a release for version two, you also push out to NPM. So people can download from NPM versus having to download from GitHub, and it gets more confusing.

[00:02:15] You can also use NPM to download code from GitHub. Yeah, it's kinda confusing. You can point to any repository that you want, whether it's NPM, whether it's yarn, whether it's GitHub is a lot of different things. But NPM is the main one where you publish your modules and how you can search for them and stuff like that.

[00:02:33] So if you go to, you might have seen this logo before. That's the NPM logo. All right, that's what this is so I can search for a package the first if I type in FS. Look at this see somebody made one called fs. And you can see published two years ago.

[00:02:49] Yeah, keywords non, like this. There's no read me. There's nothing on here. It even says this package name is not currently in use was but firmly copy. So this is like bad you would not use this. But if you want to see what a good module look like you might type in something like react.

[00:03:03] And you would see like, okay, is this a really good one? Okay.
>> Scott Moss: Two hours ago. Yeah, that's pretty active. Collaborators. That's a big one. Yeah, it seems pretty legit. How many downloads? 2.8 million in a week. Yeah, I think this is a pretty good package right, how do I install it?

[00:03:23] Just type in NPM i react, we'll talk about that in a little bit, but that the name of the package, React. And then you can go follow onto there GitHub and you can kind of see like, I''m going to look at there GitHub to see if they're legit.

[00:03:35] How many released do they have? That's a lot of comments here. When was it update last? Two hours ago, confirm that. And here's the full ReadMe and documentation. So this is how you have to look at your modules to make sure they're legit. There's literally no other way.

[00:03:48] There's tools that are just now starting to come out that will warn you of a vulnerabilities inside of other modules. Because if one module has a vulnerability and then you are using a module, that uses a module, that uses a module that uses that vulnerable one, a tool will alert you about it.

[00:04:03] Like, this one module way down there that you have never seen, that a dependency of your dependency of your dependency is poison. You should change your stuff, revert to this version and there's tools to help you do that now. It's the only help you got. [LAUGH] Other than like looking.

[00:04:19] It sounds bad and it is that bad but it's not that bad. [LAUGH] It's not a big deal. People just download the modules and they use them. Like it's just do your due diligence. What I'm saying you don't have to spend a week looking at every single module in your node modules folder and like, you don't have to do that.

[00:04:38] If you want to, for sure. But you don't have to do that. Just look for the bad apples. And you know it's bad. There's just some bad stuff on the internet. It just won't look right. Okay, cool so that's NPM. That's how you search for things. And if we get back to.

[00:04:59] Yeah, so you do all that stuff on NPM. And NPM uses what's called a package.json. So if you open up the repo, you might notice a file and a root called package.json. If you haven't seen that it looks like this. Looks something like this, so it's a JSON file, and it's got some stuff like this.

[00:05:22] And there's all these fills on here, and there's way more fills on this, but this is just the scaffolded out stuff. You'll see a name. That name is the name of your module. You didn't package it and bundle it to the internet yet, but the name is by default is going to be the name of the folder when you scaffold this out.

[00:05:37] So this is then the name of this module's Intro to NodeJS. So if I push this up to NPM, and you want us to install this, you would NPM install Intro to NodeJS and this is what you would get if I packaged it correctly. Here is the version of it.

[00:05:51] The main file that we talked about modules being a tree and there is usually an entry file somewhere. This is the entry file to this app. So I am saying hey this is the entry file to this app. So if someone where to require this. If someone said require intro to NodeJS, this is the file they would do.

[00:06:06] And that file has a dependencies and that file has dependencies and go for it and go for it. All this other stuff like licenses, not that important. And then you this thing called dev dependencies and dependencies. These are lists of dependency instructions for your app. If your app has a dependency on these things, now NPM knows what to install when you tell it to.

[00:06:28] So If you and I are working on an application together and you installed a whole bunch of dependencies from NPM, how would I know that you did it? Well, NPM saves them to this file. That way you don't have to check in the modules to Git. Because that would suck if you had to check in every single module that you downloaded to Git.

[00:06:44] It's kinda bad. You really don't want to do that. It's not the practice people use. There's an argument saying that you should do it. But for now, you just don't do that. You don't check in your downloaded modules. You just check in the list of modules that you need to install.

[00:06:56] The machine who is running that code, it's responsible to install those modules, which is what you did when you ran npx jest. When you ran npx jest, it installed all these modules every single time, because I didn't package those modules on git, because I didn't want that to happen.

[00:07:09] I wanted you to freshly install them. Cuz you have to because they might be different versions, they might have some post set up instructions that need to happen on your computer when you install them. And there's just so much to check in a git that's not our code.

[00:07:20] Could you imagine checking all that code in to git when you only made like one line change but you added 30 modules, what the code review would look like? It would be ridiculous. Look at all this code that's not even ours that we have to look at. This is ridiculous.

[00:07:31] If one thing changes, you gotta to rebase or something it's just ridiculous. So you don't just want to manually enter other people's code and your gits. So you just don't check in the remote modules, just instructions to what versions they are, what names they are. And you just install them freshly again.

[00:07:46] So that's what dependencies and dev dependencies are. Yeah, so that's where the package.json is. NPM uses that to determine and save instructions on what dependencies to save and download. And what the name of the package is and what version it is, and so all the meta information for a module that needs to be public.

[00:08:07] So it is stores remote modules in the node modules folder. So again, if you looked in that project you might have seen something like node underscore modules. I didn't make that. NPM made that. Whatever you install a module remotely, like for instance if I type in NPM. Install,

>> Scott Moss: Lodash. What's happening is, I used to NPM command, I used the command called install. Sometimes on the Internet you'll see i for short, which is short of install, so it's the NPM i. And then the name of the package, that's it. Now this is what you might have seen when you were running npx.js.

[00:08:42] It was doing something like this, right? That's because every single time you ran that command, it was installing the modules over and over again, cuz it never saved them to disk. It's just random in memory, just to run this test once. That's why I have to do it every time.

[00:08:55] If you use NPM install, it will save onto disc and you're good. So right now, I'm telling it to install a module called lodash which is a very helpful library if you never used it, super helpful. And it's downloading it. It's going to the internet and these are all the other packages that it depends on.

[00:09:12] And the packages that those things depend on. And the packages that those things depend on. And it's just getting all of it. Just for one, that's how many packages it is. So imagine if your app had I don't know, a big app might have like 50 node modules that you explicitly install each one of those had like 100 node modules.

[00:09:30] You'd have so many node modules. That's why you don't check it into git, it's ridiculous. Yes?
>> Speaker 2: It sounds bad, is this bad?
>> Scott Moss: It does sound bad, it does sound bad. No, it's not bad. [LAUGH] It is bad, but it's not bad. Everybody knows it's a problem.

[00:09:49] So it's bad as in anybody can take advantage of this and destroy everybody, and they have. People in the past have taken advantage of this system and caused chaos in the community. I mean, just Google something called left pad and tell me what you find. It's just been chaos, but those are a few bad apples.

[00:10:08] The good news is, people are fixing this. There are other tools that are working around these problems. And the first thing. NPM is one of them. Actually NPM is doing a lot better. Before this, NPM was really bad, I would never use it. Now I'm actually considering using NPM again.

[00:10:24] I don't use NPM. I use something else and I'm going to talk about what it is. But it is bad if you take advantage of it, but it's not bad. I mean, so is the browser. The browser's bad if you take advantage of it. I mean I could give you a website with an HTTP lock on, HTTPS, It looks nice.

[00:10:41] But really I'm just mining crypto. So like it is but it's not it really depends on somebody takes advantage or not. So yeah, it's not that bad. Just don't be so trusting. Cool. So yeah, it installed it and then if I go look in my Node modules folder.

[00:11:01] I'll see a few things, so node_modules/lodash. Or I'll just do ls node_modules. There's a lot of stuff here. Look at all these modules inside. I didn't install half these modules, more than half. But these are modules of modules, so lodash would be here. So there's the module that I installed, lodash.

[00:11:21] But all this other stuff comes with everything else. Look, there's left pad, that's in there. God, left pad. So lodash got installed. The problem was if I go start looking at package.json though. Okay, so by default, if you just installed something, it won't go into the package.json. Which is a problem because, when someone else pulls down your app and then they go install everything, it won't install the modules that you installed.

[00:11:47] So you have to tell NPM to say, hey, not only do I want to install this package, but I want to save it in the package.json, so people can install it later. So what you would normally do is say, NPM install, and then you would say --save. Save that in the package.json too.

[00:12:06] And that way it gets saved. Mine was already saved, though. So now that's there, it'll put the version in there, it will save it and now when you pull this app down and you run nPM install you'll be good to go. So that's how you install a single module.

[00:12:19] Now, how do you install all of the modules? If you just pull down this repo from scratch, how do you get all of the modules so you don't have to do that npx js stuff anymore? You just type in NPM install. You just do this one time, it will look at the package.json and install everything that is there.

[00:12:33] Then you're good. Looks like NPM's already checking for vulnerabilities, see? They're getting better, they're getting better, this is new, this is new stuff, they didn't do this three months ago. So they're checking for vulnerabilities now, that's awesome. So it's getting better. So yeah, that's how you install everything at package.json, that's how you install one module, that's how you save it.

[00:12:53] And everything goes into the nodes module folder and you don't check that into git. Just do not check the node modules folder into git. Put it in your git ignore, don't do it. And then yet NPM does a whole bunch of other stuff, aliasing, just so many other things.

[00:13:13] But 90% of the stuff you do with NPMs is gonna be NPM install, NPM uninstall, that's about it. If you're publishing packages, which most people don't really publish packages, but if you do then you'll use it to publish packages. But eventually you'll get really good at publishing packages and you don't wanna do that manually.

[00:13:30] So you'll have a bot do it for you in like a CI environment. Or you'll have some automation tool that you built that'll do it for you so you don't have to do it, because that just gets really annoying. Especially when you get into versioning and SemVer and patterns, you don't wanna do all that stuff.

[00:13:43] Change logs, releases, so you have something do that for you. So you don't have to manually go in there and do it, cuz it's really annoying to do that. But yeah, most of the time this is gonna be install and uninstall.