This course has been updated! We now recommend you take the TypeScript Fundamentals, v3 course.

Check out a free preview of the full TypeScript 3 Fundamentals, v2 course:
The "Configuring TypeScript" Lesson is part of the full, TypeScript 3 Fundamentals, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Mike demonstrates how to set up the configuration file in TypeScript.

Get Unlimited Access Now

Transcript from the "Configuring TypeScript" Lesson

>> Mike North: So this commands are gonna get kind of vague and cumbersome. The conventional way to do this is to use a configuration file instead. So in my source folder, I'm gonna create a file site. In the hello-ts folder, I'm gonna create a file called tsconfig.json.
>> Mike North: And we're gonna look at the various things you can do here to set it up.

[00:00:28] There are two things you need to think about when configuring the compiler. Number one is defining which files are the inputs. And you can do that either by specifying a list of files, or my preference is include, which lets you specify some globs. You seen globs before like star.ts or something.

[00:00:55] One valid glob is everything in source folder. Right, so that's number one. What are we compiling? The second option is, how are we compiling it? What are the compiler options? So to get an equivalent result of what we were just looking at, we would do module commonjs, target.

[00:01:19] And VS Code gives you some, there's a JSON schema behind this file that'll give you the allowed values for this. So we'll pick es2017, and just for fun I'm actually gonna put the output in a different directory. Put it in the lib folder. And this would make it really easy to sort of to publish only the compiled output.

[00:01:43] If this were a library, I'd wanna publish that to npm so that JavaScript and TypeScript consumers alike, can import my code. They don't have to be able to read ts files. So now I can just run tsc. Everything looks good, and I should, after refreshing here, have a lib folder with this index.js in it.

[00:02:12] So this is great. So I could almost think of it as, if I delete our first attempt here. I could think of us, like our source folder has a ts file, our lib folder has the js output. I could check the source folder into Git, and I could only publish the lib folder, because we really only care about the compiled output.

[00:02:35] And you'd keep things very well organized in that way. So this is great. One problem I see though, we have all this great type information and the stuff that I would ask my users to run is missing this type information. Now, it's necessary for me to provide an option to not use type information because people might write JavaScript apps that depend on this code.

[00:02:59] But I wanna make sure I provide some other stuff on top of that. So we're gonna say declaration true and SourceMap true. Run the compiler again and we should see some new files pop up in the lib folder. One of them is a .d.ts file, right? Same file name but it's .d.ts instead of .js.

[00:03:27] And this, if you look at it, it looks kind of like a function with no implementation, we can see that the names of my arguments are there. We can see that we have types for the arguments. This, we'll learn in a moment, but it happens to be the way you represent the return type of the function.

[00:03:45] But nothing in here describes how you would actually add a and b together. And nothing describes that we're waiting half a second before returning that. So this is a type declaration file that is meant to layer right on top of the JavaScript, that it represents. And if you're using a TypeScript aware editor, like VS Code, it's going to read this and kind of match it with that JavaScript and understand that these are the types that are meant to go along with this code, which is what is run in order to get the value we're after.

[00:04:25] The other file is a source map, right? So, this is what would let us, if you put break points in your code, it's what would, in your debugger, map that break point back to the original TypeScript source. So you kind of feel as if you're debugging through TypeScript code, when in fact, that is not what's running.

[00:04:47] What's running is the JavaScript. I can close by giving you another example config here. So this is a more complicated one. The compiler has native support for react. So it can pass JSX. Can understand that if you call your files TSX, that's like a TypeScript react file. But you don't need anything other than the TypeScript compiler in order to check that.

[00:05:13] Strict, setting strict to true is really important. You may wanna have strict as false, it's default as your sort of Moving from JavaScript to TypeScript. The approach I'll show you involves starting with the loose configuration and then tightening it up. But ultimately, you wanna end up in a place where you've got some of these strict features turned on.

[00:05:39] Forbidding implicit any, that's also important. Implicit anys are like wild card. They're places where the compiler couldn't figure things out by itself. And it's kind of a place where any type is allowed. And to put that in a more pessimistic way, it's a place where you have no type safety, right?

[00:06:00] The TypeScript compiler can check and compile regular JavaScript. And if you are interested in learning more about this, check out the Visual Studio Code course on FrontEnd Masters. You can use JSdoc comments and say that this function has an argument and it is of type string and here is the description and the compiler will actually read that as type information.

[00:06:23] So even if you are in a position where you can't actually switch to TS files, you can still use the TypeScript compiler to check and make sure that your code kind of lines up in a type-safe way. And we already talked about the target environment, and they regularly add features, and keep pace with new drafts of the JavaScript specification.

[00:06:49] So async and await were things that were added recently. I expect they will do something about some of the new stuff, project fields. As things are added to the official JavaScript spec, you'll see them added as a new target.
>> Mike North: Yes?
>> Speaker 2: Do you have a recommendation for if you wanted to support, say, I think you said ES3 was like IA6.

>> Mike North: Yep.
>> Speaker 2: If you wanted the support to say like IE or all them, or you didn't want to support IE at all, unless their targets.
>> Mike North: Yep, good quesiton there. So really, can I ask you to refine your question there? Are you thinking about using Babel with typescript?

>> Speaker 2: Yes.
>> Mike North: So that, using Babel with TypeScript that would reduce TypeScript to really just the checker, not the thing it's producing the output. And the way I would recommend setting that up, would be have TypeScript emit very, very, very modern JavaScript, and let Babel take it the rest of the way.

[00:07:54] You already have something that can take regular JavaScript and target like with using Babel preset and you can just list your browsers, right? And say, I care about the last two versions of Chrome. And that library actually keeps up to date with Chrome, and will basically remove that responsibility from you and your team in terms of keeping track of what feature should I enable and what not?

[00:08:21] So I would say, leave your target as ESNext maybe. Now, as projects get really big, sometimes there are language features that just are not appealing to include. For example, at LinkedIn we have an app that enabling async in await would be tough, just because at every await we have to polyfill using regenerator or something like that.

[00:08:51] And this starts to get expensive, it actually increases the asset size quite a bit. So I would leave all of that in the hands of lending tools and Babel. And if you're just using the compiler as a static analysis tool, well, leave your target set at ESNext.