I've got some exciting news for you and know the exciting news isn't that I'm now using Vrsaljko code
instead of sublime text, I still love my sublime text code editor.
But just to change things up, I'm going to use this code for now and I'm going to talk about ESX modules
in note.
You see, up until now, we had to use the required syntax, which is what we call the common JS syntax
with note.
Originally node was created with this syntax in mind because JavaScript wasn't created with modules
in mind and they never had the import export syntax that we had with S6.
So because Node was created before we even had that, they had to create their own module system, which
is how we got require and this common syntax.
But as of node version 12, they now have S6 style module imports and exports.
So the good news is that if you're watching this video and you have the latest version of Node, then
congratulations, you can now start to change from require to using import export keywords.
So let me show you, based on what we've just done and what we've learned about modules, how we can
convert this to S6.
So the first thing we can do with script to dogs is to well, actually you can remove this entire thing
and we can just simply say.
Consed large number, so now this gets exported.
So I can see that next in here instead of the required syntax, let's comment that out.
And let's say import.
And in here, we'll import doing the structuring the large number that we export.
So remember, we did export large number and we're going to say from a script to grab a large number.
So this object, this structuring simply says out of the script to object that we're going to import,
just grab the property, large number so I can say from an in here dot script to.
Dodgiest, so now that I've imported large number.
And I did object to structuring I don't need to call script to dot large number.
Instead, I can just simply do large number.
So will this work?
Well, let's test it out.
I'm going to open up the terminal here.
And in here, I got to make sure I'm in the right folder so I should cwd into the S6 folder and in here
I have the script and script to us.
Now, if I do this, do you think it will work?
Well, the first thing I want to do is check my note first.
So if I do Noad Dashkova and you should do the same, what's the number that you get in here?
I see that I have a pretty high note version.
As a matter of fact, it's higher than version 12.
And if you remember, with version 12, we got ESX imports.
So this should work, right?
Well, let's test it out.
I'm going to say Noad script dot James.
Syntax error cannot use a statement outside a module.
Hmmm, why is that?
I mean, I have the right version.
Luckily, Noad gives us some hints warning to Loden ESX module set type module in Pakistan.
Jason or use the MJF extension.
And this is a little Gocha.
Because node was created with this common import export in mind, we need to actually specify.
How we want know to read these files, so we know that we're using the ESX syntax because remember,
it's different from a browser.
So we have two options here.
And I also want to show you how you can find this out on the documentation website for note.
Usually what you would do is Google ECMAScript six nogs.
You'll probably get to the nogs documentation.
And we can see here we have module's ECMAScript modules and let's go to enabling.
And if we click on enabling, we see over here.
All right, there you go.
We need to add the MDGs file extension inside of package.
Jason, we have to update the field.
So if I click on the type field, I'll read about it here and I say, oh, in poor segments of JS files
are treated as S modules if the nearest parent package that JSON contains type module.
So this is a good way to learn how to read the documentation.
Remember, the answer is probably always inside of the documentation.
So let's follow their advice.
What if I rename these?
M. J.
Yes, and this to.
If I now run this.
Do you think this will work?
Actually, I have to fix one more thing, right?
I have to make sure that the syntax while we're importing is M James.
For fun, let's see if I can do it without the file extension.
Let's save here and run this.
Cannot find module, so we actually have to specify the file extension and if I run this again.
Hey, check that out, everything works out, Essex Imports works, and we just followed what they've
recommended name false IMGs, but there was another option to write the package JSON option.
So let's rename this back to some people really don't like the syntax IMGs and they prefer this method
instead.
So, again, what we'll do.
Is will run this again and make sure we change this to dogs, back to dogs, and if we run our code,
you'll give us an error because again, we have to add type module inside of package that Jason.
Hmm.
We don't really have packaged Jason.
Right.
But we can just run the command npm in it and then dash y to say yes to all the options to simply create
our package.
Jason?
Well, there you go.
So in here, all we need to do is just simply inside of package that Jason wherever we want ad type
module so that it reads the package that Jason and says, oh, yeah, they're going to be using ESX
modules.
So if I see this and now go back and run my code.
Look at that, it all works.
How cool is that?
Now, go ahead and play around with ESX modules as you start working with more and more NOAD code,
you're going to see more import statements than require statements like we have before.
However, because a lot of code bases still use the required syntax.
If you go on NPM, for example, and try to download packages, a lot of them still suggest that you
use the require syntax, and that is because you're not sure that everybody has the latest version of
note.
Some people might be running a node version that is lower than version 12.
In that case, the code isn't going to work.
And that's why for the rest of the course and even for the final Smart Brain project, I've left our
note files with the required syntax so that anybody, any student taking this course can run those without
any errors.
But feel free to update them if you ever want with S6 imports.
But for now, it's always a good idea to keep the [REMOVED]'s syntax to make sure that if your code is
being run on different systems and you don't have control over the node version, well, then you can
make sure that they require syntax is going to work for everybody.
I'll see in the next one, pabai.