Type-Checking Dev Workflow

[00:00:00]
>> Anjana Vakil: Let's talk about type checking So we talked about how we can use TypeScript without emitting files, without compiling to JavaScript, with that no emit flag We can use that to just double check our types and make sure that the compiler is happy And what you'll often see is that in your development workflow in a TypeScript project, you'll often be doing that as kind of a precursor to some other next step of getting your code out into the world, into the hands of the amazing users who will never again have to see an object object rendered in their browser

[00:00:44]
So there are some ways that we can make sure that our types are checking out as we go Like, for example, tsc actually does have a watch flag which, very similar to the scripts that we were using to watch our code for updates, this will rerun the compiler every time I save the files that tsc knows about and is looking for But because as we said earlier, the TypeScript compiler has to know a lot

[00:01:16]
It has a huge cognitive overhead to be able to figure out all of these different types and all of these built-in types and look at all of the source code and all of our repo and all of the dependencies and blah blah blah So this can end up being pretty slow, so it often works well for like smaller projects, but sometimes you'll find that gradually you'll feel like everything is grinding to a halt

[00:01:44]
So, not often something that we're going to be doing, but what you will see a lot of in like package.json's in TypeScript projects is a lot of commands that look something like this, where what we'll do is before our regular command, whatever we're doing in this case it's a test, but often this will be like before a build command or as was briefly mentioned yesterday, like before maybe some other hook that's going to push your code somewhere, something like that

[00:02:17]
What we'll see is some kind of type checking command, in this case just our friendly old tsc no emit, and then this ampersand And this is more of like a unix thing I guess, but or you know, how we often run these is to make sure, basically what that ampersand does is make sure that the command to the left passes, like succeeds, returns with a non-error kind of status, and then goes on and runs the command to the right

[00:02:49]
So this is a kind of a handy way to make sure before you do something like in this case, before we run our test, which is just a handy development workflow thing, but sometimes before you push code or before some other very long expensive build process starts or something like that, you'll want to make sure that your types check out before that happens So what this means is that if tsc is unhappy, which it tends to be, we are not going to actually launch the test runner

[00:03:24]
So what we're going to do back in our exercise is update our test script to add that little tsc no emit, and you can add if you want to add another command like for example to compile so that you get all of those amazing output emitted files, you can, you know, have fun with your scripts directory This is kind of where it's up to you and your team if you're working in a team, what your kind of ergonomics are for the commands that you need

[00:03:57]
But in this case, what we're going to be doing is updating the test scripts so that we check our tsc no emit is happy before the tests run So back in my package.json, we're going to write our tsc no emit && Vitest And save, a step I often forget to do And now if I run npm run test again, hopefully, ah yes, we get the unhappy output of tsc and the tests haven't started running yet So we are going to now try to make TypeScript happy, as seems to be our new mission in life.