Introduction to Node.js, v2 Finding & Installing Packages

[00:00:00]
>> So what I want to do is before we get into like installing things and using them, I want to show you how to find them in the first place. And this is something that I think it's actually a really important skill like I'm in a boat of a good developer is someone that knows how to use their resources, they know where to look, they know when to look, and they know how to try things to determine value really quickly.

[00:00:20] They can look at something and determine if this thing is valuable or not without wasting a lot of time. And I think that's a very important skill to have that no one really talks about and you don't really train for. It is something that you develop just along the way but if you don't have a lot of interaction with this, if you're not responsible for installing things at your company, you don't get this interaction.

[00:00:38] You don't get to build these reps. So I really pride myself being able to like go on NPM and see what's good and what's not good and try it out and move on with my day and try something else out. So I want to show you how I do that.

[00:00:50] So NPM registry is you could think of as like a database of Published NPM packages, and like that's basically it. So we're gonna go look at the NPM registry NPM js.com. It has a search bar up top and you can type in pretty much whatever you want. So let's say you're working on an API and you need to get a database.

[00:01:11] So if I type in database there's literally something called databases. an exact match is probably not what you were looking for. But there is something called database. And as you can imagine, there are over 500 pages worth of hits that contain the word database. So it will take you a very long time to go through and figure out what's what.

[00:01:31] So you probably want to come up with a bigger question. So like, maybe not that type of database, but maybe you're looking for a specific database. So let me go type in Mongo database, and try to see what plugins they have there. Okay, a little less, not so many pages.

[00:01:44] We're getting closer. So let's say we check this out. We look at, hey, I'm using Express checkout Mongo. So when you click on a package, you'll notice a couple things. One, you'll see the README here. This is the same README that's probably on the GitHub repository. It's the README.

[00:02:01] Dot md that's on the route. You can also see how many packages this package has because packages can have packages and that's where it gets pretty crazy. You can see what is using this as a package. So what's dependent on this and how many versions it has and when they were released, which is also really cool because that tells you how active or inactive this project is you can also see when it was last published, which is a good sign.

[00:02:26] So what I like to do is when I come here, I try to find the thing that I like. I try to see that make sure it was relatively updated, like if it says two years ago, unless there's literally nothing else I probably won't use it if it was updated two years ago.

[00:02:40] There's other things that this probably the last thing I'll try, I'll go try something a little more recent, the last couple months or something like that the latest. You can also go check out the GitHub to see the source code to see the open issues, open pull requests, these are all good signs.

[00:02:53] If I look at an issue, and I see that, okay, this issue was open 15 days ago. This is a pretty active project so you know this is very good sign that you have some support here if you need it because at the end of the day this is created by some developer just like you some engineer on their free time who just happened to do this.

[00:03:10] They probably have a full time job and a family and and they're not getting paid to do this. So like you but you also need this to work. So like you You can't demand that they fix it. You're not a paying customer. But at the same time you do want it to work.

[00:03:23] So you got to work with them. It's open source, you can create issues, you can fix them yourself. You can make pull requests and things like that. But at the end of the day, you do want a project that's at least maintained, it has some type of some type of maintainer behind it, that's keeping keeping it up to date and things like that.

[00:03:37] So that's what I would do once I find the thing that I want, and then I would install it. So one, I know that it's really good as lodash we go here, we see lodash is pretty good updated four months ago, which is honestly pretty crazy cuz I don't know what else they're adding to this.

[00:03:51] But yeah, lodash is one they even have the copy and paste commands that you can use here which is really cool. And that's what we are going to do. So that's pretty much my process of how I figure out what I want. So if I'm going to use something like lodash, this is how I would do it.

[00:04:09] I would go into my terminal. I would type in npm install, then I would type in the name of the package that I want, which is lodash. And in fact, actually before we install it, you can do this you can say npm info lodash and it pretty much gives you the same stuff that we just saw on the website.

