Now, before we continue on with the webpack.config.js file itself, let's take a minute and talk about ECMAScript 2015 modules. So, I find that this confuses a lot of people, at least initially. When you think of modules, just think of it as a fancy word for files. So, when I say module, just think file, okay? Now, any file can export or expose to the outside world anything at once. It can export a function, it can export a class, an object, it can export multiple functions even. Let me give you an example. Here's our main.js, and we could call this our entry point. So, I will define a function called notify here. You give it a message, and all it's going to do is just alert that message. Very, very simple. So, now I can say notify(Here is my message), and then we'll compile it down.

Very, very simple. So, now I can say notify. Here is my message, and then we'll compile it down. Great. So, let's view this in the browser now, and sure enough, we get our notification. However, you'll find that storing every single thing, every function, every class, every object within a single file gets muddy very, very quickly. Everyone who embraced jQuery heavily probably experienced this, where you have an app.js file that is thousands of lines long, and it's a huge slog to work through. So, instead, just like your PHP classes or your Ruby classes, we can divide our JavaScript into any number of files to organize things. So, let's do that now. I'm going to take our simple function, and we'll store it as notification.js, and I'll paste it in right here.

So, let's do that now. I'm going to take our simple function, and we'll store it as notification.js, and I'll paste it in right here. However, do you remember earlier when I said a module can expose anything at once to the outside world? So, in this case, it has a function, but it hasn't been exposed or exported to the outside world. I'm going to change this. I will say our default export is just this function, and that would be fine. So, now, if we come back to main.js, I want to say, well, I want to import that module or that functionality into this file. So, we'll say import, and why don't we call this notify. It can be anything we want, and I'm going to import it from notification. And notice for relative modules, I add the ./ here.

We get the exact same thing before, but now we're starting to learn how to organize and structure our JavaScript, and trust me, you're going to find that this drastically cleans up your code. Now, though, here's one thing that can really confuse people. There are multiple different formats for importing and exporting. So, if you've ever heard of CommonJS, well, that's a little bit different from ECMAScript 2015 modules. So, you might see something like this, module.exports equals a function, and then within your main.js file, you could say var notify equals, and then we would require the module. It's just a different format for doing the same thing. So, if we compile that down, you're going to see the exact same end result as before.

It's just a different format for doing the same thing. So, if we compile that down, you're going to see the exact same end result as before. And yeah, that can be a little confusing, right? Because you see, so for any given project, you might see common.js and ECMAScript 2015 modules being used at the same time. Now, as confusing as it may be, two good things. One, with webpack, or even if you're using Laravel Mix, you're going to be able to use both. There won't be a problem there at all. However, if you're starting from a clean slate, I would say don't bother with common.js. Use ECMAScript 2015 modules. That will enable a lot of inspections and optimizations with webpack that we can talk about in the future. So, in closing, we'll say import notify from 'notification'. That's the equivalent. And then your modules will not do module.exports.

All right. So we refresh. And now, you'll get our object that contains both of those functions. And this could almost be like your little library here for notifications. So I could say notification.log. Here we go. And then let's come back. Maybe we'll change this to announce. And then we'll do another one. All right, so that's running. It recompiled. So if we give this refresh, oh, and whoops, we get an issue. Notify is not defined. You know what? That's because we updated our function, but we didn't export it as announce. So we'll fix that. All right, one more time. And there we go. We get our alert as well as our console.log. Okay, so potentially some new things here. I would recommend do exactly what I've done here. Just start playing around with it. Experiment with creating a module, which is just a file, and then doing anything. Maybe you have a little calculator.

Okay, so potentially some new things here. I would recommend do exactly what I've done here. Just start playing around with it. Experiment with creating a module, which is just a file, and then doing anything. Maybe you have a little calculator. Maybe you have a notification thing here. It can be anything you want. You will decide your default export, and then you will import that into your main file, and then you will work with it. Have some fun!