Using Modules

[00:00:00]
>> All right, so we can also use ESMs in the browser, ESM, ESModule syntax, the import statements and whatnot, and export, if we put a type module in our script tag. Browser loves those types attributes. So, we can use this same syntax in a client-side script that has type equals module.

[00:00:25]
And in node, there are a couple ways we can tell node that we wanna use the ESM, the ES modules, Vibe, the ES module solution instead of CommonJS. And one is that we can give a different extension to our file. So instead of .js, I could call them .mjs.

[00:00:46]
Or I can add the key type module, the entry type module to my package.json. So I'm gonna do that because I only have to edit one line of code rather than a whole bunch of file names. So if we add type module to our package.json, that is going to transform this from a thing that will be interpreted by node as a common js module to a thing that will be interpreted by node as an ES module, allowing the different syntax that I want.

[00:01:24]
So I can, we can do, I'll just put it right here, doesn't really matter. There's, yeah, so and you can see here VS code is very helpfully auto-completing the options, and it is good to be explicit in general, right? Because for example, some other thing might make a different default choice if there is no type set, but in this case, these days we're likely just gonna be writing type module a lot, so let's get friendly with it.

[00:01:51]
Okay, now that I have declared this to be a ES module, whoops, my gosh, I keep [LAUGH] entering code in completely wrong places. Type module, clear, cool, okay. All right, so now if I run, What I was just trying to do, which is the script that's from the entry point of main.js.

[00:02:24]
Before that gave me the error about, I don't know what import, you're trying to import and you're outside a module, so like, now it's not a problem. Now we just have a beautiful cow saying some stuff, it has a very default eyes and tongue set, but you all can figure that out later.

[00:02:41]
So the point here is [LAUGH] there is a big difference between, [LAUGH] well, first of all, between the way that node historically handles modules, and now that most kind of modern projects are moving towards, is that to say, you're not gonna find a whole bunch of requires in your node dependencies?

[00:03:01]
You definitely are. Go poking around through node modules you'll require all kinds of other things. But since the browser supports yes modules too, and we have to be explicit about it there also, so that it doesn't think it's just dealing with our regular old script tag that can't support this type of import output system, we need to be explicit about it.

[00:03:26]
So type module is gonna show up on both sides of the interweb divide. This also works now with the scripts that I have defined in my package JSON that are going to use the code that I've written to run things. So, for example, this one I got a little cowier with.

[00:03:48]
Anyway, [LAUGH] okay, the idea here is not to have wrapped our heads around everything there is to know about modules in JavaScript because again, it's an infinite task. But now that we're at least in a nice moment of time where people have generally reached a consensus of the Mandalorian style, this is the way forward with ES modules.

[00:04:09]
It's a lot better than when there was a moment there where it was like, we got to support both all the time and everything. So that's still a historical fact we have to live with. But for now, from here on out, we're just gonna be in ES module land.