Importing Modules

[00:00:00]
>> Okay so and yes and so for brevity we often do npm i or npm ig if we need to to install these and if we just run just as a recap if we just run npm install without any words after it. What it's doing is looking for a package.json right here where I am.

[00:00:21]
And installing all of the dependencies and their dependencies and so on and so forth of that package.json described by that package.json. Does that make sense? So that is how we're gonna be finding ourselves as developers a lot of the time. We're gonna be doing something like cloning a repository from GitHub or something.

[00:00:41]
And then npm installing so that we now have local copies of all of those packages that we need to make this thing go. And we're gonna look at more examples of that later. So now the question is, all right, I installed cowsay, beautiful, beautiful cowsay, as a dependency of my whereAmi project.

[00:01:03]
What use is a dependency in your project with all of the bloat of those 40-some other packages that it comes with if you're not using it in your project? So, how do we use it in our project? And so now that I have npm installed, within my amazing script whereAmi.json I now have this node modules folder gives me access to all of the code of all of these things.

[00:01:35]
Right so I get like there's JavaScript files in here and do they use var still sure, because we're not gonna talk about that, but VAR will outlive us all. And what did I just, it's because I typoed. Okay, so the way that I access that amazing code that is going to help me say things with a cow, in this case, is with the import statement.

[00:02:04]
There's more to say about that in a minute. [LAUGH] And so for example, in this case, Cowsay exposes a, Essentially method but it's, we'll call it a function called say that I can, if I import it, I essentially now have a variable say in my, whereAmi.js file that does whatever cowsay, defined that function to do.

[00:02:41]
And I can now use it like a regular old function in my code. So for example, I can wrap these in a say, and now we're getting into like the VS code versus doing this at the terminal situation. And this is very zoomed in. So this is basically taking up my entire screen now, but what VS code is doing, you've noticed all these things popping up as I type, right?

[00:03:11]
VS code is giving me what it thinks are helpful information, and hopefully most of the time actually is helpful information, about what it knows about this thing that I'm currently typing. And so in this case it knows from the cowsay module what this say function looks like what it expects.

[00:03:35]
And some of [LAUGH] you can make a paranoid cow you can make a wired cow some of the amazing things that it can do. And in this case, and this is all coming from documentation that this lovely developer wrote for me. In this case, it's telling me that the way you use this say, method, which I have just de structured from cowsay, is that you pass in a object with all your options and then a text property, that is the text you want to say.

[00:04:07]
And you can change the eyes, you can change the tongue, whatever. In this case, we're just we're just gonna be fine with the default cow, I think. And so we're going to say, and we have to conform to the API that this developer has chosen for us. We're going to say with cowsay the text and maybe we even want to just like add in the current year here.

[00:04:34]
And we'll just forget the timeout part. Helps if I define it first, okay. And so now if all goes well When I go back to my last terminal and I close you, and we do in our okay and so now we run this whereAmi.js, which I can again access through that main key of the package here.

[00:05:07]
Well, we get a fun little message that says, [LAUGH] Anjana, excuse you, you cannot use this import statement. I do not know, this is not the import that, [LAUGH] you are looking for. I do not know what you're talking about because you are outside of a module, and you can only use the import statement from inside of a module.

[00:05:34]
Now, this is one that I actually did intentionally do on purpose, because that brings us to our next topic, which is a whole beast of a thing that again. There could be an entire day of discussion about, but modules in JavaScript and in Node. The idea of modularity, right, just as like a high-level concept in coding is that just like NASA doesn't build an entire massive space telescope all in one go with like one engineer.

[00:06:07]
Neither do we build massive, large scale software projects with one JavaScript file and one developer writing that file. Like that would be [LAUGH] there's some other timeline where that's happening, and I guess at least we know we're not in the darkest timeline. So the idea here is that we want to be able to create a really complex program out of very much simpler parts.

[00:06:34]
And be able to put them all together like little Lego bricks together or little integrated science instruments. I'm on a massive space telescope for example, and have one team work on that and another team work on that and one person on the Internet over there. Kindly work on that and make it open source and so on and so forth.

[00:06:52]
So then we can pull all these modules together into a beautiful, complex program that does whatever we need it to do. So, that is something that many languages have, from the get-go, an idea of like, how are we going to deal with modularity in this language? JavaScript's not one of them.

[00:07:15]
So, in 1995 we were like, just add in some event listeners to some buttons, right? What else do we need a JavaScript to do? That's not too much. That's a few lines you can put between a couple script tags, no big deal. Then things started getting more and more complicated, more and more complicated, and then stuff like Node came around and was like all right now we're really dealing with a lot of complexity here.

[00:07:45]
We saw even one little cow saying something involves 40 packages. So we're gonna have to come up with a solution to deal with all this complexity. And now we've got massive projects on both sides of the Internet. We have client side projects that are absolutely huge,and we definitely don't want to be writing in a single script tag in an TML document,if we want to keep our wits about us.

[00:08:16]
And we also have massive server side node projects. So we have a ton of JavaScript, just so much JavaScript, eating the world, as it were. Like if they say software is eating the world, JavaScript is like eating software and the food chain is we're gonna, I don't know, some zombie is gonna eat JavaScript eventually.

[00:08:36]
But anyway, the point being, this has been, again, a gradual evolution over time. And at the beginning, that complexity wasn't necessarily at the top of Brandon Eich's mind when he was writing this language in 10 days. So some stuff evolved. And one of the things involved is a module system that Node uses by default.

[00:08:58]
And that goes back to the historical reason that that was its solution before there was any other solution. We'll talk about other solutions later. So CommonJS or CJS is a different way of dealing with getting code in and out of JavaScript files. And so CommonJS has a different API for that.

[00:09:22]
And CommonJS we have a require keyword that is like a function that we call on the name of the module that gives us an object that then we can like do stuff with like cowsay.say. And if we want to export something like another function for a somebody else who's importing this code to use we would have to do module.exports.

[00:09:48]
And like create this object that has all of the keys and the values and whatever and they could be properties. They could just be constant values, they could be functions like this one. So now somebody could import my module and run the whereAmi.move function or what have you get you see what I did there?

[00:10:07]
[LAUGH] And the world kept turning and no developers built super complex projects and they used requires all over the place and everything was more or less fine. But then, over the years, as we said, the client-side stuff evolves a lot, right, too. We have super massive client-side things, and for various reasons, a new solution emerges called ECMAScript modules, or ES modules.

[00:10:38]
Again, ECMAScript being the actual factual name of the JavaScript language specification that the specified language that is specified by the thing though, we call the JavaScript anyway. ECMAScript is the real true nature of JavaScript and it came up with a whole other way of doing module stuff. And this is where that import syntax comes in that we were doing before and this is the more universal solution now because the common.js stuff was not supported in the browser.

[00:11:15]
That was a node-ish thing and now we have ESM ES modules in the browser Browser and Node also allows us to work with them, but it still uses CommonJS by default. And from here on out, like essentially ESM is the way that we are moving forward as a community.

[00:11:40]
So we want to be doing stuff with ESM because we don't want to be writing different code for the front end and the back end. And we'd like to just have one less thing to worry about please please Internet and so this is the way. ES modules so we're not from here we're just going to put down CommonJS sure there is plenty more you could say about that but this is it we're doing ESM.

[00:12:02]
This is the way. Enjoy your baby yoda,