This course has been updated! We now recommend you take the Complete Intro to Real-Time course.

Check out a free preview of the full Real-Time Web with Node.js course:
The "Publishing NPM Modules" Lesson is part of the full, Real-Time Web with Node.js course featured in this preview video. Here's what you'd learn in this lesson:

Now that the module has a package.json file, it can be published to the NPM server for distribution. Once the module has been converted into an NPM module, the require() include can simply reference the module name.

Get Unlimited Access Now

Transcript from the "Publishing NPM Modules" Lesson

>> [MUSIC]

>> Kyle Simpson: Now we've created a package JSON. We have our actual module file, so the only last step that we would need unless we were trying to commit to a GitHub repo. Other than that we would just do an npm publish and we would use the name of our module.

[00:00:18] So in this case the name was helloworld. Now I'm not going to press enter because if I do it's going to come back an error at me that there's already a hello world module in the repo. But had I picked a non-conflicting name and I hit enter. You'd see a bunch of output here and it would eventually come back and say success you've published your first NPM module.

[00:00:38] And that's all it takes. So now if there was a Hello World module all, anybody would have to do yourself included to bring it down is to say npm install Hello World.
>> Kyle Simpson: And it's going to pull it off the repository or update if you've already got it and get you the latest version of it.

[00:00:58] And then the last piece of this puzzle is that if we wanted to use that inside of our code remember our program, instead of having to reference it by a manual filename. Now we would be able to reference it by just its package name just like we do with other modules.

>> Kyle Simpson: Cuz it would have been installed in the proper install location In the proper directory location so we could just reference it by name. And that's really all there is to creating NPM modules. Anything that you could think of that's even remotely something that might be reusable by other people or by other libraries.

[00:01:36] You should think about open sourcing it and publishing it on NPM cuz it's really quite simple. Yeah.
>> Speaker 2: So will it cool down the dependencies too?
>> Kyle Simpson: Yes. If we had listed dependencies here like minimist and somebody says npm install hello world. Inside of my, that's an important point, I appreciate you asking that question.

[00:01:57] So inside, let's go into node_modules/minimist, okay? Well first of all, let me go into node_modules. I've installed minimist and these are the only ones that I've actually installed. I've installed my asyncquence, asynquence-contrib, minimist, node-static, which we'll get to and Those are the only ones I've installed as node modules for my current project, my exercises project but let's go in to minimist for just a minute.

[00:02:25] Minimist is its own module directory has a bunch of stuff in it like it's license file and things like that. Now let's look at their package.json.
>> Kyle Simpson: You see noted right here, kind of the fourth line down from the top, right here you see a list of what's called devDependencies.

[00:02:46] The devDependencies means these are dependencies that are required only if somebody is gonna do a development task like, say, run your test suite, or build files, or something like that. So they don't get installed right away. But had those been listed as dependencies then inside of this minimist directory we would see another note modules directory which has the dependencies for minimist.

[00:03:09] If I come back out I'll get to that question just a second. Well, if I come back out here and I go into, which I know has dependencies, and we look here you see that down there at the bottom that does in fact have Its own node modules directory.

[00:03:24] That's because their packaged .JSON,
>> Kyle Simpson: Listed some dependencies. You can see right there they listed right there in the middle of the screen. They listed the, the policyfile, base64id, and redis okay. So they're requiring those for them to run, they pull those things in automatically just whenever you do an N.P.N. install.

[00:03:52] What was the question?
>> Speaker 2: David W is wondering if you downloaded a ton of modules can it pollute the node.JS instance? I'm not sure what he means by node.JS instance. I'm gonna ask him for clarification.
>> Kyle Simpson: My guess is you're asking if there's a whole bunch of dependencies or all of those things getting loaded up in memory and is that.

>> Speaker 2: Okay, yeah [CROSSTALK] would you wanna keep them to a minimum in a production app.
>> Kyle Simpson: So I'm going to put on the hat of just speaking purely out of opinion here. I think there is far too much bloat in the current NPM module world with everybody depending on 5,000 other modules.

[00:04:35] It's kind of the hit I call it the hidden module tax because you find this neat little module listed somewhere on NPM and you're like it's this cool thing. It does exactly what I want. You do NPM install. And it downloads 5000 dependencies that you didn't know it was gonna download.

