Episode transcript for the podcast “Listen, Learn, and Code”. See podcast overview for more episodes and additional information.

Transcript

Hello and welcome to “Listen, Learn, and Code” - the podcast where you can learn coding while doing something else, like cleaning your room, or watching cat videos.

In the previous episodes, we’ve already mentioned that TypeScript can be configured in certain aspects. So before we look at even more built-in types, let’s see how TypeScript configuration works. So, get ready, and let’s get started!

When using the online playground, you can open the configuration options by clicking on the “TS Config” tab above the editor field. Most of the settings are boolean true-or-false options represented by checkboxes. You will also see short explanations for each of the settings. If you need more information on a certain setting, you can look it up in the reference documentation that I’ve linked in the show notes.

When working with TypeScript on your machine, you can specify configuration settings in one of two ways. The first way is to provide command line parameters when you invoke the TypeScript compiler “tsc”. A more convenient way is to use a configuration file. To generate this configuration file, you can execute the following command:

tsc --init

This generates the file “tsconfig.json”. This file contains about one hundred configuration settings, together with short explanations on their meaning. Most of them are commented out, which means that TypeScript uses their default value. If you want to change one of these settings, you can simply remove the comment marker, and adapt the value. The JSON format itself doesn’t allow comments, but TypeScript makes a useful exception here.

Now let’s take a look at the most important configuration settings.

With the “target” setting, you can decide the ECMAScript version for the transpiled JavaScript files. The default for this level is ECMAScript 3, which is very conservative. This ECMAScript version was released back in 1999. The TypeScript manual currently tells us that you can safely use ECMAScript 6 instead. This version was released in 2015 and is supported by all modern browsers. If you know your clients well, you can of course use an even newer version instead. The advantage of newer versions it that they produce shorter and more performant JavaScript code. The target value in the generated config file depends on the version of the TypeScript compiler that you have installed.

A nice thing about having a tsconfig file is that it makes compilation easier. In the previous episode, we compiled our “Hello World” program using the command

tsc hello.ts

In most cases, your program will grow, and have more than just one source file. What you could do is list all your source files as arguments to the tsc command. So for example, if you have a source file named “hello.ts”, and another one named “foobar.ts”, you would invoke the command

tsc hello.ts foobar.ts

But of course, that will get tedious soon. If you have created a tsconfig file, all you have to do is execute tsc without any arguments. The TypeScript compiler will then automatically search for all source files, and compile them.

As you start working with multiple source files, you will probably notice something else that annoys you. By default, the JavaScript files are generated next to their corresponding TypeScript files. Usually, you want to have generated files at a separate location. This way, you don’t mix them up with the manually edited files, and it’s easier to package them up for distribution. Suppose you have a folder called “dist” in your project (which is short for “distribution”), and you want the JavaScript files to be generated into this folder. For this, you have to set the configuration option called “outDir”, which stands for “output directory”.

Now you have your output files neatly together in a “dist” folder. What if you also want your TypeScript files together in their own “src” folder (which stands for “source”) next to this “dist” folder? You can create this folder and move the TypeScript files there, and the compiler will still find them. But if you look into your “dist” folder again, you will see that it now also contains an “src” folder, which doesn’t look very nice for a distribution. You can solve this by setting the configuration option “rootDir” to “src”.

So much for the folder structure, and on to the next important configuration option. With the “strict” setting, you can activate a whole bunch of other options that deal with strict type checking. There are currently 8 related options that usually default to false. But if you set “strict” to true, the default value for these 8 other settings also changes to true. When you start a new TypeScript program, you will probably want to enable strict mode to get the most out of TypeScript’s safety features. That’s why the generated tsconfig file explicitly sets “strict” to true. If necessary, you can still disable some the related options later. So for example, you can explicitly set two of these eight options back to false to disable them again. If you migrate an existing, large JavaScript program to TypeScript, you might want to go the opposite way. So you activate these eight settings one by one, and deal with the new warnings step by step.

The most important option that is contained in strict mode is “noImplicitAny”. To really understand this option, we have to know what the “any” type means, which we will cover in one of the next episodes. In a nutshell, the type checker basically ignores everything that has the “any” type, and doesn’t warn you if you do something wrong. And with this option, you can prevent that the “any” type is used implicitly in certain cases. So setting “noImplicitAny” to “true” is a good idea if you haven’t activated the “strict” option.

The second next important “strict” family member is the option “strictNullChecks”. When this option is turned on, TypeScript helps you to prevent NullPointerExceptions. We will see examples for this option when we take a closer look at the “null” type. If you prefer a more dangerous null pointer experience, like in Java for example, you have to leave this option disabled.

A final option that is not covered by the “strict” family is “noEmitOnError”. If you enable this option, the TypeScript compiler refuses to generate JavaScript code as long as there are errors reported by the TypeScript compiler. So the default value is that TypeScript produces output even if it thinks that you’ve made a mistake. This is possible because in TypeScript, type checking and transpilation are basically two independent steps, even if they are both done when you invoke the TypeScript compiler. This default setting is useful for migrating existing JavaScript projects, because you can enable additional checks without breaking your build and deployment pipeline.

So to sum up what we did in this episode:

  • We learned how to configure TypeScript both in the playground and on your local machine.
  • We saw that the generated tsconfig.json file contains comments, even though they are not supported by the JSON format.
  • And we learned about the following configuration settings:
    • target - for the ECMAScript version
    • outDir - for setting the folder for the generated JavaScript files
    • rootDir - for adjusting the hierarchy inside the output folder
    • strict - for activating 8 other options in the “strict” family
    • noImplicitAny - for preventing the implicit use of the dangerous “any” type
    • strictNullChecks - for preventing NullPointerExceptions
    • and noEmitOnError - for disabling code generation in case of errors

And that’s all for now. I hope you enjoyed this episode, which conludes the first batch of episodes for this podcast. If you wish to hear more of this, be sure to subscribe the podcast and give it a like, or drop me a message. If there is enough demand, I’ll be happy to hear you next time on “Listen, Learn, and Code”.

References