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

Check out a free preview of the full Introduction to Node.js course:
The "Sharing Modules" 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 details the checklist to go through to make modules sharing-ready.

Get Unlimited Access Now

Transcript from the "Sharing Modules" Lesson

>> Scott Moss: Sharing modules, so we talked about creating modules, we talked about about pulling down the internet. But how do you share yours to the rest of the world? If you want to, you should. If you could do something or legit, like share it, share it like this, give it away, let people use it.

[00:00:18] And then let them fix it for you if the stuff is really good, then people will fix your stuff if they use it. And then you can ask them for money. [LAUGH] You can put a donate badge on your read me and have them buy you a coffee, like every other hipster that creates open source for a living.

[00:00:34] So it's pretty simple. You just push your code to GitHub, and then you publish it to NPM. That's basically it. So nothing really changed. There's just some things that you have to change before you do it. Basically, you need to add node modules to the gitignore file if you haven't already.

[00:00:48] Like I said that should not go in GitHub, just don't add it. Super early breaking edge tip, this might change in the near future cuz people are working on other things, other alternatives that npm and yarn that do things differently. And yarn and npm are the ones working on it.

[00:01:04] So, this might change in the future, but as of right now do not check any of this stuff into GitHub. Do not check your modules into GitHub, just rely on package.json and you are good. To declare remote modules at devDependencies, if you only need them to develop jest If only you need them to develop with, so something like jest.

[00:01:25] So basically what that means is, if we're gonna look at our tag as JSON, a devDependency is something like jest. We don't need jest for our code to run, we just use jest to help us develop. That was a testing thing that we used. But our app doesn't need jest to run.

[00:01:40] So we make that a devDependency. And the reason why we do that is when someone installs this module, NPM is gonna look at deDependencies inside of this file and install those, and we don't want it installing Jest, cuz we don't need Jest, so why even install it? Jest was only for us to test things.

[00:01:55] So things that you needed for development purposes, you would add to the devDependencies. And the way you would do that is when you install npm install whatever the name of the package. When you --save, you do --save-dev instead. So if you just save dev it'll install it to the devDependency.

[00:02:14] The short cut is -D with a capital D. That's also a shortcut. So that means like it's just a development dependency. I actually don't need my users to download this for this to work. I just use it to develop on. It's a tool that I use. It's a testing framework.

[00:02:27] It's' whatever you use to develop with. That's why it's called a dev dependency. A testing framework is a really good one. Or anything that involves tests. Mostly test stuff you would do that. The other things you would put here would also be for instance, if you were creating a React package or something like that, say you were creating a React component.

[00:02:52] And you wanted to bundle it up and send it to someone, you wouldn't want to bundle React with your React package, because the person that's gonna install it, it's gonna have React. So now, there's two versions of React. You don't want that, so you're just gonna rely on their version of React.

[00:03:05] So in your code, you would just require React as if it existed, because it does locally on your machine because you installed it. But you need to make it a devDependency so it doesn't get installed again on their machine. And then they would have to resolve the different versions of React.

[00:03:20] If your module's relying on this version but they're relying on this version there will be a conflict. So you need to like okay, here's all the stuff that they're going to have to install. Here's the stuff that I know, I need to install. There's also a need for development.

[00:03:31] You got to think about that the easy way to think about it is most of the time just make everything a devDependency almost all the time. If you're like if you're about to publish a module for someone to use this make it a devDependencies. If you're using some other module most of the time.

[00:03:46] There's some small things that you can just say, yeah, I'm just gonna bundle this. But most of the time, it's a bigger library, like Lodash, React, something like that, some framework. Make it depth dependency because they're gonna use it on their end, and it's not your concern to bundle it.

[00:03:58] And you don't want to do that. You'll have conflicts. So that's mostly it for that. Although, again, NPM does try to fix this. They try to resolve different versions cuz right now NPM, they store everything flat. So they'll try to like, you got two versions of React. We'll try to resolve the right one and store it flat.

[00:04:15] I wouldn't rely on NPM to do that. So just don't do it. People will do it and they always are not gonna do it, so it's gonna happen.
>> Scott Moss: Think about if this is private or public. Can the rest of the world see this? Or is it just something for you and your company?

[00:04:31] NPM allows you to publish private modules and public modules, just like you have private repos and public repos in GitHub, same thing with NPM. You can say, I wanna put it on NPM, but it needs to be private. So that way they have to add afile to the repos as talking in it and that's all capacity use for every request so it can be private, so use private modules for everything, yes?

>> Speaker 2: So you know we've written the module we don't wanna blow the code bases to the people who install it so we just put Lodash and devDependencies. But what if everyone follows that same rule and now, no one has put Lodash in the actual dependencies.
>> Scott Moss: No but they have to because at the end of the day, so these are for libraries.

[00:05:11] For libraries, you will just be putting them in devDependencies eventually you're gonna make an app. And an app is never gonna be installed into another app, right. An app is just an app. You're not gonna like Wrap an app up into a module and put it on NPM, it's an app.

[00:05:24] It doesn't go. It gets deployed to Heroku. It gets deployed to some CDN. So that's when you don't need devDependencies, so you will have to install Lodash at that point. So that's where it matters. Because eventually, somebody's gonna use an app. And if they use an app, you have to install everything.

[00:05:37] So yeah, that's what happens.