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
undefined
default provides suggestions to the editor as warningstrue
allows inclusionfalse
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 warningstrue
allows inclusionfalse
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 modern
JavaScriptconcept of iterators on older
Javascript` 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
TypeScript
accurately implements theES6
module specification, most libraries usingCommonJS/AMD/UMD
modules 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.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:
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):typescript
will not only checkimport
orexport
statements, but also check ifpackage.json
has atype
field, and when themodule
value in the configuration file isnodenext
ornode16
, thetype
field value ismodule
. And check. When using thejsx: react-jsx
configuration, whether the current file is ajsx
file.legacy
: Checks if the file containsimport
orexport
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 thetsconfig.json
file.All implementation files must be matched by
include
or specified in thefiles
array. If this constraint is violated,tsc
will tell you which files are not specified.declaration
defaults 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.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 | |
---|---|
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
.