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: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: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: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: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?
>> 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.
[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.