tsconfig.json Complete Usage Guide
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.
Basics
Using TSConfig is very easy. Just create a tsconfig.json or jsconfig.json file in the directory:
{}{}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:
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
undefineddefault provides suggestions to the editor as warningstrueallows inclusionfalsedoes 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.
undefineddefault provides suggestions to the editor as warningstrueallows inclusionfalsedoes 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 // errornoFallthroughCasesInSwitch
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 toconst moment = require("moment")Default imports like
import moment from "moment"are equivalent toconst 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
TypeScriptaccurately implements theES6module specification, most libraries usingCommonJS/AMD/UMDmodules do not follow it as strictly asTypeScript.
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 toReact.createElementand generate .js files.react-jsx: call__jsxinstead and generate .js files.react-jsxdev: call__jsxinstead 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:
| Name | Content |
|---|---|
| ES5 | Core functionality of ES3 and ES5 |
| ES2015 | Additional APIs in ES2015 (also known as ES6) - array.find, Promise, Proxy, Symbol, Map, Set, Reflect, etc. |
| ES6 | Alias for ES2015. |
| ES2016 | Additional APIs in ES2016 - array.include, etc. |
| ES7 | Alias for ES2016. |
| ES2017 | Additional APIs in ES2017 - Object.entries, Object.values, Atomics, SharedArrayBuffer, date.formatToParts, typed arrays, etc. |
| ES2018 | Additional APIs in ES2018 — async iterables, promise.finally, Intl.PluralRules, rexexp.groups, etc. |
| ES2019 | Additional APIs in ES2019 — array.flat, array.flatMap, Object.fromEntries, string.trimStart, string.trimEnd, etc. |
| ES2020 | Additional APIs in ES2020 — string.matchAll, etc. |
| ESNext | Additional APIs in ESNext — these will change as JavaScript evolves. |
| DOM | DOM definitions — window, document, etc. |
| WebWorker | APIs that exist in the context of a WebWorker. |
| ScriptHost | APIs 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):typescriptwill not only checkimportorexportstatements, but also check ifpackage.jsonhas atypefield, and when themodulevalue in the configuration file isnodenextornode16, thetypefield value ismodule. And check. When using thejsx: react-jsxconfiguration, whether the current file is ajsxfile.legacy: Checks if the file containsimportorexportstatements.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
rootDiris not explicitly specified, it defaults to the directory containing thetsconfig.jsonfile.All implementation files must be matched by
includeor specified in thefilesarray. If this constraint is violated,tscwill tell you which files are not specified.declarationdefaults totrue.
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
Types: string[]
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.lockpatterns
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 | |
|---|---|
fixedPollingInterval | Check for file changes at a fixed interval multiple times per second |
priorityPollingInterval | Use fs.watchFile to poll for file changes. But use different intervals for source files, configuration files, and missing files |
dynamicPriorityPolling | Use a dynamic queue to poll for file changes. Use shorter intervals for frequently changing files and longer intervals for infrequently changing files |
useFsEvents default | Use 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 |
useFsEventsOnParentDirectory | Use 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 | |
|---|---|
fixedPollingInterval | Check all directory changes multiple times per second at a fixed interval |
dynamicPriorityPolling | Use a dynamic queue to poll and check directory changes. Use shorter intervals for frequently changing directories, longer intervals for less frequently changing directories |
useFsEvents default | Use 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 | |
|---|---|
fixedPollingInterval | Check for file changes at a fixed interval multiple times per second |
priorityPollingInterval | Use fs.watchFile to poll for file changes. But use different intervals for source files, configuration files, and missing files |
dynamicPriorityPolling | Use a dynamic queue to poll for file changes. Use shorter intervals for frequently changing files, longer intervals for less frequently changing files |
synchronousWatchDirectory | Disables 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.