[00:04:52] And then every one of those dependencies had dependencies that they downloaded and so forth. And I think we've gotten a little bit crazy with our dependencies. So I would agree with the spirit of the question that says you should pay a little bit of attention to what you're installing because yeah it definitely is gonna blow your file system.

[00:05:09] It's gonna blow out your bandwidth tasks. A lot of people use NPM as a production deploy mechanism. So they deploy their app and they ask for all their modules to be pulled down off of an NPM repository. Well you're paying for that bandwidth in your production environment and if you're spending up new VM's every couple of minutes in the AWS and you're pulling down 100's of megabytes worth the dependencies.

[00:05:31] You're paying for all that bandwidth. So there is a tax there and we should be aware of that whenever we use other people's modules.
>> Speaker 2: James L was also wondering kind of in a similar grain, will dependency be installed twice if it's required by two different modules you're using?

>> Kyle Simpson: Yes because you'll note that the dependencies were installed inside of the directory. So socket IO's dependencies didn't get installed in my directory they got installed inside of socket IO subdirectory. So yes there will be multiple copies however NPM does a really good job of making sure that there's a cache so it's not read downloading it multiple times.

[00:06:07] Theoretically I think there's supposed to be a way for it to, you can link it. So you could install it once and globally and then link it into your local locations, but there's ways to manage it but yes. Each module gets its own copy of its own dependencies.

[00:06:22] Yeah.
>> Speaker 2: If there isn't an upgrade to the package [INAUDIBLE].
>> Kyle Simpson: There's no daemon that's running that's automatically updating your stuff but every time you run npm install on your package name it will get the latest version or if you do npm update it'll get the latest version of all your packages.

[00:06:43] So as a regular maintenance process, you want to run npm update to get the latest version of everything that you're depending upon
>> Speaker 2: How hard is it to set up your npm repository either for internal company packages or just for the production situation where you might have on your own local NPM cache [INAUDIBLE].

[00:07:01] How hard is it to set up something like that?
>> Kyle Simpson: Yeah that's a fantastic question. I have never done it but that is actually a suggested thing. NPM has a public repository where everybody in the open source community can share but NPM itself is a protocol for private repositories.

[00:07:19] So as I understand it you should be able to get their code deploy it on a server and it should just work. I've never actually done it myself though. Yeah.
>> Speaker 2: Greg M is asking for clarification on what the terms of the dev dependencies will be installed.
>> Kyle Simpson: Yes, so it's only if you do something, so the dev dependencies will not be automatically installed at all if you're inside of a module directory.

[00:07:45] Let's say I go inside of node_modules/minimist. Remember that minimist had some dev dependencies listed? If we looked at their package .JSON, remember they had some dev dependencies listed which were tape and tap, I don't know what those are, but those are some devDependencies, okay? So inside of the minister rectory if I do npm install without anything.

[00:08:12] It's gonna automatically install any of my developer dependencies. So you'll note that it will go and get tape and tap, and any of their dependencies, and runs through the whole long list of stuff. So now, I have a node modules directory where I did not have one before.

[00:08:27] I have a node modules directory here that has tape in tap. Okay and of course if we went into tape or tap we'd find that they have their own the dependencies and so forth. The reason I ran in NPM install is that I might want to do something like test I might wanna run their test suite locally.

[00:08:44] So, I did npm test and I ran their test suite. What you list in your dev dependencies are things that you want people to only, you only want them to download if they intend to do some sort of developer tasks, like run your test suite, or build your files, or something like that.

>> Kyle Simpson: There's another way of annotating dependencies, it's called an optional dependency. You could put optional dependencies in there if you have a dependency that is not required but is preferred. For instance if you have a minifier that you prefer to be able to use but your code is able to ignore it if there is no minifier, then you might list one of the minifiers.

[00:09:22] Like five.js, you might list that is an optional dependency and it'll only be installed if the person wants to install it.
>> Kyle Simpson: Great questions anymore about how we are managing things with these packages. Okay. I don't need that polluting my stuff, so I'm gonna go ahead and delete their dev dependencies, cuz I don't care about those.