tsconfig Bases

[00:00:00]
>> Anjana Vakil: Thankfully, we do not have to individually write all of these compiler options ourselves There is an awesome set of base configs which we can leverage as kind of starting points for these various use cases that we might have So if you go to this repo on GitHub, tsconfig/bases, you will see, and again, we can, you can read all about this later, but you will see that there's a table of these are all of the base configs

[00:00:40]
They're kind of like out of the box, set up, ready to go configs that correspond to all kinds of different projects and tools that we might be using So for example, as we said, there's like a billion Node versions out there, and sure enough, we have TS configs that are set up for all those different Node versions if I'm doing something that's backendy with a Node project

[00:01:05]
But then there's also other things like React and even other JavaScript runtimes like Bun and all that good stuff which you can take all kinds of courses about on Frontend Masters, and we see all kinds of frontend frameworks too, like React and Svelte and various other tools that you may or may not recognize Point being, this can be a very helpful starting point so that we don't have to basically reinvent the wheel every time we want to TypeScript a new project

[00:01:45]
So how do we use these bases Well, each of these is like a package that we can install again with our dev dependencies because this is all at development time This is all before we ever actually get the code into Node or the browser or wherever it's going to go So what we can do is install the base that we want, and there is a really handy base called recommended that, guess what, is recommended

[00:02:19]
So we can install that one And then we can add on the kind of highest level of our config file, we can add an extends option and give it the path to a tsconfig.json file in that package So these are some just magical incantations that we're going to just chant in a circle Just kidding, we're going to chant into our command line, all right So if I run this command, and I'm still, I'm in my frontend directory

[00:03:02]
If I run npm i -D @tsconfig/recommended, now I'll see it added one package, and sure enough, in my TS, sorry, in my package.json, I now see it Awesome And now in my tsconfig, I can put this and you'll often see it right up at the top, and it's not going to be inside of the compiler options object It's going to be on the top level here, and conveniently, TypeScript is already helping me know what the many options are that I can type in here, and it's not externs, it's extends

[00:03:46]
And as TypeScript and VS Code are helpfully hinting me, this property extends is going to point me to a path to the base configuration file that this project wants to inherit its config from, or an array of them We'll talk about that in a second So, extends colon and then the name of the base that I used, so it was @tsconfig/recommended No, recommended slash and then tsconfig.json

[00:04:22]
I'm just going to add that on Although it might be able to find it without that, and now if I run tsc, I'm still getting that we have a small problem, which is that there's no TypeScript in this TypeScript repository And much like Jeff Goldblum was wondering in Jurassic Park, you did promise us TypeScript on your TypeScript course, and that's now going to be your problem

[00:04:59]
So what we're going to do is, you can browse on your own time, take a look at some of the other bases, and we can think about what some of the other values are that we might want to get involved here And as I just briefly mentioned, we can also pass in multiple configs to the, multiple base configs to the extends parameter, we can make it an array

[00:05:27]
And so, for example, since this frontend project, it uses Vite and Vanilla JS as I mentioned, there is a Vite React based config in here, which we could use, even though we don't have React It probably has some extra stuff to do React stuff that we don't really need So we can also install that one if we'd like Npm i -D @tsconfig/vite-react And back in package.json, it shows up there, and now if I want to, I can make this an array and extend multiple base configurations

[00:06:20]
And you can kind of think of this again, like a little bit object orientity, extending multiple interfaces or inheriting multiple classes, but what this will do is essentially keep tweaking our JSON for us So vite-react/tsconfig.json, it's going to be our other one, and we're going to later look at the backend side of this coin, and we saw all of those Node Node Node Node versions

[00:06:50]
We're going to worry about that later in our backend We're not finding any files So that's what tsc is complaining about I don't know what you want me to check because you didn't tell me to check anything Can anybody think of ways that we could give tsc some code to look at and tell it that we wanted to look at our codebase full of JavaScript files

[00:07:23]
Rename a JavaScript file to a .ts file We can rename a JavaScript file to a .ts file Bingo Shall we start with main Perhaps Because it's there I'm just going to do this right in my IDE here Boom Oh good, squiggles So now, hopefully, if we run tsc, it at least found the one file, and it's found 8 errors in it So we're off to a grand old start But what we've got now is hopefully a working tsc

[00:08:03]
Well, we can see it's a working tsc, and now if I run my show config, it's going to tell me what it actually did, like what config it actually used to come up with these error messages to look at my input files, etc., and we'll see that there's a whole bunch of options in here that I didn't write, because they're inherited from that base config And again, we're not going to go through all of these, but you can on your own

[00:08:36]
But suffice it to say, it's real nice that we didn't have to figure all this out for ourselves And we can see in this files array, like exactly which files it is actually looking at Can anybody think of another way that we could give TypeScript some more input files to look at Is there a flag to look at JS as well We had a way to look at JS as well, right

[00:09:04]
It was our checkJs option So we could run that We can tell tsconfig that we also want it to check JS by, for example, adding We can, why don't we take these out for now, just so that we know exactly what is happening is all coming from our base configs, and indeed it is Even if I make compiler options just completely empty, tsc still has a bunch of compiler options that are inherited from those other base configs

[00:09:46]
And we are again going to be able to tweak this further by kind of in the same way that we can extend interfaces, we can extend this config with our own options So here if I want to do, and because TypeScript knows what a TypeScript config looks like, it's going to helpfully, if I start typing checkJS, the default is false, we're going to change that maybe

[00:10:14]
Let's see what happens Now, if I do tsc show config, I get a whole bunch of other files that tsc is going to look at And sure enough, if I run tsc, found 95 errors and 9 files, yikes, okay Now we're not actually going to ask tsc to check JS for this project, we're just warming up to TS configs here So I'm actually going to set this back to false

[00:10:45]
We'll go back to only checking a subset of our code because this is more realistic for what you might run into if you are, let's say, migrating a JavaScript codebase to TypeScript, or if you landed in the middle of a project that is a migration in progress that was never completed, that has a mix of JavaScript and TypeScript files You'll often want to kind of make sure that you can bite off little chunks and go step by step by renaming certain files and leaving others in JavaScript for a while and kind of picking the low hanging fruit of the more problematic places

[00:11:29]
So that's what we're going to do is we're going to actually leave checkJs as false, so I can explicitly say it's false here or I can just omit this because that's the default.