[00:04:28] So that way you can see it here in your terminal. You can see keywords, GitHub URLs maintainers, when it was published last, all different types of stuff, you can do that. I think there's also an NPM search, you can search through here in your terminal too. But I don't know about that, I don't think I would do that.

[00:04:44] So yeah, now let's go on to install it. So I'm gonna say npm install. I'm gonna say lodash. But instead of hitting Enter, I'm actually gonna pass a flag. This is a flag. By the way, when you do dash, dash like that, that's a flag. And you can think of flags as like, options that we pass into a command line tool, what you will be making soon so you'll know exactly what that means when you make it.

[00:05:05] We're gonna pass on SS, save and I'm going to hit enter. So you can see it went and downloaded it you get a couple couple things here you get some notices you get some warnings you can ignore the warnings you can ignore all of this. This is not for you is not some meet meaning thing.

[00:05:20] Sometimes you'll see errors here and you should maybe look for those even sometimes it's not that big of a deal. And then you can see we add at one package, low dash version 14.17.21. So major version four, minor version, 17 patch 21, we add at one package from two contributors and that audited one package and half a second, zero vulnerabilities.

[00:05:41] So like they're really checking for everything. Now, if we go back to our code, we have this, we have two new files. Now well, one new file in one folder. We have a package lock JSON, and we'll talk about that. And then we have node modules. So this is what I want to start with node modules.

[00:05:58] If you open it up, there is a lot of code in here. We're like, what is all of this? Why is all this code in here? How did it get here? I didn't ask for any of this. I just installed lodash. But what is all of this? Well, these are probably the dependencies on which lodash depends on, because packages have packages.

[00:06:20] I know lodash recently kind of like broke everything up to be their own individual packages. And I would imagine if you install lodash by itself, it just pulls in all the individual packages and like bundles them for you. So these are all the dependencies that lodash actually needs.

[00:06:35] So that's what's inside of here. And if you install something else that has a similar dependency, there's a conflict npm tries to resolve that conflict by like going to like the most common version and it keeps everything flat and not nested. Different things like that so there's a lot of work going on behind the scenes of NPM, to make sure that your modules are like conflict free you have the right version and you don't have duplicates.

[00:06:57] Different things like that and it's all inside this node modules folder. So you should never touch this folder, you should never be coming here an adding files and trying different things and stuff like that because this is gonna get wiped out every every time someone runs npm install this folder is also not meant to be checked into source control.

[00:07:14] So what you would do is you would make a gitignore Git.ignore, and you'd add node modules to that because let's just be honest, you don't want to send up a bunch. You don't want to send a bunch of third party code that's not yours into your source control to be processed by whatever ci that you have, or code reviewed by some of you imagine a pull request of all of these files, when all you did was install lodash and use it on one line.

[00:07:48] But now your progress has all of these in green. That would be crazy, right? So you don't check this into source control. So how does someone like someone on your team or another machine on a CI somewhere?. How do they know what modules that this app needs?. If you don't check it in, like how do they know to get that code?

[00:08:05] Well, that's where that save flag came in. So when we did the dash dash save, what we actually did was we told npm to save the name of these dependencies. Into the dependencies object in the package, that JSON with the current version. So, when anyone else pulls this out from GitHub minus the node modules folder.

[00:08:25] All they would have to do is just run npm install with no arguments and that's gonna look at the package that JSON to determine what packages need to be installed, and then they will be installed there. Now to make sure that they install the exact same versions as that you have though what's supposed to be there.

[00:08:44] The package lock that the package lock JSON was introduced. This does exactly what it sounds like, it locks the packages and to the exact resolved or the exact result version that npm decided was correct, so if there's any like. Conflicts between versions. If there's any duplicates that were resolved, whatever they resolve to, will be saved in this package lock JSON, so that everyone on your team guaranteed to have the exact same dependencies, with the exact same versions, and there should be no discrepancies between that.

[00:09:16] So that's where that comes in. So all these work together to do that. That was a lot. Any questions on packages in npm before we move on. So yeah, the question was how do we know if the code is malicious? Well I would say this you literally don't know.

