Introduction to Node.js, v3

Importing & Exporting Modules

Scott Moss

Scott Moss

Superfilter AI
Introduction to Node.js, v3

Check out a free preview of the full Introduction to Node.js, v3 course

The "Importing & Exporting Modules" Lesson is part of the full, Introduction to Node.js, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Scott demonstrates how to import both internal and external modules in Node.js. The differences between using `require` and `import` for including external modules are also explained in this segment.


Transcript from the "Importing & Exporting Modules" Lesson

>> Okay, so that's how you would make your own module and that's how you would import them. Now let's talk about how you import core modules or internal modules that Node ships with. So we talked about Node having globals like console, and literally the word global, process we see is a global.

We didn't have to import that. But Node also has other modules that we're gonna use. So I'm gonna show you how to import them, but we're not gonna use those modules right now. So let's say we wanna use the fs module, which stands for file system from Node.

I can do this. Anybody notice a difference from how I import fs from how I import one of these?
>> Not using a path.
>> Yeah, the path, right? So when I'm importing a file that I made, it needs to be a path to that file, which typically starts with a dot and a slash.

It could be two dots, I could be going up a directory, but it has to start at least with a dot. This is how Node knows that like, you're looking for a file that you made, got you. This doesn't have it, I just put a name here, and that's because this is inside of Node.js.

It ships with this module. So you can just say it, you don't know where the path is. And in fact, on the latest version of Node, we can now be explicit about that and we can do something like, we can do that. This doesn't change the behavior on how it imports.

And it kinda looks weird for people who've been doing Node for a long time. But this is just being explicit that this fs module is the core internal fs module, and not some fs module that you might have installed called fs, which who would ever make that is a jerk.

Because why would they make a module called fs when they know Node has one built in? That's really, really cruel. So this is just being explicit. I want the fs that Node ships with and not some third party thing that might be called fs. It's very explicit, but you don't have to put it, it's optional.

And then the way to import a third party module after you install one, which we're going to in a minute, is literally the same thing. So I can say, in this case, let's say lodash, it'll also be like that. So it's no difference than importing a internal module other than the fact that, again, if you wanted to be explicit, you would do that.

You would say node, whereas you wouldn't do that here. Cuz this is saying, there's some third party model that I installed, and that's it. And you can do this in any file. Any file that you have, you can import and export to wherever you want. So you end up creating this dependency graph of imports and exports.

You might even get to a point where your modules are cyclic. You might have a module that's exporting to another file, that's exporting to another file where the third file imports from the first one. So it's a cyclic dependency. All that stuff is taken care of for you and resolved automatically, but it can get pretty deep.

Any questions on modules? Like I said, if you've ever used React or anything like that, it's pretty much the same thing because it's all based off of JavaScript, ECMAScript, which is built into JavaScript. So nothing too crazy there. Okay, there's no questions on that. We will keep moving.

So let's talk about require versus import. I think it's worth noting because although we are using ES6 imports and things here, this is relatively new. So a lot of code bases that you might go join probably won't be using imports and exports in their Node.js code, unless they're using a processor or they're using something like TypeScript.

If they're using Vanilla JavaScript and Node and the app is already built and stuff, chances are it's probably not using import and export, it's using require and module.exports. So let's talk about those differences because I do think it matters if you're gonna be using this stuff day-to-day. So basically, the equivalents, let me actually bring this stuff back.

So I'm just gonna write the equivalent for all this stuff so you can see it. So the equivalent for importing a module using require would be something like this, right? I would say count equals and then I would use this global function called require and it's the same path.

This is the equivalent. Right, and the same is true for these two. This path doesn't change. That's the only thing that doesn't change is a path, but you just replace import with let const or var and you replace from with equals require. Everything else is pretty much the same.

Now there are some differences with how you export. So now if you wanna export, the equivalent to this would be, well, no one does this anymore, but they would do this. They would say exports.count equals some function. They would do that, but no one does that. [LAUGH] I haven't seen this since, I don't know, a decade.

What people mostly do instead is they'll do something like this, module.exports, which you can think of as the default export, and then it'll look something like that. Those exporting objects with a count property on it, that's the count versus manually exporting each single thing. It'll probably be like a module.exports.

So this is how you export in CommonJS with require. This is how you import with CommonJS and require, and these are their equivalents with ES6. Require also does some other crazy stuff that hopefully you never have to get involved with, but for the most part, this is it.

Cool, we won't be using this because it's getting phased out. That's the whole point. The reason this is even here is because when Node.js came out, there was no ES6 modules. There was no modules, period, in the browser. So they had to come up with their own module system, and CommonJS is it.

There's also other module systems out there, not to be confused by RequireJS, which is not this require. It's just called RequireJS, but it's not this. But that's pretty much dead. Nobody uses that. And if they do, go running, run away from that company. [LAUGH] It's not gonna be fun.

But yeah, this was built before ES6 templates were standardized. So they had it, and then now, they have to make it compatible and stuff. So they're just now getting there and we're using it. But remember, you gotta make sure you have type module enabled to be able to use it, so.

Okay, any other questions on that? And again, like I said, I like to go through and just show examples, but more thoroughly, you can go through the notes and you can see all my thoughts and all the things and stuff like that. But I'm not gonna say how to read this verbatim.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now