00:00 We're going to start our explanation of module node next here, which is a really, really important config option to know about. Module node next implies a second config option of module resolution node next here. So basically if you have module node next,

00:15 it implies the second one here and I tend to just omit a module resolution node next because one gets implied by the other and they always need to be paired together. So module node next, what it does is it should be used when you're using TSC to transpile your code.

00:32 The reason it should be used in this way is because it copies the way that node works and the way that node understands your code. Now this gets really difficult when we start talking about ES modules versus common JS modules.

00:50 So if we look at our three files that we're outputting here, we have a common JS dot CJS file and this common JS dot CJS file, what it's doing is it's using require or common JS versions of imports and exports. So it says exports dot example equals this example here.

01:10 If we look at the source file, we've got common JS dot CTS, and this is going to look really weird to you because common JS dot CJS, it's using require calls. But actually the thing that we've got in here is ES modules. Hmm, that's weird. So we're using ES modules in the source here,

01:27 but TypeScript is outputting common JS. Interesting. The reason it's doing that is because we have a dot CTS file here. Now, if we have a different file extension here, ES module dot MTS, we're actually able to import from common JS here.

01:46 And the thing that gets emitted is ES modules that you're used to writing here. And this is fascinating because we're using this dot MTS extension here. TypeScript is able to understand that this file is supposed to be outputting ES

02:02 modules, whereas this file is supposed to be outputting common JS. Fascinating. If we change this, if we change this to a module ES next, for instance, now we're forcing both of them to use ES modules here. So this one, even though it's a CJS file,

02:21 when node looks at this is actually going to break because this type of imports and exports are not supposed to be inside CJS files. And if we do the same thing again, if we go back and we change it to common JS, now it's forcing everything to be common JS here,

02:36 which is really not what you want when you're using this dot MGS extension. So this is what node next does is it follows nodes semantics for what sort of thing is supposed to be in what sort of file. Now we have a third one here, which is, it depends on the package dot Jason.

02:55 Now what this does is we have a package dot Jason with a type of module inside. And what this is doing is it's saying this is supposed to be a ES module package. And so everything inside this folder here that has this package dot Jason inside,

03:12 you should treat this as ES modules or rather if you encounter a JavaScript file here, a dot JS file, it should be treated as ES modules. And so the thing that gets outputted by TypeScript is ES modules. Whereas if we change it to in fact go back to package dot Jason,

03:29 we can either change it to common JS here and now like magic, this is now require calls instead. How brilliant is that? And so we change it back. And in fact, if we just use the default as well, which is the default is actually common JS here, then this will be common JS. But if we change it back to type module,

03:49 then this depends on package dot Jason file will be transformed back to type module. So you can start to understand how complex this is really because node next here, what it's doing is copying nodes semantics for the extensions, checking all of the package dot Jason files,

04:07 and also finally making sure that everything has an extension on it. Because when you have all this sort of CJS, MJS nonsense, you want to make sure that the extension is correct. And we're going to be looking at that more in the next exercise.