00:00 One really interesting topic, which is relatively controversial between different dev teams, is should you block your dev server when you have TypeScript errors? Should you block your dev process, prevent you from moving forward when you have TypeScript errors?

00:15 Let's say you have an error here, which is saying type number is not assignable to type string. We're saying that this number should be a string, but in fact, we're passing a number. Not good. So should you, when you go over to your dev server here,

00:30 actually, should it block you from doing anything until you fix those errors? Now, I have this set up. So I have it set up inside my Vite.config.js inside here. I've added Vite plugin checker, and it's basically inside checker, I'm passing in TypeScript true.

00:48 And with this setup, it means that when I run this, first of all, I get errors in my CLI down here. So it's actually going to do the type checking for me. And it's also going to run it inside my dev server too. Now, some people like this approach because it means that they're forced to fix their TypeScript errors

01:07 before they actually see them on the screen. This means that when you then push them up to your CI, which is also checking your TSC, you're not going to get any surprises because you've known about them all the way from your dev server.

01:22 But I really don't like this, and I never ever set up my TypeScript this way. TypeScript really is just like, you should think of it like a linter. Unlike other strongly typed languages, TypeScript just compiles down to JavaScript.

01:38 It's not like Rust or something, where it's really important that you get all the types right because those types feed into the runtime. TypeScript types disappear at runtime, as we've seen. When they get turned into JavaScript files, it's just pure JavaScript.

01:54 So TypeScript is really just some annotations on top of JavaScript. And so if you've come from those strongly typed languages, you might think, oh, I need to fix my types first. Of course I do, because then it won't work at runtime. Whereas actually TypeScript, of course it'll work at runtime.

02:09 So what I like to do is really if this setup, if I encounter this setup, I'm really just sort of losing information here. Sometimes you actually just want to run your code in a broken state just to see how things are working and then fix the types afterwards, sort of in this prototype stage

02:27 when you're just kind of like working through your setup. And so this whole feeling of like blocking my tests from running or blocking my dev server from running when I'm doing this, it feels awful to me because really the runtime and the types are two separate things in TypeScript,

02:45 and you should treat them that way. The types just tell you things about the runtime, sure, but the runtime never ever uses the types. A different setup that I prefer is if I cd into this other directory, number three,

03:00 then I can see that I can say pnpm run dev, and I need to install. Now inside this setup, I have something different going on. I can go into the package.json here, and it's going to show me something important.

03:19 Now what I have is I have dev, and this is running run p dev colon asterisk. What this is going to do is using npm run all, it's going to run all of the scripts inside this package.json that start with dev, and it's going to run them all at once.

03:38 So here I have it. It's running Vite, first of all, great, and it's also running tsc watch. Now this is different from my previous setup because what I've got now is on this side, I get zero type errors inside my dev server. It's not blocking me at all.

03:55 Whereas when I go to my terminal, I can now see the type errors just in my terminal. So I get a really nice readout as to what TypeScript is thinking about my code that I'm pushing, but I can also see everything that I'm working on at runtime working here.

04:12 So this is my recommended setup where you should be able to always access your runtime code and see how the JavaScript is working. But you should also always have the ability to just check in with your TypeScript and make sure that you've not made any stupid mistakes. But one should not block the other just when you're working on it in dev mode.

04:31 When you go up to production, sure, TypeScript definitely should block you at that point, and you should have some blockades to make sure you can't push broken codes to production. But you should be able to mess about with code that TypeScript thinks is broken in dev.