[00:09:37] There's no way of knowing. And so I'll tell you how we've gotten to this point where like that's been, even though you don't know how that's been almost entirely avoided is because of the community. So typically one just because you make a package, that doesn't mean a lot of people are going to install it.

[00:09:53] So that's why you should probably only install packages that, like I said, are being used by a bunch of people that kind of vet the fact that, hey, it's not malicious. It's on GitHub. You can see the code people are making issues. There's multiple contributors. It's being sponsored by big names.

[00:10:07] So that's a good sign, though don't just install something that no one else, didn't install. And if you have to go on GitHub and look at the source code. If you cannot find the source code, you can install it. Just don't run it and then go look at the code in the node modules folder.

[00:10:24] Don't run it and just see what it's doing. You can see what it's doing, and kind of figure out for yourself, but at that point, it's probably not worth it. You should just go find a better alternative or just whatever you're trying to install. Just make it yourself cuz if you got to go dig in an old models folder to see why this thing how this thing is safer not it's probably not worth it in my opinion.

[00:10:42] But yeah, it's mostly the power of the people that prevents that from happening. Whereas like, I can't think of like one big event where there was something malicious, but I can't think of plenty events where like someone changed something in a code and it broke everything downstream like someone changed this parentheses to this.

[00:11:01] Now every package that depends on this is broken. That has happened a lot. Yeah, so, the question is, what's the difference between NPM and yarn and why do people choose one or the other? So, yarn was created by Facebook Some time ago because at the current time when it was created npm was in this state of just basically not being updated.

[00:11:25] It was really slow. It didn't have this feature of like D duping it didn't have a package lock JSON at a time. So there was just so many issues around npm and it was the only thing around. So people just dealt with it. I guess the folks at Facebook got tired of it.

[00:11:38] So they made yarn, which was exactly like npm, but it did caching and it resolved versions. It dedupe things, it stored them flat. And so people started using yarn because of that, because it was literally the same thing, but better. It was exactly what they wanted from npm.

[00:11:53] Then soon after, because of just how competition works, npm was like, well, we're gonna do that too. So npm just does the same thing as well, just as good as yarn if not better. And so now it's like, well, whatever one you wanna use is probably the one that you're gonna use, because they all kinda really do the same thing.

[00:12:09] And as far as like, where they get the packages from, that's a sweet thing about these managers. Either yarn or npm allows you to basically point to whatever registry you want. NPM is going to default to the npm registry and I want to say yarn defaults to the yarn or the npm registry as well.

[00:12:25] I've had to check on that depending on what version of yarn you're using, but you can point to whatever register you want, and even GitHub who owns npm. Now, I guess Microsoft owns them now because Microsoft own GitHub owns GitHub. They have their own registry as well. So you could point to that and download from a GitHub registry.

[00:12:41] It really just as long as the registry follows the, the the way that the package manager is expecting to interact with it or someone makes a plugin for it, then the package manager doesn't really know what it's talking to or who it's talking to. And you can pretty much pull from anywhere.

[00:12:56] Is the package folder named important? No. I just called my package because I couldn't think of a better name. You can name this whatever you want it has no it whatever your name is folder. Has nothing to do with anything other than I guess the name of what's going to be in the import statement.

[00:13:13] If someone were to like drink, but the only thing that's really important is the main field. This is what so like, what if I were to import this package from inside of another app the way it would look is because the name is called app. It would look something like this.

[00:13:30] It would be like I would be importing you know Something from app, it will look like that. That's exactly what it will look like. And you can see, I'm only using the name of the package, not the name of the folder that the package is in. It's just that name field.

[00:13:47] And if it's like scoped it might be something like, my GitHub name or my npm name slash my thing. That way it's scoped you know, you'll see stuff like that companies use that a lot of companies will have something like some company here slash app, or something like that.

[00:14:02] Or slash lib utils, whatever. You will see that so, yeah it's a little different when you, it's a little different than like what you would normally think but yeah it's just the name field that determines how you import it and not the name of the folder that the package is in.