CommonJS Export

[00:00:00]
>> Sean Larkin: There was a request, yes, I read those feedbacks. Somebody said, well, how do I use CommonJS modules, Sean? So there are gonna be times when you're forced against your will, you have to use CommonJS. A good example is the React. It frustrates me so much that they're still in CommonJS, but they don't really care, cuz they have their own module system internally.

[00:00:27]
Anyways, so yes, if we wanted to use a CommonJS module, why don't we just define one so that we can actually consume it? So maybe I'll pop back into our dev mode to get our nice looking incremental build. And so for CommonJS, the format is kind of similar.

[00:00:50]
This is something that I always confused myself though from time to time. So let's just say we have something called, I don't know, let's say, button. All right, and we have two options. So we can do a default export, or we can do named exports. Now, I think about my button, if I wanted to describe what I want my button to do.

[00:01:19]
Let's say, I want to take a name or a string, and then that's gonna be the label, the button label. The label, and return a element, right? Okay, that's cool. So now, I won't use the dom APIs yet, but we can kinda think about this still. So module.exports.

[00:01:47]
See, I'm even questioning myself right now just thinking about module.exports. So, with CommonJS, exports is with an S, not without an S. So, that's where I always confuse, but module.exports is your default export. So, what we're seeing here is I wanna provide a function that takes a button name and then returns something.

[00:02:13]
So return, why don't we just return, Button, and then buttonName as a string for right now?
>> Sean Larkin: Why am I getting yelled at?
>> [INAUDIBLE]
>> Sean Larkin: Tell me why you're mad at me.
>> Speaker 2: Parentheses on the end, around the brackets.
>> Sean Larkin: Thank you. See? Crowd-driven development is my favorite.

[00:02:43]
[LAUGH] Now, of course, our dev build hasn't recompiled. We haven't seen anything different, right? So why don't we go ahead and consume this, right? Cuz this would be nice if we take a name, and then we return something. And so let's go ahead and pull it in. Now, we have some rules in Webpack that just say, you cannot use CommonJS and ES syntax in the same file.

[00:03:14]
It would throw an error. Or you can't use an export, and then a default exports, or a module.exports. So what I tend to do is usually just use the ESM syntax at the top level. Webpack supports using require, but what we'll do is we actually have interrupt to support using both and have it work accurately with the correct cyclical dependencies and light binding.

[00:03:42]
So since we know this is a default export, we can actually call this like, makeButton from, and now we see button here. And there we go, we have Webpack recompiling.
>> Sean Larkin: And sure, I could call makeButton, and them pass, My first button. [LAUGH] Okay, so now, if you wanted to use, let's say, what would be a great idea?

[00:04:22]
We're gonna get that element and pull it in here, but maybe we have a couple different styles we wanna apply to it, or would we style strings? I think that's fair. So why don't we create another file? Let's just say we wanna button-styles.js. I'm just gonna try and show you the CommonJS named exports.

[00:04:47]
Again though, I heavily endorse not to use CommonJS as much as possible, and sometimes you might be using it and you don't even know it on accident. There are tools like Babble and Typescript that safely default to converting your ESM to CommonJS behind the scenes and then passing it to Webpack.

[00:05:09]
But Webpack supports ESM out of the box, and that's makes it possible to tree shake, to code eliminate, and all the optimizations.