Tsconfig. json is a TypeScript configuration file that can be initialized using the TSC –init command. This article will read the configuration order that this command generates.

Ps: TypeScript version 4.3.4

incremental

With this parameter enabled, we can see a series of files with the suffix.tsbuildinfo in the same directory as the result of the compilation. This parameter can be used to cache the result of the last compilation to hard disk for the next compilation.

tsBuildInfoFile

As we explained in the previous article, when Incremental is enabled, some files will be generated with the default suffix.tsbuildinfo, and this parameter can be used to specify the name of the generated file.

target

TS as a static type detection language, it can only help us to find errors before the code is run, and finally to compile into JS to run, as to which version of JS, will depend on this parameter to specify.

module

To switch the package management system, we can set different values depending on what type of project we are developing, such as ‘commonJS’ for node.js projects.

As an example, we can see what this configuration does if we write two lines in a TypeScript file:

import { age } from "./constants";

console.log(age)
Copy the code

When we set the module value to ‘commonJS’, the compiled result looks like this:

"use strict";
Object.defineProperty(exports."__esModule", { value: true });
const constants_1 = require("./constants");
console.log(constants_1.age);
Copy the code

When we set the module value to ‘ESNext’, the compilation result is unchanged:


import { age } from "./constants";

console.log(age)
Copy the code

allowJs

By default, TypeScript can only import.ts and.tsx files. With this option, we can also import.js files.

// @filename: foo.js
export const foo = () = > {
    console.log('hi')};// @filename: index.ts
import { foo } from "./foo";
foo()
Copy the code

checkJs

This parameter should be used in conjunction with allowJs. If this parameter is enabled, we will be notified of any errors in JS. However, in my experience, this parameter can be difficult to turn on for projects that mix JavaScript and TypeScript.

JSX

Indicates which way to translate JSX syntax, parsing only for.tsx files.

In React 17, the developers optimized the JSX conversion. With this parameter, we can specify which JSX conversion mode to choose. Refer to the link

declaration

This command generates d.ts if we develop a package in TypeScript and need to use it in JavaScript. Generating.d.ts files at this point gives us a nice reminder of the code even in the JavaScript environment.

declarationMap

This command is used in conjunction with the generated.d.ts file. Before opening it, use the editor to find the method definition (CTRL + right mouse button) to find the corresponding interface definition. Turning on this property will help us find the real method.

sourceMap

Helps us debug TypeScript code while debugging on the console.

outFile

It packs all the files into the file we specified, but it doesn’t work in CommonJS and ESM, so we won’t go into that too much.

outDir

For example, we specify that the conversion results of.ts files should be placed in the dist directory:

{
    outDir: './dist'
}
Copy the code

removeComments

Whether to remove comments from translated JavaScript code.

noEmit

When this parameter is turned on, JavaScript code is not translated, SourceMap is not generated, and.d.ts files are not generated. We might use it with Babel, where we might just treat TypeScript as a type detector and leave the rest of the work to Babel.

downlevelIteration

When enabled, it helps us translate the new syntax so that older browsers can support it, similar to Babel.

Take this code for example:

const str = "Hello!";
for (const s of str) {
  console.log(s);
}

Copy the code

Will translate into:

"use strict";
var str = "Hello!";
for (var _i = 0, str_1 = str; _i < str_1.length; _i++) {
    var s = str_1[_i];
    console.log(s);
}
Copy the code

importHelpers

One problem with enabling downlevelIteration is that multiple places using the same new syntax will not be merged into one place, resulting in redundant code. For example, if two places in our project use for… Of, then the above translation result will appear twice.

If we start importHelpers and encounter a new syntax, we resolve the problem by importing the method’s polyfill from the tslib package rather than translating it directly. Of course, at this point we need to make sure that the tSLIb package is installed in our project.

For more examples, see: this link

noEmitOnError

For those of you who have written TS, you may have encountered a scenario where webPack cannot continue compiling if the type is not written correctly. If we want to change a working JS file to TS, the biggest obstacle we encounter is the type error, as in the following code, which can be run in JS:

function greet(person) {
    console.log(person.toUpperCase())
}
Copy the code

But if we change the file’s suffix to “.ts “and turn on the noImplicitAny property, ts will report an error, which we can turn off if we don’t have time to fix all the TS errors and want to compile. Otherwise, turn this property on.

This property is useful when migrating old JS projects to TS projects.

strictNullChecks

If this property is not enabled, we can write code like the following. Although the following statement will return an error at runtime, it can also pass TS detection:

function doSomething(x: string | null) {
    console.log("Hello, " + x.toUpperCase());
}

doSomething(null)
Copy the code

If this property is enabled, we can only call the toUpperCase method if x is string:

function doSomething(x: string | null) {
  if (x === null) {
    // do nothing
  } else {
    console.log("Hello, "+ x.toUpperCase()); }}Copy the code

If x is not null, TS will return an error. If x is not null, TS will return an error.

x! .toUpperCase()Copy the code

But be careful, it doesn’t rule out null, we just write it this way and tell TS that it’s not null, so we don’t get an error.