Introduction to Node.js, v3

Internal & 3rd-Party 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 "Internal & 3rd-Party 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 discusses built-in modules that are available within the Node.js environment. Installing, updating, and removing third-party modules using npm is also covered in this segment.


Transcript from the "Internal & 3rd-Party Modules" Lesson

>> So we can just breeze through these two things so we can get to writing some code. But basically, just wanna go over some of the useful internal modules that are out there in Node.js that we're gonna talk about. And we can kinda just play around with them, so let's do that.

So I've already talked about a little bit of them, talked about fs. This one's really cool, this is one I think you start to realize things are just really powerful. So fs is a core internal module that stands for file system that allows you to do all different types of things.

So I'm just gonna hit fs., can you show me some stuff? There we go. Okay, so you can see here, I can read files, I can write files. There's a lot of different things you can do with the file system. Pretty much anything you can do as a human on your computer with files, this thing can do in code, so just think how powerful that is.

And you might even be thinking, yeah, cool, I can open a file, I can look at it. I mean you're writing code right now to a file, so this thing can also write code to a file as well, so it can get very complicated. If you've ever used something like Create React App or any starter template thing like that, that's what they're using.

How do they write that file to your file system? Well, they probably use fs or something like that, right, to write that. So any time some program is writing things for you, it's using fs, so you can get pretty complicated with this module. So fs is a good one.

Another good one is probably gonna be http. So http is exactly what it sounds like. It's just a module that helps you with networking in Node.js, not as low level as TCP, but right above it with http. So you would use this to make a server, which we are gonna do today.

So you can make a server, send back some JSON, send back some images, send back a file, or whatever, this is what http is for. It's still pretty low level and most people don't use this directly, they use something on top of this like a framework, but that's a really good one.

There's tons, I could talk about this all day. There's path, which people don't really use anymore because they don't need to. Yeah, so those are some really good internal modules. And then let's talk about npm, so this one is really important to understand. We've been using npm this whole time, but I don't think we quite understand what's going on here.

So I'm gonna head over to my terminal. And npm just stands for node package manager. It manages your packages at Node, that's really all it does. So right now, we've used it to link things and init, but we didn't use it to install anything. So let's install some stuff with it, it's actually quite simple.

All you have to do is type in npm install, followed by a list of package names you want to install. So how do you know what packages you need? There's this really cool tool called Google, where if you type in npm and then followed by the thing that you need, there's probably a package for it.

Say anything, I guarantee there's a package for it. Just give me an example of something you would wanna do in JavaScript, anything.
>> Parse EXIF data.
>> What is it?
>> EXIF.
>> EXIF, I bet there is something for it. Let's see, there it is, exif-parser. [LAUGH] There's one, it was published six years ago.

So yeah, you'll come to the npm page here, which tells you all the stats about it. You get the link to the repo, you can go check it out. You see the repo was updated. The last update was, yeah, five years ago. So this one's probably outdated, but that doesn't mean it's bad, it's just it's not updated.

Here's the documentation for it. More importantly, here's how you install it. So if we wanted to install this, we could just say, npm install, followed by that name, exif-parser. And it's gonna go download it and install it, done, easily. But where did it install it? Well, hold on now, what is this?

We have this Node modules folder now, this wasn't here before, this got created. And the Node modules folder is the folder in which all the things that you download live. They live in this folder now, this is their home. It also created a package-lock.json. What is this? This is a file similar to package.json, but it basically locks in the versions of all the things that we installed.

And this is useful, because if we're working on the same team, we wanna make sure we got the same versions of the same modules, so this helps us ensure that. And also when we deploy this to another server, we wanna make sure that server has the same versions of the same modules, otherwise things might not work.

But you might be asking yourself then, why don't I just include the Node modules folder when I put this on GitHub or on my machine, and then I won't need this file because the modules will already be here? Okay, you never include Node modules in Git. The reason why is because if you include Node modules to Git, every PR you make is gonna be, I don't know, 20 million changes cuz it's gonna look at every single change in all that code.

