tsc Inputs & Outputs

[00:00:00]
>> Anjana Vakil: Let's talk about JavaScript So TypeScript and JavaScript are, at least as of this recording, intimately intertwined And to use the amazing, is it Predator handshake meme that, what they have in common is JavaScript So JavaScript is still kind of the living, beating heart of TypeScript And when we said that TypeScript is a superset of JavaScript, basically, everything about TypeScript is kind of anchored in JavaScript

[00:00:44]
So even though there's extra syntax and there's extra type information, at the end of the day, JavaScript is what unites them in the most powerful, epic handshake So refreshing our notion of like, when we compile with the tsc command, when we compile a .ts file, tsc generates a .js file And maybe then some, we'll talk about that later

[00:01:21]
And the types that we wrote don't exist in that file So if we go back to our type.js that was output by the compiler, like, where's all my beautiful type aliases Where's all my wonderful type info It's not there This is just events It's even So, and yet somehow, TypeScript knew information about it, and this code still works because the TypeScript compiler said it would

[00:01:58]
So, this is one thing to understand, it's like when the TypeScript compiler reads .ts and writes .js, all of that extra stuff that is in the outer part here of the Venn diagram, the superset, all of that stuff only exists while we're writing the .ts code, and like as we are running the compilation, but once we have compiled it to JavaScript, it no longer exists

[00:02:32]
It is really only something that exists for us at compile time So when we execute JavaScript code, so when we execute TypeScript code with something like TSX or newer Node versions and things like that, under the hood, it's removing that type stuff so that it can run the code as if it were JavaScript And we're going to be spending a lot of time talking about exactly what is going on there and exactly how tsc knows what kind of JavaScript to output

[00:03:21]
Like, for example, this is some code that maybe we're not used to seeing in JavaScript files, or vars haven't shown up in, you know, code that's on camera in a while So we're going to be getting to know and love or feel other emotions about our good friend tsc by doing lots of compiling So earlier we ran tsc on a .js file, and we passed in a bunch of flags that back then I just said like, yeah, don't worry about it, we'll figure it out

[00:04:08]
So what do these flags do Well, we talked about what noEmit does a little bit ago, but we're going to examine that a bit more here The other two we're going to sort of understand, as they do what it says on the tin CheckJs says, hey, tsc, I know that by default, you are a TypeScript compiler, so you check .ts files That's the default

[00:04:45]
But with our checkJs flag, we're saying to the compiler, hey, also check my .js And with strict, what we're doing is giving TypeScript kind of a shorthand, like a cheat code for a whole bunch of ways that it can be more rigorous with us in terms of the exactness of the types of data that are flowing through our program And noEmit, we said it's going to stop it from emitting anything output by the compiler, like the .js file that we just poofed into existence by running tsc on our type.ts file

[00:05:43]
So when we talk about compiling to .js, we're essentially talking about reading .ts and emitting a rewritten file that expresses the same logic, the same program as the .ts file, but in JavaScript, without any of the extra TypeScript syntax that is a superset around JavaScript So if we think about this in another way, these flags, some of them, affect what are the inputs and what are the outputs to the compiler

[00:06:23]
So by default, the compiler is looking for inputs that are .ts files, and by default, it's going to output, emit .js files We didn't tell it, hey, I want you to emit a .js from my type.ts file It just does that That's its baseline That's what it's here for, bro So we can tweak that if we need to by, for example, adding the checkJs flag

[00:06:52]
We're saying, OK, in addition to your regular default .ts inputs, I also want you to take in my .js files as inputs and keep doing what you regularly do with the emit part and give me that .js output But if we run the noEmit flag by itself, we're saying, OK, no change to your default inputs We're still going to be looking at the same .ts files, but please just don't give me those .js files

[00:07:26]
Don't emit anything So, even with just these couple of flags, we've already actually been configuring the TypeScript compiler and tweaking its settings of what inputs it's reading in and what outputs it's writing out Or not Question How does this look in CI normally, like if you're going to push code and you don't want to see .js files, would you just not run that locally, do like a pre-commit hook to make sure you have proper types and then let it run with output in CI or like

[00:08:02]
OK, so, um, let me try to rephrase the question So it's like if we're using this not, you know, at the command line where we're trying to understand what tsc is doing, but if we're trying to automate some of this and maybe use type checking, use tsc for type checking before we like have GitHub deploy our code somewhere or blah blah

[00:08:25]
What if we don't want the .js files What if we want it to just, you know, what, how do I make it do what I want And yes, the types, the tsc compiler can be used as a kind of pre-build or pre whatever part of your workflow, and we're actually going to take a look at that later But, suffice it to say that there are a bunch of options we can use to really fine tune what's going on with the compiler, and later on in the course we're actually going to be considering TypeScript, like how do we actually put this to work for us as part of our overall developer workflow