Skip to content

tsconfig.json Complete Usage Guide

About 4608 wordsAbout 15 min

typescript

2022-04-28

The TSConfig file is used to indicate that the directory it is in is the root directory of a typescript or javascript project.

The TSConfig file can be tsconfig.json or jsconfig.json, and their configuration and behavior are the same.

Official Documentation

Basics

Using TSConfig is very easy. Just create a tsconfig.json or jsconfig.json file in the directory:

tsconfig.json
{}

TSConfig contains the default configuration.

TSConfig mainly contains the following top level configuration fields:

{
  "extends": "",
  "compilerOptions": {},
  "files": [],
  "include": [],
  "exclude": [],
  "references": [],
  "watchOptions": {},
  "typeAcquisition": {}
}

extends

Type: string

The extends property is used to inherit configuration from another TSConfig file. Its value is a path, or a Node.js style path. If it is a relative path, the path is resolved relative to the configuration file. If it is a Node.js style path, the path is resolved from node_modules.

extends does not inherit the files, include, exclude fields in the configuration file, and does not allow circular references between configuration files.

example

tsconfig.base.json

{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

tsconfig.json

{
  "extends": "./tsconfig.base",
  "files": ["main.ts"]
}

tsconfig.noStrictNullChecks.json

{
  "extends": "./tsconfig",
  "compilerOptions": {
    "strictNullChecks": false
  }
}

compilerOptions

Specify the compilation configuration of typescript.

compilerOptions mainly includes the following configuration contents:

Type checking:

allowUnreachableCode, allowUnusedLabels, alwaysStrict, exactOptionalPropertyTypes, noFallthroughCasesInSwitch, noImplicitAny, noImplicitOverride, noImplicitReturns, noImplicitThis, noPropertyAccessFromIndexSignature, noUncheckedIndexedAccess,noUnusedLocals, noUnusedParameters, strict, strictBindCallApply, strictFunctionTypes, strictNullChecks, strictPropertyInitialization, useUnknownInCatchVariables

Modules:

allowUmdGlobalAccess, baseUrl, module, moduleResolution, moduleSuffixes, noResolve, paths, resolveJsonModule, rootDir, rootDirs, typeRoots, types

Emit:

declaration, declarationDir, declarationMap, downlevelIteration, emitBOM, emitDeclarationOnly, importHelpers, importsNotUsedAsValues, inlineSourceMap, inlineSources, mapRoot, newLine, noEmit, noEmitHelpers, noEmitOnError, outDir, outFile, preserveConstEnums, preserveValueImports, removeComments, sourceMap, sourceRoot, stripInternal

JavaScript Support:

allowJs, checkJs, maxNodeModuleJsDepth

Editor Support:

disableSizeLimit, plugins

Interop Constraints:

allowSyntheticDefaultImports, esModuleInterop, forceConsistentCasingInFileNames, isolatedModules, preserveSymlinks

Backwards Compatibility:

charset, keyofStringsOnly, noImplicitUseStrict, noStrictGenericChecks, out, suppressExcessPropertyErrors, suppressImplicitAnyIndexErrors

Language and Environment:

emitDecoratorMetadata, experimentalDecorators, jsx, jsxFactory, jsxFragmentFactory, jsxImportSource, lib, moduleDetection, noLib,reactNamespace,target, useDefineForClassFields

Compiler Diagnostics:

diagnostics, explainFiles, extendedDiagnostics, generateCpuProfile, generateCpuProfile, listFiles, traceResolution

Projects:

composite, disableReferencedProjectLoad, disableSolutionSearching, disableSourceOfProjectReferenceRedirect, incremental, tsBuildInfoFile

Output Formatting:

noErrorTruncation, preserveWatchOutput, pretty

Completeness:

skipDefaultLibCheck,skipLibCheck

watch options:

assumeChangesOnlyAffectDirectDependencies

allow Unreachable Code

Whether to allow the code to include code that will not be executed

  • undefined default provides suggestions to the editor as warnings
  • true allows inclusion
  • false does not allow, and gives an error warning

example "allowUnreachableCode": false

function fn(n: number) {
  if (n > 5) {
    return true
  } else {
    return false
  }
  return true
  // error: Unreachable code detected.
}

allowUnusedLabels

Whether to allow unused labels.

  • undefined default provides suggestions to the editor as warnings
  • true allows inclusion
  • false does not allow, and gives an error warning

example:

function verifyAge(age: number) {
  // Forgot 'return' statement
  if (age > 18) {
    verified: true
    // error: Unused label.
  }
}

alwaysStrict

Ensure that the file is parsed in ECMAScript strict mode and add use strict to each source file.

exactOptionalPropertyTypes

If exactOptionalPropertyTypes is enabled, typescript will use a stricter mode for optional properties declared with ? via type or interface

example:

interface Theme {
  colorThemeOverride?: 'dark' | 'light'
}

If this configuration is not enabled, the value of colorThemeOverride can be 'dark', 'light', undefined.

If this configuration is enabled, the value cannot be explicitly assigned to undefined.

"exactOptionalPropertyTypes": true

const theme: Theme = {}

theme.colorThemeOverride = 'dark'
theme.colorThemeOverride = 'light'

theme.colorThemeOverride = undefined // error

noFallthroughCasesInSwitch

If set to true, any non-empty case branch in a switch statement must contain a break or a return.

noImplicitAny

In the absence of type annotations, typescript will fall back to any when it cannot infer the type. This may cause some errors to be missed.

With this configuration enabled, typescript will report an error when the type falls back to any.

function fn(s) {
  // Parameter 's' implicitly has an 'any' type.
  console.log(s.subtr(3))
}

no Implicit Override

no Implicit Returns

no Implicit This

no Property Access From Index Signature

no Unchecked Indexed Access

no Unused Locals

no Unused Parameters

strict

Whether to enable strict mode type checking. When this option is enabled, all strict series of configurations are also enabled.

strictBindCallApply

When enabled, TypeScript will check whether call, bind, and apply call the underlying function with the correct parameters.

strict Function Types

When enabled, TypeScript will use stricter type checking for function arguments. It should be noted that this configuration only applies to function syntax, not to method syntax。

function fn(x: string) {
  return x
}
type Fn = (ns: string | number) => string | number

const fn1: Fn = fn // error: Types of parameters 'x' and 'ns' are incompatible.

strictNullChecks

When enabled, typescript treats undefined and null as different types.

strictPropertyInitialization

When enabled, typescript checks properties declared in class to see if they are initialized in constructor.

useUnknownInCatchVariables

allowUmdGlobalAccess

Allow Umd global access.

When allowUmdGlobalAccess is set to true, it allows you to access UMD exports as global variables in module files. A module file is a file that has or both imports and exports. When this option is not set, using the exports of a UMD module requires first importing the declaration.

For example, in a web project, you know that certain libraries (such as jQuery or Lodash) are always available at runtime, but you can't use them by importing them.

baseUrl

Sets the base directory when resolving non-absolute module names.

module

Set the module system of the program.

Optional values ​​include: CommonJS, UMD, AMD, System, ESNext, ES2020, ES6/ES2015, ES2022, Node16, NodeNext, None

moduleResolution

Specify the module resolution strategy.

Optional values ​​include: node, classic.

If no value is specified, when module is CommonJS, it is node, when module is UMD, AMD, System, ESNext, ES2015, it is classic.

moduleSuffixes

Declare a list of file name suffixes to search for by default when resolving modules

{
  "compilerOptions": {
    "moduleSuffixes": [".ios", ".native", ""]
  }
}

import * as foo from "./foo";, typescript will search for ./foo.ios.ts, ./foo.native.ts, ./foo.ts.

noResolve

paths

Path settings. Remap module imports to configuration relative to baseUrl paths.

paths allow you to declare how TypeScript should resolve your require/import.

{
  "compilerOptions": {
    "baseUrl": ".", // this must be specified if "paths" is specified.
    "paths": {
      "jquery": ["node_modules/jquery/dist/jquery"]
    }
  }
}

Tell the TypeScript file parser to support some custom prefixes to find code. This pattern can avoid long relative paths in your code:

{
"compilerOptions": {
"baseUrl": "src",
"paths": {
"app/*": ["app/*"],
"config/*": ["app/_config/*"],
"environment/*": ["environments/*"],
"shared/*": ["app/_shared/*"],
"helpers/*": ["helpers/*"],
"tests/*": ["tests/*"]
},
}

resolveJsonModule

Allows direct import of .json modules. And generates static types based on json.

rootDir

Root directory.

Default: The longest common path among all input non-declaration files. If composite is specified, it is the directory containing the tsconfig.json file.

rootDirs

Root directories.

With rootDirs, you can tell the compiler that there are a number of "virtual" directories that act as a root directory.

This will allow the compiler to resolve corresponding module imports in these "virtual" directories as if they were merged into the same directory.

typeRoots

By default, all visible @types packages will be included in your compilation process.

Any package in node_modules/@types is considered visible.

For example, this means including all packages in ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/.

When typeRoots is specified, only packages under typeRoots will be included. For example:

{
  "compilerOptions": {
    "typeRoots": ["./typings", "./vendor/types"]
  }
}

This configuration file will include all packages under ./typings and ./vendor/types, but not under ./node_modules/@types. All paths are relative to tsconfig.json.

types

By default, all visible @types packages will be included in your compilation process.

Any package in node_modules/@types is considered visible.

For example, this means including all packages in ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/. .

When types is specified, only the listed packages will be included in the global scope. For example:

{
  "compilerOptions": {
    "types": ["node", "jest", "express"]
  }
}

This tsconfig.json file will only include ./node_modules/@types/node, ./node_modules/@types/jest and ./node_modules/@types/express. Other packages under node_modules/@types/* will not be included.

This option does not affect how @types/* are included in your code.

When you set this option, by not including it in the types array, it will:

  • Will not add global declarations to your project (such as process in node or expect in Jest)
  • Exports will not appear in auto-import suggestions

declaration

Generates a .d.ts file for each TypeScript or JavaScript file in your project. These .d.ts files are type definition files that describe the external API of a module. .d.ts files can provide intellisense and precise typing for untyped code.

declarationDir

Configures the output directory for declaration file generation.

declarationMap

downlevelIteration

Downlevel is TypeScript terminology for converting to older versions of JavaScript. This option is intended to more accurately implement the modernJavaScriptconcept of iterators on olderJavascript` runtimes.

ECMAScript 6 adds several new iterator primitives: for / of loops (for (el of arr)), array spread ([a, ...b]), argument spread (fn(...args)), and Symbol.iterator.

--downlevelIteration will allow more accurate use of these iteration primitives in ES5 environments if Symbol.iterator is present.

emitBOM

emitDeclarationOnly

Generate only .d.ts files, not .js files

importHelpers

importsNotUsedAsValues

inlineSourceMap

Whether to inline sourceMap

inlineSources

mapRoot

newLine

Specify the line ending sequence to use when outputting files: CRLF (dos) or LF (unix).

noEmit

Disables the compiler from generating files such as JavaScript code, source-map, or declarations.

This leaves room for another tool, such as Babel or swc, to handle the process of converting TypeScript to files that can be run in a JavaScript environment.

You can then use TypeScript as a tool to provide editor integration, or to type-check your source code.

noEmitHelpers

noEmitOnError

Do not allow the compiler to output files such as JavaScript source code, source maps, or declarations if any errors are reported.

Defaults to false, which makes it easier to use TypeScript in a watch-like environment, where you might want to see the results of code changes in another environment before making sure all errors are resolved.

outDir

If specified, .js (and .d.ts, .js.map, etc.) will be generated into this directory.

The original source file's directory will be preserved, if the computed root directory is not what you want, see rootDir.

If not specified, .js will be generated into the same directory as the .ts files that generated them.

outFile

If specified, all global (non-module) files will be merged into the specified single output file.

If module is system or amd, all module files will also be merged into this file after all globals.

Note: outFile cannot be used unless module is None``, System or AMD. This option cannot be used to bundle CommonJS or ES6 modules.

preserveConstEnums

preserveValueImports

removeComments

Ignore comments in all TypeScript files when transpiling to JavaScript. Defaults to false.

sourceMap

Enables generation of sourcemap files. These files allow debuggers and other tools to display the original TypeScript code when using the actual generated JavaScript files. Source map files are generated as .js.map (or .jsx.map) files alongside the corresponding .js file output.

.js files will include a sourcemap comment to indicate to external tools where the file is.

sourceRoot

stripInternal

allowJs

Allow JavaScript files to be included in your project, rather than just .ts and .tsx files.

This option is a way to allow .ts and .tsx to coexist with existing JavaScript files. Can be used to incrementally add TypeScript files to a JS project.

checkJs

Used with allowJs, errors will be reported in JavaScript files when checkJs is enabled. This is equivalent to including // @ts-check at the top of all JavaScript files in the project.

maxNodeModuleJsDepth

disableSizeLimit

To avoid possible memory bloat when working with very large JavaScript projects, there is an upper limit on the amount of memory allocated by TypeScript. Turning this flag on will remove the restriction.

plugins

A list of language service plugins that can be run from within the editor.

Language service plugins are a way to provide additional information to the user based on an existing TypeScript file. They can improve the existing information between TypeScript and the editor, or provide their own error messages.

allowSyntheticDefaultImports

When set to true, and a module does not explicitly specify a default export, allowSyntheticDefaultImports allows you to write imports like:

import React from 'react'

instead of:

import * as React from 'react'

This option does not affect the JavaScript generated by TypeScript, it only affects type checking. This option can make TypeScript behave in the same way as Babel when you use Babel to generate additional default exports to make module default exports easier to use.

esModuleInterop

By default (esModuleInterop not set or false``), TypeScript treats CommonJS/AMD/UMD like ES6 modules. This behavior has two documented flaws:

  • Namespace imports like import * as moment from "moment" are equivalent to const moment = require("moment")

  • Default imports like import moment from "moment" are equivalent to const moment = require("moment").default

This incorrect behavior leads to two problems:

  • The ES6 module spec states that namespace imports (import * as x) can only be an object. TypeScript's behavior of treating it as = require("x") allows the import to be treated as a callable function, which is not in compliance with the spec.

  • While TypeScript accurately implements the ES6 module specification, most libraries using CommonJS/AMD/UMD modules do not follow it as strictly as TypeScript.

Enabling the esModuleInterop option will fix these two issues in TypeScript transpilation.

forceConsistentCasingInFileNames

isolatedModules

While you can use TypeScript to generate JavaScript code from TypeScript, it is common to use other transpilers such as Babel. However, other transpilers can only operate on one file at a time, which means that they cannot perform code transformation based on a full understanding of the type system. This limitation also applies to the TypeScript interface ts.transpileModule used by some build tools. These limitations may cause runtime problems with some TypeScript features, such as const enum and namespace. With the isolatedModules option set, TypeScript will warn you if you have written code that cannot be properly processed by the single-file transpilation process. It does not change the behavior of your code, nor does it affect TypeScript's checking and code generation process. If isolatedModules is set, all implementation files must be modules (that is, they have some form of import/export). ### preserveSymlinks

charset

Configures the encoding to use when reading text files from disk.

keyofStringsOnly

noImplicitUseStrict

noStrictGenericChecks

out

Deprecated.

suppressExcessPropertyErrors

suppressImplicitAnyIndexErrors

emitDecoratorMetadata

Enable experimental support for emitting type metadata for decorators using the reflect-metadata module.

experimentalDecorators

jsx

Controls how JSX is output in JavaScript files. This only affects JS file output for .tsx files.

  • react: Change JSX to equivalent calls to React.createElement and generate .js files.
  • react-jsx: call __jsx instead and generate .js files.
  • react-jsxdev: call __jsx instead and generate .js files.
  • preserve: make no changes to JSX and generate .jsx files.
  • react-native: make no changes to JSX and generate .js files.

jsxFactory

Changes the function called in .js files when compiling JSX Elements using the classic JSX runtime. The most common change is to use h or preact.h instead of the default React.

jsxFragmentFactory

jsxImportSource

lib

TypeScript includes a set of default type definitions for built-in JS interfaces (such as Math), as well as type definitions for objects that exist in the browser environment (such as document). TypeScript also includes APIs for newer JS features that match the target option you specify. For example, type definitions for Map are available if target is ES6 or newer.

You might change this for a few reasons:

  • Your program doesn't run in a browser, so you don't want "dom" type definitions.
  • Your runtime platform provides some JavaScript API objects (perhaps via a polyfill), but doesn't yet support the full syntax for a certain ECMAScript version.
  • You have some (but not all) polyfills or native implementations for higher-level ECMAScript versions.

High-level library:

NameContent
ES5Core functionality of ES3 and ES5
ES2015Additional APIs in ES2015 (also known as ES6) - array.find, Promise, Proxy, Symbol, Map, Set, Reflect, etc.
ES6Alias ​​for ES2015.
ES2016Additional APIs in ES2016 - array.include, etc.
ES7Alias ​​for ES2016.
ES2017Additional APIs in ES2017 - Object.entries, Object.values, Atomics, SharedArrayBuffer, date.formatToParts, typed arrays, etc.
ES2018Additional APIs in ES2018 — async iterables, promise.finally, Intl.PluralRules, rexexp.groups, etc.
ES2019Additional APIs in ES2019 — array.flat, array.flatMap, Object.fromEntries, string.trimStart, string.trimEnd, etc.
ES2020Additional APIs in ES2020 — string.matchAll, etc.
ESNextAdditional APIs in ESNext — these will change as JavaScript evolves.
DOMDOM definitions — window, document, etc.
WebWorkerAPIs that exist in the context of a WebWorker.
ScriptHostAPIs for the Windows Script Hosting System.

Various components of the library:

DOM.Iterable, ES2015.Core, ES2015.Collection, ES2015.Generator, ES2015.Iterable, ES2015.Promise, ES2015.Proxy, ES2015.Reflect, ES2015.Symbol, ES2015.Symbol.WellKnown, ES2016.Array.Include, ES2017.object, ES2017.Intl, ES2017.SharedMemory, ES2017.String, ES2017.TypedArrays, ES2018.Intl, ES2018.Promise, ES2018.RegExp, ES2019.Array, ES2019.Full, ES2019.Object, ES2019.String, ES2019.Symbol, ES2020.Full, ES2020.String, ES2020.Symbol.wellknown, ESNext.AsyncIterable, ESNext.Array, ESNext.Intl, ESNext.Symbol

moduleDetection

Module check.

  • auto (default): typescript will not only check import or export statements, but also check if package.json has a type field, and when the module value in the configuration file is nodenext or node16, the type field value is module. And check. When using the jsx: react-jsx configuration, whether the current file is a jsx file.

  • legacy: Checks if the file contains import or export statements.

  • force: Ensures that every non-declaration file is considered a module.

noLib

Disables automatic inclusion of any library files. If this option is set, lib will be ignored.

reactNamespace

Deprecated, use `jsxFactory instead

target

Compile target

Modern browsers support all ES6 features, so ES6 is a good choice. You can choose to set a lower target if your code is deployed in an old environment, or a higher target if your code is guaranteed to run in a new environment.

The target configuration will change which JS features are downgraded and which are kept intact. For example, if target is ES5 or lower, the arrow function () => this will be converted to the equivalent function expression.

Changing target will also change the default value of the lib option. You can mix and match target and lib configurations as needed, or you can just set target for convenience.

The special ESNext value represents the highest version of TypeScript that your TypeScript supports. This configuration should be used with caution, as it has different meanings between different TypeScript versions and can make upgrades less predictable.

Values: es3 (default), es5, es6/es2015, es2016, es2017, es2018, es2019, es2020, es2021, es2022, esnext

useDefineForClassFields

diagnostics

explainFiles

extendedDiagnostics

generateCpuProfile

listEmittedFiles

listFiles

traceResolution

composite

The composite option enforces certain constraints so that build tools (including TypeScript itself in --build mode) can quickly determine whether a project has been built.

When this setting is on:

  • If rootDir is not explicitly specified, it defaults to the directory containing the tsconfig.json file.

  • All implementation files must be matched by include or specified in the files array. If this constraint is violated, tsc will tell you which files are not specified.

  • declaration defaults to true.

disableReferencedProjectLoad

disableSolutionSearching

disableSourceOfProjectReferenceRedirect

incremental

Makes TypeScript save project information from the last compilation to a file on disk. This will create a series of .tsbuildinfo files in the same folder as your build output. They are not used by your JavaScript at runtime and can be safely deleted.

tsBuildInfoFile

This option allows you to specify a file to store incremental compilation information as part of a composite project, allowing for faster builds of larger TypeScript codebases.

This option provides a way to configure TypeScript to track the location of the files it stores on disk to indicate the build status of your project - by default, they are in the same folder as your generated JavaScript.

noErrorTruncation

When enabled, error messages are not truncated.

preserveWatchOutput

Whether to preserve history watch messages in the console, rather than flushing them.

pretty

Whether to format output messages using colors and styles.

skipDefaultLibCheck

Use skipLibCheck for this configuration.

skipLibCheck

Skip type checking of declaration files.

This can save time during compilation, but at the expense of type system accuracy. For example, two libraries could define two copies of the same type in inconsistent ways. TypeScript does not perform a comprehensive check on all d.ts files, but only on code that you specifically reference in your app's source code.

assumeChangesOnlyAffectDirectDependencies

When this option is enabled, TypeScript will avoid rechecking/rebuilding all files that might actually be affected, and only check/rebuild files that have changed and files that directly import those files.

This can be thought of as a "fast and loose" implementation of the watch algorithm, which can drastically reduce incremental rebuild times, at the expense of having to occasionally run a full build to get all compiler error messages.

files

Typesstring[]

Explicitly specify a list of files to compile.

If a file in the list does not exist, an error will occur.

example

{
  "files": ["main.ts", "core.ts", "shared.ts", "utils.ts"]
}

include

Type: string[]

Specify a list of files to compile, which can be a directory, file, or pattern matching. These file paths are resolved relative to the directory containing tsconfig.json.

example

{
  "include": ["src/**/*.ts", "test/**/*.ts"]
}

It will match:

.
├── scripts
 ├── lint.ts
 ├── update_deps.ts
 └── utils.ts
├── src
 ├── client
 ├── index.ts
 └── utils.ts
 ├── server
 └── index.ts
├── tests
 ├── app.test.ts
 ├── utils.ts
 └── tests.d.ts
├── package.json
├── tsconfig.json
└── yarn.lock

patterns

include and exclude support wildcard pattern matching:

  • * matches zero to multiple characters (excluding directory separators)

  • ? matches any one character (excluding directory separators)

  • **/ matches directories of any nesting depth

exclude

Type: string[]

Specifies a list of files that should be skipped when parsing files included by include. It can be a directory, file, or pattern match.

example

{
  "exclude": ["src/**/*.spec.ts"]
}

Tip: exclude only excludes files that have been included in the include setting. But sometimes even if exclude is configured to exclude a file, typescript will still compile it if the file is still imported using the import statement in the code, or included in types, or imported through /// <reference.

exclude is not a mechanism to prevent files from being included in the code organization, it only acts on include to exclude files when looking for files.

references

Type: { path: string }[]

Project references are a way to deconstruct TypeScript projects into smaller pieces.

Using project references can greatly improve build and editor interaction time, strengthen logical separation between components, and improve code organization in new ways.

watchOptions

Configure the behavior of the typescript compiler to watch files and directories.

When the compiler is enabled using the command line --watch, the compiler uses fs.watch and fs.watchFile to watch files and directories, but both methods have their pros and cons.

fs.watch uses file system events to notify about changes to files and directories. But it is OS dependent and the notifications are not reliable, it does not work properly on many OSes. In addition, it has a limit on the number of created watches, on some OSes like linux, we may exhaust it quickly for large projects with many files. But because it uses file system events, it does not consume too many CPU cycles. In the typescript compiler, fs.watch is used to watch directory changes that allow loss of precision (include of configuration files, or directories where module resolution fails).

But only Windows and OSX support recursive watching, which means that other methods are needed to support recursive watching on other systems.

fa.watchFile implements watching by polling, so it consumes more CPU cycles. But fs.watchFile is the most reliable way to get directory/file status updates. The compiler uses fs.watchFile to watch source files, configuration files, and missing file references.

{
  "watchOptions": {
    "watchFile": "",
    "watchDirectory": "",
    "fallbackPolling": "",
    "synchronousWatchDirectory": true,
    "excludeDirectories": [],
    "excludeFiles": []
  }
}

watchFile

Configures the strategy for watching a single file. The following optional values ​​are supported:

Description
fixedPollingIntervalCheck for file changes at a fixed interval multiple times per second
priorityPollingIntervalUse fs.watchFile to poll for file changes. But use different intervals for source files, configuration files, and missing files
dynamicPriorityPollingUse a dynamic queue to poll for file changes. Use shorter intervals for frequently changing files and longer intervals for infrequently changing files
useFsEvents defaultUse fs.watch(file system events) to monitor file changes (but may not work on some operating systems). Use fs.watchFile instead when the number of monitors allowed by the system is exceeded
useFsEventsOnParentDirectoryUse fs.watch(file system events) to monitor changes in the parent directory of the file, with lower accuracy

watchDirectory

Configures a strategy for monitoring the entire directory on systems that lack recursive file monitoring. Supports the following optional values:

Description
fixedPollingIntervalCheck all directory changes multiple times per second at a fixed interval
dynamicPriorityPollingUse a dynamic queue to poll and check directory changes. Use shorter intervals for frequently changing directories, longer intervals for less frequently changing directories
useFsEvents defaultUse fs.watch(file system events) to watch for directory changes (but may not work on some operating systems)

fallbackPolling

When using file system events, this option specifies the polling strategy to use when the system runs out of native file watchers and/or does not support native file watchers.

Description
fixedPollingIntervalCheck for file changes at a fixed interval multiple times per second
priorityPollingIntervalUse fs.watchFile to poll for file changes. But use different intervals for source files, configuration files, and missing files
dynamicPriorityPollingUse a dynamic queue to poll for file changes. Use shorter intervals for frequently changing files, longer intervals for less frequently changing files
synchronousWatchDirectoryDisables lazy watching of a directory. Lazy watching is useful when a lot of file changes may happen at once (e.g. running npm install causes node_modules to change), but in some less common setups you may want to disable it with this flag.

synchronousWatchDirectory

Synchronously calls callback and updates the state of the directory watcher on platforms that don't support native recursive watching. Instead of giving a small timeout to allow for multiple edits that may have happened on a file.

{
  "watchOptions": {
    "synchronousWatchDirectory": true
  }
}

excludeDirectories

Type: string[]

Configure directories that do not need to be watched. This configuration can reduce the number of files that need to be watched.

excludeFiles

Type: string[]

Configure files that do not need to be watched. This configuration can reduce the number of files that need to be watched.

typeAcquisition

Points to the behavior of type acquisition in the project.

Type acquisition is only important in javascript. In javascript projects, the typescript tool will download type declarations for modules in the background or outside of node_modules.

In typescript projects, you need to explicitly specify the types to include in the project.

{
  "typeAcquisition": {
    "enable": true,
    "include": [],
    "exclude": [],
    "disableFilenameBasedTypeAcquisition": true
  }
}

enable

Specifies whether type acquisition is enabled in javascript projects.

include

Explicitly declares the types of dependencies that need to be included. Useful in javascript projects to help typescript tools understand dependency tracking, or to add dependencies manually when disableFilenameBasedTypeAcquisition is set to true.

example

"typeAcquisition": {
"include": ["lodash"],
}
}

exclude

Disable type acquisition for certain modules, which is useful for projects that include additional libraries in the test infrastructure that are not needed by the main application.

example

"typeAcquisition": {
"exclude": ["jest", "mocha"],
}
}

disableFilenameBasedTypeAcquisition

TypeScript type acquisition can infer what types should be added based on the file names in the project. This means having a file like JQuery in your project will automatically download typings for JQuery from DefinitelyTyped.