And here's the thing, you didn't write any of this code, this code came off the Internet. Why do you need this to be checked in the Git? Why do you want code that you didn't write, that's not part of your repo to be part of your pull requests and your code reviews?

So it's really expensive, you don't really wanna do that. So that's why you have these files here that list all the different versions of all the dependencies that you installed so it can just be replicated again. So anyone on any machine could just say install and they'll get the same dependencies you installed with the same versions without you having to send those dependencies in Git, right?

So typically, you would git ignore the Node modules folder. The other thing is in our package.json, you'll notice is now we have a dependencies object and there's an entry for exif-parser. There's also a version here, but it's not an exact version. This caret just means within this range, so that's why we still have that package.lock to ensure that it resolved to a very specific version, which you can see right here it resolved to this version, so we'll always get this version.

No matter what computer we're on, no matter what machine we're on, we'll always get this version. So that's what npm does. And that's how simple it is to install something. You just npm install, or even better you could just say, npm i, and that'll do the same thing.

So now, if I delete this Node modules folder, I no longer have that thing installed, but it's still in my package.json, it's still in my package.lock. So this is the equivalent of someone else on my team installed some modules, I just pulled it out for the first time so I don't have those modules.

But these files do get checked into Git, so now all I have to do is to say, npm install with no arguments. And what it's gonna do, it's gonna read these files and go download all the dependencies for me. So if I just do that with no arguments, it went and installed the right thing anyway.

>> Do you ever have to worry about security with downloading random npm installs?
>> There's been so many issues in the past of really bad actors, not even bad actors, just people. For instance, there was this one package that was used by every other big package in the world.

It was something small, it changed a string or something like that, and it broke, all right? This package broke and it pushed up a broken change to npm, and it broke the whole Internet because the package was broken. So everyone had to go patch that, because this one little package was broken, right?

And then there are times when people will push up malicious things and you'll just install it and you won't know. So yes, you do, and if you work at a bigger company, they're very serious about it. You have to get things on a whitelist of approved packages and stuff like that.

Sometimes attorneys are involved, cuz of IP issues and stuff like that. But for the most part, I would say people are very careless, they will just install things and just it works, right? And I think that's because there's a lot of trust in the open source community that if you publish something that's bad, that's gonna look bad on you.

So the way that I do it is I'll go Google something, I'll get on GitHub, I'll check out their GitHub, right, and then I'll just check out the activity. I won't really look too much into this person. I mean, there are people who do a lot of open source that I recognize and that's all they do.

But I don't really care who the person is, but I'll look at their activity, I'll look at the issues. If infact, it was bad, somebody might have opened an issue here and they're like, don't download this, this is terrible, right? So I'll do things like that, just some slight research can save you a lot of time.

But I'm definitely not going in here like, let me look at this code and let me, I'm not doing all that, that's just too much work. So yes, you will run into that. It's more likely that you'll run into something that's broken than something that's malicious. And that happens a lot, and that's just because everything moves so fast.

It's a very good chance that something is broken because people just give up on these projects. They'll make something, and in the moment, it was cool, then they were just like, and they'll just go work on something else, and not knowing there's a million people relying on this thing.

And then it died because some new version of Node came out and killed it. So that's more likely, yeah. Any other questions? Nope, okay? All right, yeah, so that's npm, pretty simple. And then you can uninstall things by just doing npm uninstall, followed by the thing that you wanna uninstall, so in this case, exif-parser.

I can uninstall that and it will remove it from my package.json and remove it from my package.lock, it no longer exists. It also removed it from the Node modules, so that's how you would uninstall things, cool. npm also does other stuff, but 90% of the time, you're just gonna do npm install.

That's all you're gonna be using it for unless you're making packages, which we're not gonna do in this course.

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