00:00 So the reason that when we run TSC, we're not emitting any JavaScript files is thanks to no emit true. Disable emitting file from a compilation. Like it should be emitting files from a compilation. So why would we want to do this? Well, if we turn this off and we basically say,

00:18 okay, in TypeScript as linter, we're going to say run TSC. Then inside here, first of all, it's going to say, okay, all right, we've got some interesting stuff going on. Probably need to disable this config option. Set up counter.ts. Okay, I got some various other errors and we're producing some JavaScript too.

00:37 This is essentially just doing the same work twice because what we're doing is inside Vite, Vite is now the one handling the actual bundling, the actual turning this TypeScript code into JavaScript code, right? And so no emit true basically says to the TypeScript CLI,

00:55 we don't need you anymore, or rather we don't need you to produce JavaScript files anymore. So if I remove these files, it's definitely not needed anymore, close down some stuff. The discussion is then why would you need no emit true? Or why actually do you need the TypeScript CLI at all? Well, Vite itself doesn't actually do

01:15 any type checking for you. So when we're working in Vite, we can basically do anything we want in terms of TypeScript. We can just remove stuff here and remove HTML button elements as well. Just like give us TypeScript errors all over the place. Vite won't mind. Vite will continue running your dev server.

01:34 It will push code to production if you want to. And so these actual errors here, they don't, Vite doesn't know about these. It just uses something called ES build, which is an alternative to the TypeScript CLI to take this TypeScript code and turn it into JavaScript code without type checking.

01:52 This means that it's faster at doing that job than the TypeScript CLI because the TypeScript CLI has to type check your code and then transform it into JavaScript. Whereas the Vite CLI just transforms into JavaScript, which is a lot easier. So why do we need TypeScript CLI

02:10 in order to type check our project? This means that when we run TSC or TSC watch inside here, and we, for instance, make a change to here to count, we're going to get an error inside here. And this is basically like a, just a warning to us. It's not going to block production code if we don't want it to,

02:29 but it's just going to say to us, you have something wrong with your code that you might need to go and fix. So TypeScript here is acting more like a linter than an actual build process here. And this is how you're probably going to be using it in most of your, especially front end applications. Sometimes when you're working in Node

02:49 or working in other places, you're going to need to use TypeScript CLI yourself in order to turn your TypeScript code into JavaScript code manually. But in many applications, that's just not going to cut it in terms of the complexity needed. So if you use Vite, if you use Next, Remix, Astro, any of these big front end frameworks,

03:07 then you're probably going to be using TypeScript more as a linter, and you're going to have inside your TS config, no emit set to true. Now, this means that TypeScript still has an important place in the build process. It says whether you're over your entire repo, whether everything is type safe

03:25 and whether everything is doing what you expect it to, but it's not actually building your code. Really important difference.