Introduction to Node.js, v2 Using npm Packages

Transcript from the "Using npm Packages" Lesson

[00:00:00]
>> Now I'm gonna talk about how to consume those packages that you installed inside of your own modules. So let's do that. So I'm gonna head over to my Package folder. I'm gonna make a new file. Not a new folder, a new file. I'll call it index.mjs, and I want to consume that lodash package that I just installed.

[00:00:24] So what you would probably wanna do is go look at the documentation on how to do that. So, in the sake of following my own advice, I'm gonna do that. I'm gonna look at the documentation and see if maybe they're up to date with es modules, and they have a really great thing.

[00:00:39] Wow, that's so many files. My goodness! Here we go. So the documentation is basically using common js, it's using the require statement. So I'm going see if I can get lucky and try out these es module imports instead. So I'm gonna say lodash is usually used as an underscore, and that's a play on another library called _js which lodash replaced.

[00:01:00] So usually people use the _variable name for lodash. So I'm gonna do the same thing. Import from lodash. So let's try that and let's see if this import actually works. Let's see what happens. So now I'm going to run that code. And it looks like it works just fine.

[00:01:21] So the interrupt here was just fine. The creators of lodash must anticipated this and made sure I was able to import it with no problems. So, a couple things to notice here. When we, let's go back to what we were working on earlier, before when we were importing modules that we created, notice that I put this ./ here, right?

[00:01:40] This is very important. This is not optional. When you put a ./ or if you got to go up a couple levels or, whatever that is. Long as there's a dot there, this is telling NPM, this is telling know that, hey, I want you to resolve a module that I created locally.

[00:01:54] This is a local module that I created. It's on the file system. It's in this project. It's in this directory somewhere. Go get it, it's a file. But when you don't put the dot in front of it or slash like that, it's telling NPM and know that hey, this is either an internal module like Fs, or it's something that I installed via NPM and it's in a node modules folder.

[00:02:16] So what node is gonna do and NPM is gonna do it's gonna first check to see if this is internal It's not, then it's going to recursively start walking up your directory tree and checking every node modules folder until it finds the matching thing. If it can't find it in the current working directory, then it will error out.

[00:02:33] I mean, it'll literally go all the way up to like the global folder of your computer looking for it. So if it doesn't find it, then you're like, I can't find this module like friends if I change this to something else, and I tried to run this code, it's gonna say MODULE_ NOT_ FOUND and can literally cannot find that module right there.

[00:02:50] So it's gonna keep looking. So if you have multiple node modules folders above this folder and something exists in there, it'll find it and use it and that may or may not be what you want. So just be cautious of that, that is gonna keep looking for the closest one until we resolve this package.

[00:03:05] You can change that behavior if you want, but it's not worth it. Cool, so, that's how we use those packages. And then as far as like if we wanted to uninstall this package, we could say NPM uninstall followed by the name lodash and as you can see it'll remove it.

[00:03:27] If I checked the package lock, it's no longer there. By tech I checked the package JSON is no longer there. It's gone. So uninstall completely removes it from the node modules folder as well, which as you can see was deleted because I don't have any more modules. So NPM was smart enough to just delete it for me.

[00:03:43] It seems like nothing was ever there in the first place. So that's how you uninstall. Now we did have a question about NPX. So I wanna talk about NPX. But before we talk about NPX, I wanna talk about global installs of packages. So far we've been installing packages locally to a project as it's going to exists inside of this app that I'm making and nowhere else.

[00:04:05] If you're not in this app, you can't use it. But sometimes you want some packages to exist globally on your machine and that's useful for things like a CLI. For instance NPM is a CLI. And did you know that you can install NPM with NPM? Yeah, I know it sounds crazy but you can because NPM is a package itself that can also be installed with NPM.

[00:04:25] So can yarn you can install yarn with NPM if you wanted to. And both of those should be global because we want to be able to use them from our terminal like this. If they were not global, we couldn't use them. So if you want to install something global, you would do NPM install, followed by the name.

[00:04:42] We try yarn this this time and then you would say -g for global. And then you will try to install it. So you can see right now I just installed yarn globally. So if I say which yarn, you can see I have yarn now, and I use NPM to install that globally.

[00:05:00] Now, sometimes there are some global CLIs, some global tools that you don't want to install. But you need some functionality out of them for there is a one off thing. Maybe it's a scaffolding tool. Maybe it's a deployment tool, but it's just something you don't really wanna keep around, but you do need to run it right quick.

[00:05:18] That's where NPX comes from. So NPX was also installed when you installed node. It's already here. If I type in which NPX, I should see that, hey, I have this thing called NPX. NPX is basically like running one off global install. So instead of installing yarn I could have just said npx and then yarn, and then whatever command that yarn can do.

[00:05:41] So in this case yarn has like a yarn add, then I'm gonna say yarn add lodash, so I'm telling npx to tell yarn to install lodash for me, so it's very meta. And this you can see it executed pretty quick. So it basically just runs that tool for us whatever this tool is in this case it's yarn.

[00:05:59] And whatever functionality that that command has it runs that without actually installing yarn. Even though I haven't installed it on my machine. If I didn't, npx will still work the same way. So it's great for one off global tasks that you don't wanna install. So, CI environments or CLI, as you just know you're not gonna use other than for like this one thing, it's perfect for that.

[00:06:22] And then to uninstaller globally, you will just literally do the same thing as before. The uninstall but you would just say that dash g and it will uninstall it. And it's that simple, it's gone. So npm is came up a long way it didn't used to be this good, but now it's pretty good.

[00:06:43] I've used yarn pretty much. The whole time it's been out and I just recently switched back to npm because it's amazing. But it doesn't really matter which one you use. They're both really good. And questions on any of that so far?
>> Does it make any difference if you use dependencies versus using dev dependencies in package.json.

[00:07:05]
>> Good question. Yes, I was going to talk about dev dependencies. Yes, where's our talk about dev dependencies. Yes, I was gonna talk about dev dependencies in the testing section, but I'll hint at it just now. There is the only difference when it comes to dependencies and dev dependencies is how and when they're installed.

[00:07:25] But as far as functionality, there's no difference. You can use a dev dependency the same way you can use a regular dependency. It just comes down to how and when they're installed. Yeah, good question. The question was, is there a problem if we use npm and yarn in the same project?

[00:07:41] I would say yeah, that would be a problem because now everyone else has to do the same thing. So, because okay, now there's a yarn lock file that says, here's the package of the version that we need. And now there's a package lock file that says, well, here's a package of the version that we need.

[00:07:58] So which one is the source of truth? I don't know. I guess it depends on which one you installed with. Yes, they both will write to the package.json file and least your dependencies will be in there. But if any of those dependencies required a conflict. Like for instance, if you had a mono repo that had like reacted and then there was another react app living next to it that was meant for like storybook or I don't know, whatever your configuration was, then how do you know what version of react to resolve to?

[00:08:24] And how do you know which tool did the resolution was a yarn or was an npm? Well, you don't. So, you'll just end up with probably the wrong version compared to everyone else. So if you are working on an existing project that's already using something, use that, I highly recommend using that and if you made a mistake and use something else, delete it, did not check it into git, and just get rid of it.

[00:08:44] One thing that I've done in the past is I've always added like a script to the package.json. So if you go to package.json, you can add whatever you want here. And sometimes it might make some sense to like make a script here, that like, does something, right. So this is npm.

[00:09:00] So now if you just, if you run like that now it doesn't really matter what you do. It can be very confusing, if you try to put two in there. I highly recommend just use whatever is in the project. And don't try to do anything else because everyone else has to also change as well.

[00:09:16] So yeah, just delete it.