{

"$schema": "http://json-schema.org/draft-04/schema#",

"$comment": "Note that this schema uses 'null' in various places. The value of 'null' is UNDOCUMENTED (https://github.com/microsoft/TypeScript/pull/18058)",

"allowTrailingCommas": true,

"allOf": [

{

"$ref": "#/definitions/compilerOptionsDefinition"

},

{

"$ref": "#/definitions/compileOnSaveDefinition"

},

{

"$ref": "#/definitions/typeAcquisitionDefinition"

},

{

"$ref": "#/definitions/extendsDefinition"

},

{

"$ref": "#/definitions/watchOptionsDefinition"

},

{

"$ref": "#/definitions/buildOptionsDefinition"

},

{

"$ref": "#/definitions/tsNodeDefinition"

},

{

"anyOf": [

{

"$ref": "#/definitions/filesDefinition"

},

{

"$ref": "#/definitions/excludeDefinition"

},

{

"$ref": "#/definitions/includeDefinition"

},

{

"$ref": "#/definitions/referencesDefinition"

}

]

}

],

"definitions": {

"//": {

"explainer": "https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#overview",

"reference": "https://www.typescriptlang.org/tsconfig",

"reference metadata": "https://github.com/microsoft/TypeScript-Website/blob/v2/packages/tsconfig-reference/scripts/tsconfigRules.ts"

},

"filesDefinition": {

"properties": {

"files": {

"description": "If no 'files' or 'include' property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by 'exclude'. When a 'files' property is specified, only those files and those specified by 'include' are included.\n\n---\n\nSpecifies an allowlist of files to include in the program. An error occurs if any of the files can't be found.\n\n```json tsconfig\n{\n \"compilerOptions\": {},\n \"files\": [\n \"core.ts\",\n \"sys.ts\",\n \"types.ts\",\n \"scanner.ts\",\n \"parser.ts\",\n \"utilities.ts\",\n \"binder.ts\",\n \"checker.ts\",\n \"tsc.ts\"\n ]\n}\n```\n\nThis is useful when you only have a small number of files and don't need to use a glob to reference many files.\nIf you need that then use [`include`](https://typescriptlang.org/tsconfig/#include).",

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string"

},

"markdownDescription": "If no 'files' or 'include' property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by 'exclude'. When a 'files' property is specified, only those files and those specified by 'include' are included.\n\n---\n\nSpecifies an allowlist of files to include in the program. An error occurs if any of the files can't be found.\n\n```json tsconfig\n{\n \"compilerOptions\": {},\n \"files\": [\n \"core.ts\",\n \"sys.ts\",\n \"types.ts\",\n \"scanner.ts\",\n \"parser.ts\",\n \"utilities.ts\",\n \"binder.ts\",\n \"checker.ts\",\n \"tsc.ts\"\n ]\n}\n```\n\nThis is useful when you only have a small number of files and don't need to use a glob to reference many files.\nIf you need that then use [`include`](https://typescriptlang.org/tsconfig/#include).",

"x-intellij-html-description": "<p>If no &#39;files&#39; or &#39;include&#39; property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by &#39;exclude&#39;. When a &#39;files&#39; property is specified, only those files and those specified by &#39;include&#39; are included.</p>\n<hr>\n<p>Specifies an allowlist of files to include in the program. An error occurs if any of the files can&#39;t be found.</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {},\n &quot;files&quot;: [\n &quot;core.ts&quot;,\n &quot;sys.ts&quot;,\n &quot;types.ts&quot;,\n &quot;scanner.ts&quot;,\n &quot;parser.ts&quot;,\n &quot;utilities.ts&quot;,\n &quot;binder.ts&quot;,\n &quot;checker.ts&quot;,\n &quot;tsc.ts&quot;\n ]\n}\n</code></pre>\n<p>This is useful when you only have a small number of files and don&#39;t need to use a glob to reference many files.\nIf you need that then use <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a>.</p>\n"

}

}

},

"excludeDefinition": {

"properties": {

"exclude": {

"description": "Specifies a list of files to be excluded from compilation. The 'exclude' property only affects the files included via the 'include' property and not the 'files' property. Glob patterns require TypeScript version 2.0 or later.\n\n---\n\nSpecifies an array of filenames or patterns that should be skipped when resolving [`include`](https://typescriptlang.org/tsconfig/#include).\n\n**Important**: `exclude` _only_ changes which files are included as a result of the [`include`](https://typescriptlang.org/tsconfig/#include) setting.\nA file specified by `exclude` can still become part of your codebase due to an `import` statement in your code, a `types` inclusion, a `/// <reference` directive, or being specified in the [`files`](https://typescriptlang.org/tsconfig/#files) list.\n\nIt is not a mechanism that **prevents** a file from being included in the codebase - it simply changes what the [`include`](https://typescriptlang.org/tsconfig/#include) setting finds.",

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string"

},

"markdownDescription": "Specifies a list of files to be excluded from compilation. The 'exclude' property only affects the files included via the 'include' property and not the 'files' property. Glob patterns require TypeScript version 2.0 or later.\n\n---\n\nSpecifies an array of filenames or patterns that should be skipped when resolving [`include`](https://typescriptlang.org/tsconfig/#include).\n\n**Important**: `exclude` _only_ changes which files are included as a result of the [`include`](https://typescriptlang.org/tsconfig/#include) setting.\nA file specified by `exclude` can still become part of your codebase due to an `import` statement in your code, a `types` inclusion, a `/// <reference` directive, or being specified in the [`files`](https://typescriptlang.org/tsconfig/#files) list.\n\nIt is not a mechanism that **prevents** a file from being included in the codebase - it simply changes what the [`include`](https://typescriptlang.org/tsconfig/#include) setting finds.",

"x-intellij-html-description": "<p>Specifies a list of files to be excluded from compilation. The &#39;exclude&#39; property only affects the files included via the &#39;include&#39; property and not the &#39;files&#39; property. Glob patterns require TypeScript version 2.0 or later.</p>\n<hr>\n<p>Specifies an array of filenames or patterns that should be skipped when resolving <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a>.</p>\n<p><strong>Important</strong>: <code>exclude</code> <em>only</em> changes which files are included as a result of the <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a> setting.\nA file specified by <code>exclude</code> can still become part of your codebase due to an <code>import</code> statement in your code, a <code>types</code> inclusion, a <code>/// &lt;reference</code> directive, or being specified in the <a href=\"https://typescriptlang.org/tsconfig/#files\"><code>files</code></a> list.</p>\n<p>It is not a mechanism that <strong>prevents</strong> a file from being included in the codebase - it simply changes what the <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a> setting finds.</p>\n"

}

}

},

"includeDefinition": {

"properties": {

"include": {

"description": "Specifies a list of glob patterns that match files to be included in compilation. If no 'files' or 'include' property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by 'exclude'. Requires TypeScript version 2.0 or later.\n\n---\n\nSpecifies an array of filenames or patterns to include in the program.\nThese filenames are resolved relative to the directory containing the `tsconfig.json` file.\n\n```json\n{\n \"include\": [\"src/**/*\", \"tests/**/*\"]\n}\n```\n\nWhich would include:\n\n<!-- TODO: #135\n```diff\n .\n- ├── scripts\n- │ ├── lint.ts\n- │ ├── update_deps.ts\n- │ └── utils.ts\n+ ├── src\n+ │ ├── client\n+ │ │ ├── index.ts\n+ │ │ └── utils.ts\n+ │ ├── server\n+ │ │ └── index.ts\n+ ├── tests\n+ │ ├── app.test.ts\n+ │ ├── utils.ts\n+ │ └── tests.d.ts\n- ├── package.json\n- ├── tsconfig.json\n- └── yarn.lock\n``` -->\n\n```\n.\n├── scripts ⨯\n│ ├── lint.ts ⨯\n│ ├── update_deps.ts ⨯\n│ └── utils.ts ⨯\n├── src ✓\n│ ├── client ✓\n│ │ ├── index.ts ✓\n│ │ └── utils.ts ✓\n│ ├── server ✓\n│ │ └── index.ts ✓\n├── tests ✓\n│ ├── app.test.ts ✓\n│ ├── utils.ts ✓\n│ └── tests.d.ts ✓\n├── package.json\n├── tsconfig.json\n└── yarn.lock\n```\n\n`include` and `exclude` support wildcard characters to make glob patterns:\n\n- `*` matches zero or more characters (excluding directory separators)\n- `?` matches any one character (excluding directory separators)\n- `**/` matches any directory nested to any level\n\nIf the last path segment in a pattern does not contain a file extension or wildcard character, then it is treated as a directory, and files with supported extensions inside that directory are included (e.g. `.ts`, `.tsx`, and `.d.ts` by default, with `.js` and `.jsx` if [`allowJs`](https://typescriptlang.org/tsconfig/#allowJs) is set to true).",

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string"

},

"markdownDescription": "Specifies a list of glob patterns that match files to be included in compilation. If no 'files' or 'include' property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by 'exclude'. Requires TypeScript version 2.0 or later.\n\n---\n\nSpecifies an array of filenames or patterns to include in the program.\nThese filenames are resolved relative to the directory containing the `tsconfig.json` file.\n\n```json\n{\n \"include\": [\"src/**/*\", \"tests/**/*\"]\n}\n```\n\nWhich would include:\n\n<!-- TODO: #135\n```diff\n .\n- ├── scripts\n- │ ├── lint.ts\n- │ ├── update_deps.ts\n- │ └── utils.ts\n+ ├── src\n+ │ ├── client\n+ │ │ ├── index.ts\n+ │ │ └── utils.ts\n+ │ ├── server\n+ │ │ └── index.ts\n+ ├── tests\n+ │ ├── app.test.ts\n+ │ ├── utils.ts\n+ │ └── tests.d.ts\n- ├── package.json\n- ├── tsconfig.json\n- └── yarn.lock\n``` -->\n\n```\n.\n├── scripts ⨯\n│ ├── lint.ts ⨯\n│ ├── update_deps.ts ⨯\n│ └── utils.ts ⨯\n├── src ✓\n│ ├── client ✓\n│ │ ├── index.ts ✓\n│ │ └── utils.ts ✓\n│ ├── server ✓\n│ │ └── index.ts ✓\n├── tests ✓\n│ ├── app.test.ts ✓\n│ ├── utils.ts ✓\n│ └── tests.d.ts ✓\n├── package.json\n├── tsconfig.json\n└── yarn.lock\n```\n\n`include` and `exclude` support wildcard characters to make glob patterns:\n\n- `*` matches zero or more characters (excluding directory separators)\n- `?` matches any one character (excluding directory separators)\n- `**/` matches any directory nested to any level\n\nIf the last path segment in a pattern does not contain a file extension or wildcard character, then it is treated as a directory, and files with supported extensions inside that directory are included (e.g. `.ts`, `.tsx`, and `.d.ts` by default, with `.js` and `.jsx` if [`allowJs`](https://typescriptlang.org/tsconfig/#allowJs) is set to true).",

"x-intellij-html-description": "<p>Specifies a list of glob patterns that match files to be included in compilation. If no &#39;files&#39; or &#39;include&#39; property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by &#39;exclude&#39;. Requires TypeScript version 2.0 or later.</p>\n<hr>\n<p>Specifies an array of filenames or patterns to include in the program.\nThese filenames are resolved relative to the directory containing the <code>tsconfig.json</code> file.</p>\n<pre><code class=\"language-json\">{\n &quot;include&quot;: [&quot;src/**/*&quot;, &quot;tests/**/*&quot;]\n}\n</code></pre>\n<p>Which would include:</p>\n<!-- TODO: #135\n```diff\n .\n- ├── scripts\n- │ ├── lint.ts\n- │ ├── update_deps.ts\n- │ └── utils.ts\n+ ├── src\n+ │ ├── client\n+ │ │ ├── index.ts\n+ │ │ └── utils.ts\n+ │ ├── server\n+ │ │ └── index.ts\n+ ├── tests\n+ │ ├── app.test.ts\n+ │ ├── utils.ts\n+ │ └── tests.d.ts\n- ├── package.json\n- ├── tsconfig.json\n- └── yarn.lock\n``` --><pre><code>.\n├── scripts ⨯\n│ ├── lint.ts ⨯\n│ ├── update_deps.ts ⨯\n│ └── utils.ts ⨯\n├── src ✓\n│ ├── client ✓\n│ │ ├── index.ts ✓\n│ │ └── utils.ts ✓\n│ ├── server ✓\n│ │ └── index.ts ✓\n├── tests ✓\n│ ├── app.test.ts ✓\n│ ├── utils.ts ✓\n│ └── tests.d.ts ✓\n├── package.json\n├── tsconfig.json\n└── yarn.lock\n</code></pre>\n<p><code>include</code> and <code>exclude</code> support wildcard characters to make glob patterns:</p>\n<ul>\n<li><code>*</code> matches zero or more characters (excluding directory separators)</li>\n<li><code>?</code> matches any one character (excluding directory separators)</li>\n<li><code>**/</code> matches any directory nested to any level</li>\n</ul>\n<p>If the last path segment in a pattern does not contain a file extension or wildcard character, then it is treated as a directory, and files with supported extensions inside that directory are included (e.g. <code>.ts</code>, <code>.tsx</code>, and <code>.d.ts</code> by default, with <code>.js</code> and <code>.jsx</code> if <a href=\"https://typescriptlang.org/tsconfig/#allowJs\"><code>allowJs</code></a> is set to true).</p>\n"

}

}

},

"compileOnSaveDefinition": {

"properties": {

"compileOnSave": {

"description": "Enable Compile-on-Save for this project.",

"type": ["boolean", "null"]

}

}

},

"extendsDefinition": {

"properties": {

"extends": {

"description": "Path to base configuration file to inherit from. Requires TypeScript version 2.1 or later.\n\n---\n\nThe value of `extends` is a string which contains a path to another configuration file to inherit from.\nThe path may use Node.js style resolution.\n\nThe configuration from the base file are loaded first, then overridden by those in the inheriting config file. All relative paths found in the configuration file will be resolved relative to the configuration file they originated in.\n\nIt's worth noting that [`files`](https://typescriptlang.org/tsconfig/#files), [`include`](https://typescriptlang.org/tsconfig/#include), and [`exclude`](https://typescriptlang.org/tsconfig/#exclude) from the inheriting config file _overwrite_ those from the\nbase config file, and that circularity between configuration files is not allowed.\n\nCurrently, the only top-level property that is excluded from inheritance is [`references`](https://typescriptlang.org/tsconfig/#references).\n\n##### Example\n\n`configs/base.json`:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"noImplicitAny\": true,\n \"strictNullChecks\": true\n }\n}\n```\n\n`tsconfig.json`:\n\n```json tsconfig\n{\n \"extends\": \"./configs/base\",\n \"files\": [\"main.ts\", \"supplemental.ts\"]\n}\n```\n\n`tsconfig.nostrictnull.json`:\n\n```json tsconfig\n{\n \"extends\": \"./tsconfig\",\n \"compilerOptions\": {\n \"strictNullChecks\": false\n }\n}\n```\n\nProperties with relative paths found in the configuration file, which aren't excluded from inheritance, will be resolved relative to the configuration file they originated in.",

"oneOf": [

{

"default": "",

"type": "string"

},

{

"default": [],

"items": {

"type": "string"

},

"type": "array"

}

],

"markdownDescription": "Path to base configuration file to inherit from. Requires TypeScript version 2.1 or later.\n\n---\n\nThe value of `extends` is a string which contains a path to another configuration file to inherit from.\nThe path may use Node.js style resolution.\n\nThe configuration from the base file are loaded first, then overridden by those in the inheriting config file. All relative paths found in the configuration file will be resolved relative to the configuration file they originated in.\n\nIt's worth noting that [`files`](https://typescriptlang.org/tsconfig/#files), [`include`](https://typescriptlang.org/tsconfig/#include), and [`exclude`](https://typescriptlang.org/tsconfig/#exclude) from the inheriting config file _overwrite_ those from the\nbase config file, and that circularity between configuration files is not allowed.\n\nCurrently, the only top-level property that is excluded from inheritance is [`references`](https://typescriptlang.org/tsconfig/#references).\n\n##### Example\n\n`configs/base.json`:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"noImplicitAny\": true,\n \"strictNullChecks\": true\n }\n}\n```\n\n`tsconfig.json`:\n\n```json tsconfig\n{\n \"extends\": \"./configs/base\",\n \"files\": [\"main.ts\", \"supplemental.ts\"]\n}\n```\n\n`tsconfig.nostrictnull.json`:\n\n```json tsconfig\n{\n \"extends\": \"./tsconfig\",\n \"compilerOptions\": {\n \"strictNullChecks\": false\n }\n}\n```\n\nProperties with relative paths found in the configuration file, which aren't excluded from inheritance, will be resolved relative to the configuration file they originated in.",

"x-intellij-html-description": "<p>Path to base configuration file to inherit from. Requires TypeScript version 2.1 or later.</p>\n<hr>\n<p>The value of <code>extends</code> is a string which contains a path to another configuration file to inherit from.\nThe path may use Node.js style resolution.</p>\n<p>The configuration from the base file are loaded first, then overridden by those in the inheriting config file. All relative paths found in the configuration file will be resolved relative to the configuration file they originated in.</p>\n<p>It&#39;s worth noting that <a href=\"https://typescriptlang.org/tsconfig/#files\"><code>files</code></a>, <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a>, and <a href=\"https://typescriptlang.org/tsconfig/#exclude\"><code>exclude</code></a> from the inheriting config file <em>overwrite</em> those from the\nbase config file, and that circularity between configuration files is not allowed.</p>\n<p>Currently, the only top-level property that is excluded from inheritance is <a href=\"https://typescriptlang.org/tsconfig/#references\"><code>references</code></a>.</p>\n<h5>Example</h5>\n<p><code>configs/base.json</code>:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;noImplicitAny&quot;: true,\n &quot;strictNullChecks&quot;: true\n }\n}\n</code></pre>\n<p><code>tsconfig.json</code>:</p>\n<pre><code class=\"language-json\">{\n &quot;extends&quot;: &quot;./configs/base&quot;,\n &quot;files&quot;: [&quot;main.ts&quot;, &quot;supplemental.ts&quot;]\n}\n</code></pre>\n<p><code>tsconfig.nostrictnull.json</code>:</p>\n<pre><code class=\"language-json\">{\n &quot;extends&quot;: &quot;./tsconfig&quot;,\n &quot;compilerOptions&quot;: {\n &quot;strictNullChecks&quot;: false\n }\n}\n</code></pre>\n<p>Properties with relative paths found in the configuration file, which aren&#39;t excluded from inheritance, will be resolved relative to the configuration file they originated in.</p>\n"

}

}

},

"buildOptionsDefinition": {

"properties": {

"buildOptions": {

"properties": {

"dry": {

"description": "~",

"type": ["boolean", "null"],

"default": false

},

"force": {

"description": "Build all projects, including those that appear to be up to date",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Build all projects, including those that appear to be up to date",

"x-intellij-html-description": "<p>Build all projects, including those that appear to be up to date</p>\n"

},

"verbose": {

"description": "Enable verbose logging",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Enable verbose logging",

"x-intellij-html-description": "<p>Enable verbose logging</p>\n"

},

"incremental": {

"description": "Tells TypeScript to save information about the project graph from the last compilation to files stored on disk. This\ncreates a series of `.tsbuildinfo` files in the same folder as your compilation output. They are not used by your\nJavaScript at runtime and can be safely deleted. You can read more about the flag in the [3.4 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#faster-subsequent-builds-with-the---incremental-flag).\n\nTo control which folders you want to the files to be built to, use the config option [`tsBuildInfoFile`](https://typescriptlang.org/tsconfig/#tsBuildInfoFile).",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Tells TypeScript to save information about the project graph from the last compilation to files stored on disk. This\ncreates a series of `.tsbuildinfo` files in the same folder as your compilation output. They are not used by your\nJavaScript at runtime and can be safely deleted. You can read more about the flag in the [3.4 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#faster-subsequent-builds-with-the---incremental-flag).\n\nTo control which folders you want to the files to be built to, use the config option [`tsBuildInfoFile`](https://typescriptlang.org/tsconfig/#tsBuildInfoFile).",

"x-intellij-html-description": "<p>Tells TypeScript to save information about the project graph from the last compilation to files stored on disk. This\ncreates a series of <code>.tsbuildinfo</code> files in the same folder as your compilation output. They are not used by your\nJavaScript at runtime and can be safely deleted. You can read more about the flag in the <a href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#faster-subsequent-builds-with-the---incremental-flag\">3.4 release notes</a>.</p>\n<p>To control which folders you want to the files to be built to, use the config option <a href=\"https://typescriptlang.org/tsconfig/#tsBuildInfoFile\"><code>tsBuildInfoFile</code></a>.</p>\n"

},

"assumeChangesOnlyAffectDirectDependencies": {

"description": "When this option is enabled, TypeScript will avoid rechecking/rebuilding all truly possibly-affected files, and only recheck/rebuild files that have changed as well as files that directly import them.\n\nThis can be considered a 'fast & loose' implementation of the watching algorithm, which can drastically reduce incremental rebuild times at the expense of having to run the full build occasionally to get all compiler error messages.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "When this option is enabled, TypeScript will avoid rechecking/rebuilding all truly possibly-affected files, and only recheck/rebuild files that have changed as well as files that directly import them.\n\nThis can be considered a 'fast & loose' implementation of the watching algorithm, which can drastically reduce incremental rebuild times at the expense of having to run the full build occasionally to get all compiler error messages.",

"x-intellij-html-description": "<p>When this option is enabled, TypeScript will avoid rechecking/rebuilding all truly possibly-affected files, and only recheck/rebuild files that have changed as well as files that directly import them.</p>\n<p>This can be considered a &#39;fast &amp; loose&#39; implementation of the watching algorithm, which can drastically reduce incremental rebuild times at the expense of having to run the full build occasionally to get all compiler error messages.</p>\n"

},

"traceResolution": {

"description": "When you are trying to debug why a module isn't being included.\nYou can set `traceResolution` to `true` to have TypeScript print information about its resolution process for each processed file.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "When you are trying to debug why a module isn't being included.\nYou can set `traceResolution` to `true` to have TypeScript print information about its resolution process for each processed file.",

"x-intellij-html-description": "<p>When you are trying to debug why a module isn&#39;t being included.\nYou can set <code>traceResolution</code> to <code>true</code> to have TypeScript print information about its resolution process for each processed file.</p>\n"

}

}

}

}

},

"watchOptionsDefinition": {

"properties": {

"watchOptions": {

"type": ["object", "null"],

"description": "Settings for the watch mode in TypeScript.",

"properties": {

"force": {

"description": "~",

"type": ["string", "null"]

},

"watchFile": {

"description": "The strategy for how individual files are watched.\n\n- `fixedPollingInterval`: Check every file for changes several times a second at a fixed interval.\n- `priorityPollingInterval`: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified files will be checked less often.\n- `useFsEvents` (the default): Attempt to use the operating system/file system's native events for file changes.\n- `useFsEventsOnParentDirectory`: Attempt to use the operating system/file system's native events to listen for changes on a file's parent directory",

"type": ["string", "null"],

"markdownDescription": "The strategy for how individual files are watched.\n\n- `fixedPollingInterval`: Check every file for changes several times a second at a fixed interval.\n- `priorityPollingInterval`: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified files will be checked less often.\n- `useFsEvents` (the default): Attempt to use the operating system/file system's native events for file changes.\n- `useFsEventsOnParentDirectory`: Attempt to use the operating system/file system's native events to listen for changes on a file's parent directory",

"x-intellij-html-description": "<p>The strategy for how individual files are watched.</p>\n<ul>\n<li><code>fixedPollingInterval</code>: Check every file for changes several times a second at a fixed interval.</li>\n<li><code>priorityPollingInterval</code>: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.</li>\n<li><code>dynamicPriorityPolling</code>: Use a dynamic queue where less-frequently modified files will be checked less often.</li>\n<li><code>useFsEvents</code> (the default): Attempt to use the operating system/file system&#39;s native events for file changes.</li>\n<li><code>useFsEventsOnParentDirectory</code>: Attempt to use the operating system/file system&#39;s native events to listen for changes on a file&#39;s parent directory</li>\n</ul>\n"

},

"watchDirectory": {

"description": "The strategy for how entire directory trees are watched under systems that lack recursive file-watching functionality.\n\n- `fixedPollingInterval`: Check every directory for changes several times a second at a fixed interval.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified directories will be checked less often.\n- `useFsEvents` (the default): Attempt to use the operating system/file system's native events for directory changes.",

"type": ["string", "null"],

"markdownDescription": "The strategy for how entire directory trees are watched under systems that lack recursive file-watching functionality.\n\n- `fixedPollingInterval`: Check every directory for changes several times a second at a fixed interval.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified directories will be checked less often.\n- `useFsEvents` (the default): Attempt to use the operating system/file system's native events for directory changes.",

"x-intellij-html-description": "<p>The strategy for how entire directory trees are watched under systems that lack recursive file-watching functionality.</p>\n<ul>\n<li><code>fixedPollingInterval</code>: Check every directory for changes several times a second at a fixed interval.</li>\n<li><code>dynamicPriorityPolling</code>: Use a dynamic queue where less-frequently modified directories will be checked less often.</li>\n<li><code>useFsEvents</code> (the default): Attempt to use the operating system/file system&#39;s native events for directory changes.</li>\n</ul>\n"

},

"fallbackPolling": {

"description": "When using file system events, this option specifies the polling strategy that gets used when the system runs out of native file watchers and/or doesn't support native file watchers.\n\n- `fixedPollingInterval`: Check every file for changes several times a second at a fixed interval.\n- `priorityPollingInterval`: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified files will be checked less often.\n- `synchronousWatchDirectory`: Disable deferred watching on directories. Deferred watching is useful when lots of file changes might occur at once (e.g. a change in `node_modules` from running `npm install`), but you might want to disable it with this flag for some less-common setups.",

"type": ["string", "null"],

"markdownDescription": "When using file system events, this option specifies the polling strategy that gets used when the system runs out of native file watchers and/or doesn't support native file watchers.\n\n- `fixedPollingInterval`: Check every file for changes several times a second at a fixed interval.\n- `priorityPollingInterval`: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified files will be checked less often.\n- `synchronousWatchDirectory`: Disable deferred watching on directories. Deferred watching is useful when lots of file changes might occur at once (e.g. a change in `node_modules` from running `npm install`), but you might want to disable it with this flag for some less-common setups.",

"x-intellij-html-description": "<p>When using file system events, this option specifies the polling strategy that gets used when the system runs out of native file watchers and/or doesn&#39;t support native file watchers.</p>\n<ul>\n<li><code>fixedPollingInterval</code>: Check every file for changes several times a second at a fixed interval.</li>\n<li><code>priorityPollingInterval</code>: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.</li>\n<li><code>dynamicPriorityPolling</code>: Use a dynamic queue where less-frequently modified files will be checked less often.</li>\n<li><code>synchronousWatchDirectory</code>: Disable deferred watching on directories. Deferred watching is useful when lots of file changes might occur at once (e.g. a change in <code>node_modules</code> from running <code>npm install</code>), but you might want to disable it with this flag for some less-common setups.</li>\n</ul>\n"

},

"synchronousWatchDirectory": {

"description": "Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively. Instead of giving a small timeout to allow for potentially multiple edits to occur on a file.\n\n```json tsconfig\n{\n \"watchOptions\": {\n \"synchronousWatchDirectory\": true\n }\n}\n```",

"type": ["boolean", "null"],

"markdownDescription": "Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively. Instead of giving a small timeout to allow for potentially multiple edits to occur on a file.\n\n```json tsconfig\n{\n \"watchOptions\": {\n \"synchronousWatchDirectory\": true\n }\n}\n```",

"x-intellij-html-description": "<p>Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively. Instead of giving a small timeout to allow for potentially multiple edits to occur on a file.</p>\n<pre><code class=\"language-json\">{\n &quot;watchOptions&quot;: {\n &quot;synchronousWatchDirectory&quot;: true\n }\n}\n</code></pre>\n"

},

"excludeFiles": {

"description": "You can use `excludeFiles` to remove a set of specific files from the files which are watched.\n\n```json tsconfig\n{\n \"watchOptions\": {\n \"excludeFiles\": [\"temp/file.ts\"]\n }\n}\n```",

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string"

},

"markdownDescription": "You can use `excludeFiles` to remove a set of specific files from the files which are watched.\n\n```json tsconfig\n{\n \"watchOptions\": {\n \"excludeFiles\": [\"temp/file.ts\"]\n }\n}\n```",

"x-intellij-html-description": "<p>You can use <code>excludeFiles</code> to remove a set of specific files from the files which are watched.</p>\n<pre><code class=\"language-json\">{\n &quot;watchOptions&quot;: {\n &quot;excludeFiles&quot;: [&quot;temp/file.ts&quot;]\n }\n}\n</code></pre>\n"

},

"excludeDirectories": {

"description": "You can use [`excludeFiles`](https://typescriptlang.org/tsconfig/#excludeFiles) to drastically reduce the number of files which are watched during `--watch`. This can be a useful way to reduce the number of open file which TypeScript tracks on Linux.\n\n```json tsconfig\n{\n \"watchOptions\": {\n \"excludeDirectories\": [\"**/node_modules\", \"_build\", \"temp/*\"]\n }\n}\n```",

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string"

},

"markdownDescription": "You can use [`excludeFiles`](https://typescriptlang.org/tsconfig/#excludeFiles) to drastically reduce the number of files which are watched during `--watch`. This can be a useful way to reduce the number of open file which TypeScript tracks on Linux.\n\n```json tsconfig\n{\n \"watchOptions\": {\n \"excludeDirectories\": [\"**/node_modules\", \"_build\", \"temp/*\"]\n }\n}\n```",

"x-intellij-html-description": "<p>You can use <a href=\"https://typescriptlang.org/tsconfig/#excludeFiles\"><code>excludeFiles</code></a> to drastically reduce the number of files which are watched during <code>--watch</code>. This can be a useful way to reduce the number of open file which TypeScript tracks on Linux.</p>\n<pre><code class=\"language-json\">{\n &quot;watchOptions&quot;: {\n &quot;excludeDirectories&quot;: [&quot;**/node_modules&quot;, &quot;_build&quot;, &quot;temp/*&quot;]\n }\n}\n</code></pre>\n"

}

}

}

}

},

"compilerOptionsDefinition": {

"properties": {

"compilerOptions": {

"type": ["object", "null"],

"description": "Instructs the TypeScript compiler how to compile .ts files.",

"properties": {

"allowArbitraryExtensions": {

"description": "In TypeScript 5.0, when an import path ends in an extension that isn't a known JavaScript or TypeScript file extension, the compiler will look for a declaration file for that path in the form of `{file basename}.d.{extension}.ts`.\nFor example, if you are using a CSS loader in a bundler project, you might want to write (or generate) declaration files for those stylesheets:\n\n```css\n/* app.css */\n.cookie-banner {\n display: none;\n}\n```\n\n```ts\n// app.d.css.ts\ndeclare const css: {\n cookieBanner: string;\n};\nexport default css;\n```\n\n```ts\n// App.tsx\nimport styles from \"./app.css\";\n\nstyles.cookieBanner; // string\n```\n\nBy default, this import will raise an error to let you know that TypeScript doesn't understand this file type and your runtime might not support importing it.\nBut if you've configured your runtime or bundler to handle it, you can suppress the error with the new `--allowArbitraryExtensions` compiler option.\n\nNote that historically, a similar effect has often been achievable by adding a declaration file named `app.css.d.ts` instead of `app.d.css.ts` - however, this just worked through Node's `require` resolution rules for CommonJS.\nStrictly speaking, the former is interpreted as a declaration file for a JavaScript file named `app.css.js`.\nBecause relative files imports need to include extensions in Node's ESM support, TypeScript would error on our example in an ESM file under `--moduleResolution node16` or `nodenext`.\n\nFor more information, read up [the proposal for this feature](https://github.com/microsoft/TypeScript/issues/50133) and [its corresponding pull request](https://github.com/microsoft/TypeScript/pull/51435).",

"type": ["boolean", "null"],

"markdownDescription": "In TypeScript 5.0, when an import path ends in an extension that isn't a known JavaScript or TypeScript file extension, the compiler will look for a declaration file for that path in the form of `{file basename}.d.{extension}.ts`.\nFor example, if you are using a CSS loader in a bundler project, you might want to write (or generate) declaration files for those stylesheets:\n\n```css\n/* app.css */\n.cookie-banner {\n display: none;\n}\n```\n\n```ts\n// app.d.css.ts\ndeclare const css: {\n cookieBanner: string;\n};\nexport default css;\n```\n\n```ts\n// App.tsx\nimport styles from \"./app.css\";\n\nstyles.cookieBanner; // string\n```\n\nBy default, this import will raise an error to let you know that TypeScript doesn't understand this file type and your runtime might not support importing it.\nBut if you've configured your runtime or bundler to handle it, you can suppress the error with the new `--allowArbitraryExtensions` compiler option.\n\nNote that historically, a similar effect has often been achievable by adding a declaration file named `app.css.d.ts` instead of `app.d.css.ts` - however, this just worked through Node's `require` resolution rules for CommonJS.\nStrictly speaking, the former is interpreted as a declaration file for a JavaScript file named `app.css.js`.\nBecause relative files imports need to include extensions in Node's ESM support, TypeScript would error on our example in an ESM file under `--moduleResolution node16` or `nodenext`.\n\nFor more information, read up [the proposal for this feature](https://github.com/microsoft/TypeScript/issues/50133) and [its corresponding pull request](https://github.com/microsoft/TypeScript/pull/51435).",

"x-intellij-html-description": "<p>In TypeScript 5.0, when an import path ends in an extension that isn&#39;t a known JavaScript or TypeScript file extension, the compiler will look for a declaration file for that path in the form of <code>{file basename}.d.{extension}.ts</code>.\nFor example, if you are using a CSS loader in a bundler project, you might want to write (or generate) declaration files for those stylesheets:</p>\n<pre><code class=\"language-css\">/* app.css */\n.cookie-banner {\n display: none;\n}\n</code></pre>\n<pre><code class=\"language-ts\">// app.d.css.ts\ndeclare const css: {\n cookieBanner: string;\n};\nexport default css;\n</code></pre>\n<pre><code class=\"language-ts\">// App.tsx\nimport styles from &quot;./app.css&quot;;\n\nstyles.cookieBanner; // string\n</code></pre>\n<p>By default, this import will raise an error to let you know that TypeScript doesn&#39;t understand this file type and your runtime might not support importing it.\nBut if you&#39;ve configured your runtime or bundler to handle it, you can suppress the error with the new <code>--allowArbitraryExtensions</code> compiler option.</p>\n<p>Note that historically, a similar effect has often been achievable by adding a declaration file named <code>app.css.d.ts</code> instead of <code>app.d.css.ts</code> - however, this just worked through Node&#39;s <code>require</code> resolution rules for CommonJS.\nStrictly speaking, the former is interpreted as a declaration file for a JavaScript file named <code>app.css.js</code>.\nBecause relative files imports need to include extensions in Node&#39;s ESM support, TypeScript would error on our example in an ESM file under <code>--moduleResolution node16</code> or <code>nodenext</code>.</p>\n<p>For more information, read up <a href=\"https://github.com/microsoft/TypeScript/issues/50133\">the proposal for this feature</a> and <a href=\"https://github.com/microsoft/TypeScript/pull/51435\">its corresponding pull request</a>.</p>\n"

},

"allowImportingTsExtensions": {

"description": "`--allowImportingTsExtensions` allows TypeScript files to import each other with a TypeScript-specific extension like `.ts`, `.mts`, or `.tsx`.\n\nThis flag is only allowed when `--noEmit` or `--emitDeclarationOnly` is enabled, since these import paths would not be resolvable at runtime in JavaScript output files.\nThe expectation here is that your resolver (e.g. your bundler, a runtime, or some other tool) is going to make these imports between `.ts` files work.",

"type": ["boolean", "null"],

"markdownDescription": "`--allowImportingTsExtensions` allows TypeScript files to import each other with a TypeScript-specific extension like `.ts`, `.mts`, or `.tsx`.\n\nThis flag is only allowed when `--noEmit` or `--emitDeclarationOnly` is enabled, since these import paths would not be resolvable at runtime in JavaScript output files.\nThe expectation here is that your resolver (e.g. your bundler, a runtime, or some other tool) is going to make these imports between `.ts` files work.",

"x-intellij-html-description": "<p><code>--allowImportingTsExtensions</code> allows TypeScript files to import each other with a TypeScript-specific extension like <code>.ts</code>, <code>.mts</code>, or <code>.tsx</code>.</p>\n<p>This flag is only allowed when <code>--noEmit</code> or <code>--emitDeclarationOnly</code> is enabled, since these import paths would not be resolvable at runtime in JavaScript output files.\nThe expectation here is that your resolver (e.g. your bundler, a runtime, or some other tool) is going to make these imports between <code>.ts</code> files work.</p>\n"

},

"charset": {

"description": "In prior versions of TypeScript, this controlled what encoding was used when reading text files from disk.\nToday, TypeScript assumes UTF-8 encoding, but will correctly detect UTF-16 (BE and LE) or UTF-8 BOMs.",

"type": ["string", "null"],

"markdownDescription": "In prior versions of TypeScript, this controlled what encoding was used when reading text files from disk.\nToday, TypeScript assumes UTF-8 encoding, but will correctly detect UTF-16 (BE and LE) or UTF-8 BOMs.",

"x-intellij-html-description": "<p>In prior versions of TypeScript, this controlled what encoding was used when reading text files from disk.\nToday, TypeScript assumes UTF-8 encoding, but will correctly detect UTF-16 (BE and LE) or UTF-8 BOMs.</p>\n"

},

"composite": {

"description": "The `composite` option enforces certain constraints which make it possible for build tools (including TypeScript\nitself, under `--build` mode) to quickly determine if a project has been built yet.\n\nWhen this setting is on:\n\n- The [`rootDir`](https://typescriptlang.org/tsconfig/#rootDir) setting, if not explicitly set, defaults to the directory containing the `tsconfig.json` file.\n\n- All implementation files must be matched by an [`include`](https://typescriptlang.org/tsconfig/#include) pattern or listed in the [`files`](https://typescriptlang.org/tsconfig/#files) array. If this constraint is violated, `tsc` will inform you which files weren't specified.\n\n- [`declaration`](https://typescriptlang.org/tsconfig/#declaration) defaults to `true`\n\nYou can find documentation on TypeScript projects in [the handbook](https://www.typescriptlang.org/docs/handbook/project-references.html).",

"type": ["boolean", "null"],

"default": true,

"markdownDescription": "The `composite` option enforces certain constraints which make it possible for build tools (including TypeScript\nitself, under `--build` mode) to quickly determine if a project has been built yet.\n\nWhen this setting is on:\n\n- The [`rootDir`](https://typescriptlang.org/tsconfig/#rootDir) setting, if not explicitly set, defaults to the directory containing the `tsconfig.json` file.\n\n- All implementation files must be matched by an [`include`](https://typescriptlang.org/tsconfig/#include) pattern or listed in the [`files`](https://typescriptlang.org/tsconfig/#files) array. If this constraint is violated, `tsc` will inform you which files weren't specified.\n\n- [`declaration`](https://typescriptlang.org/tsconfig/#declaration) defaults to `true`\n\nYou can find documentation on TypeScript projects in [the handbook](https://www.typescriptlang.org/docs/handbook/project-references.html).",

"x-intellij-html-description": "<p>The <code>composite</code> option enforces certain constraints which make it possible for build tools (including TypeScript\nitself, under <code>--build</code> mode) to quickly determine if a project has been built yet.</p>\n<p>When this setting is on:</p>\n<ul>\n<li><p>The <a href=\"https://typescriptlang.org/tsconfig/#rootDir\"><code>rootDir</code></a> setting, if not explicitly set, defaults to the directory containing the <code>tsconfig.json</code> file.</p>\n</li>\n<li><p>All implementation files must be matched by an <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a> pattern or listed in the <a href=\"https://typescriptlang.org/tsconfig/#files\"><code>files</code></a> array. If this constraint is violated, <code>tsc</code> will inform you which files weren&#39;t specified.</p>\n</li>\n<li><p><a href=\"https://typescriptlang.org/tsconfig/#declaration\"><code>declaration</code></a> defaults to <code>true</code></p>\n</li>\n</ul>\n<p>You can find documentation on TypeScript projects in <a href=\"https://www.typescriptlang.org/docs/handbook/project-references.html\">the handbook</a>.</p>\n"

},

"customConditions": {

"description": "`--customConditions` takes a list of additional [conditions](https://nodejs.org/api/packages.html#nested-conditions) that should succeed when TypeScript resolves from an [`exports`](https://nodejs.org/api/packages.html#exports) or [`imports`](https://nodejs.org/api/packages.html#imports) field of a `package.json`.\nThese conditions are added to whatever existing conditions a resolver will use by default.\n\nFor example, when this field is set in a `tsconfig.json` as so:\n\n```jsonc\n{\n \"compilerOptions\": {\n \"target\": \"es2022\",\n \"moduleResolution\": \"bundler\",\n \"customConditions\": [\"my-condition\"]\n }\n}\n```\n\nAny time an `exports` or `imports` field is referenced in `package.json`, TypeScript will consider conditions called `my-condition`.\n\nSo when importing from a package with the following `package.json`\n\n```jsonc\n{\n // ...\n \"exports\": {\n \".\": {\n \"my-condition\": \"./foo.mjs\",\n \"node\": \"./bar.mjs\",\n \"import\": \"./baz.mjs\",\n \"require\": \"./biz.mjs\"\n }\n }\n}\n```\n\nTypeScript will try to look for files corresponding to `foo.mjs`.\n\nThis field is only valid under the `node16`, `nodenext`, and `bundler` options for [`--moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution).",

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string"

},

"markdownDescription": "`--customConditions` takes a list of additional [conditions](https://nodejs.org/api/packages.html#nested-conditions) that should succeed when TypeScript resolves from an [`exports`](https://nodejs.org/api/packages.html#exports) or [`imports`](https://nodejs.org/api/packages.html#imports) field of a `package.json`.\nThese conditions are added to whatever existing conditions a resolver will use by default.\n\nFor example, when this field is set in a `tsconfig.json` as so:\n\n```jsonc\n{\n \"compilerOptions\": {\n \"target\": \"es2022\",\n \"moduleResolution\": \"bundler\",\n \"customConditions\": [\"my-condition\"]\n }\n}\n```\n\nAny time an `exports` or `imports` field is referenced in `package.json`, TypeScript will consider conditions called `my-condition`.\n\nSo when importing from a package with the following `package.json`\n\n```jsonc\n{\n // ...\n \"exports\": {\n \".\": {\n \"my-condition\": \"./foo.mjs\",\n \"node\": \"./bar.mjs\",\n \"import\": \"./baz.mjs\",\n \"require\": \"./biz.mjs\"\n }\n }\n}\n```\n\nTypeScript will try to look for files corresponding to `foo.mjs`.\n\nThis field is only valid under the `node16`, `nodenext`, and `bundler` options for [`--moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution).",

"x-intellij-html-description": "<p><code>--customConditions</code> takes a list of additional <a href=\"https://nodejs.org/api/packages.html#nested-conditions\">conditions</a> that should succeed when TypeScript resolves from an <a href=\"https://nodejs.org/api/packages.html#exports\"><code>exports</code></a> or <a href=\"https://nodejs.org/api/packages.html#imports\"><code>imports</code></a> field of a <code>package.json</code>.\nThese conditions are added to whatever existing conditions a resolver will use by default.</p>\n<p>For example, when this field is set in a <code>tsconfig.json</code> as so:</p>\n<pre><code class=\"language-jsonc\">{\n &quot;compilerOptions&quot;: {\n &quot;target&quot;: &quot;es2022&quot;,\n &quot;moduleResolution&quot;: &quot;bundler&quot;,\n &quot;customConditions&quot;: [&quot;my-condition&quot;]\n }\n}\n</code></pre>\n<p>Any time an <code>exports</code> or <code>imports</code> field is referenced in <code>package.json</code>, TypeScript will consider conditions called <code>my-condition</code>.</p>\n<p>So when importing from a package with the following <code>package.json</code></p>\n<pre><code class=\"language-jsonc\">{\n // ...\n &quot;exports&quot;: {\n &quot;.&quot;: {\n &quot;my-condition&quot;: &quot;./foo.mjs&quot;,\n &quot;node&quot;: &quot;./bar.mjs&quot;,\n &quot;import&quot;: &quot;./baz.mjs&quot;,\n &quot;require&quot;: &quot;./biz.mjs&quot;\n }\n }\n}\n</code></pre>\n<p>TypeScript will try to look for files corresponding to <code>foo.mjs</code>.</p>\n<p>This field is only valid under the <code>node16</code>, <code>nodenext</code>, and <code>bundler</code> options for <a href=\"https://typescriptlang.org/tsconfig/#moduleResolution\"><code>--moduleResolution</code></a>.</p>\n"

},

"declaration": {

"description": "Generate `.d.ts` files for every TypeScript or JavaScript file inside your project.\nThese `.d.ts` files are type definition files which describe the external API of your module.\nWith `.d.ts` files, tools like TypeScript can provide intellisense and accurate types for un-typed code.\n\nWhen `declaration` is set to `true`, running the compiler with this TypeScript code:\n\n```ts twoslash\nexport let helloWorld = \"hi\";\n```\n\nWill generate an `index.js` file like this:\n\n```ts twoslash\n// @showEmit\nexport let helloWorld = \"hi\";\n```\n\nWith a corresponding `helloWorld.d.ts`:\n\n```ts twoslash\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\nexport let helloWorld = \"hi\";\n```\n\nWhen working with `.d.ts` files for JavaScript files you may want to use [`emitDeclarationOnly`](https://typescriptlang.org/tsconfig/#emitDeclarationOnly) or use [`outDir`](https://typescriptlang.org/tsconfig/#outDir) to ensure that the JavaScript files are not overwritten.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Generate `.d.ts` files for every TypeScript or JavaScript file inside your project.\nThese `.d.ts` files are type definition files which describe the external API of your module.\nWith `.d.ts` files, tools like TypeScript can provide intellisense and accurate types for un-typed code.\n\nWhen `declaration` is set to `true`, running the compiler with this TypeScript code:\n\n```ts twoslash\nexport let helloWorld = \"hi\";\n```\n\nWill generate an `index.js` file like this:\n\n```ts twoslash\n// @showEmit\nexport let helloWorld = \"hi\";\n```\n\nWith a corresponding `helloWorld.d.ts`:\n\n```ts twoslash\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\nexport let helloWorld = \"hi\";\n```\n\nWhen working with `.d.ts` files for JavaScript files you may want to use [`emitDeclarationOnly`](https://typescriptlang.org/tsconfig/#emitDeclarationOnly) or use [`outDir`](https://typescriptlang.org/tsconfig/#outDir) to ensure that the JavaScript files are not overwritten.",

"x-intellij-html-description": "<p>Generate <code>.d.ts</code> files for every TypeScript or JavaScript file inside your project.\nThese <code>.d.ts</code> files are type definition files which describe the external API of your module.\nWith <code>.d.ts</code> files, tools like TypeScript can provide intellisense and accurate types for un-typed code.</p>\n<p>When <code>declaration</code> is set to <code>true</code>, running the compiler with this TypeScript code:</p>\n<pre><code class=\"language-ts\">export let helloWorld = &quot;hi&quot;;\n</code></pre>\n<p>Will generate an <code>index.js</code> file like this:</p>\n<pre><code class=\"language-ts\">// @showEmit\nexport let helloWorld = &quot;hi&quot;;\n</code></pre>\n<p>With a corresponding <code>helloWorld.d.ts</code>:</p>\n<pre><code class=\"language-ts\">// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\nexport let helloWorld = &quot;hi&quot;;\n</code></pre>\n<p>When working with <code>.d.ts</code> files for JavaScript files you may want to use <a href=\"https://typescriptlang.org/tsconfig/#emitDeclarationOnly\"><code>emitDeclarationOnly</code></a> or use <a href=\"https://typescriptlang.org/tsconfig/#outDir\"><code>outDir</code></a> to ensure that the JavaScript files are not overwritten.</p>\n"

},

"declarationDir": {

"description": "Offers a way to configure the root directory for where declaration files are emitted.\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nwith this `tsconfig.json`:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"declaration\": true,\n \"declarationDir\": \"./types\"\n }\n}\n```\n\nWould place the d.ts for the `index.ts` in a `types` folder:\n\n```\nexample\n├── index.js\n├── index.ts\n├── package.json\n├── tsconfig.json\n└── types\n └── index.d.ts\n```",

"type": ["string", "null"],

"markdownDescription": "Offers a way to configure the root directory for where declaration files are emitted.\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nwith this `tsconfig.json`:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"declaration\": true,\n \"declarationDir\": \"./types\"\n }\n}\n```\n\nWould place the d.ts for the `index.ts` in a `types` folder:\n\n```\nexample\n├── index.js\n├── index.ts\n├── package.json\n├── tsconfig.json\n└── types\n └── index.d.ts\n```",

"x-intellij-html-description": "<p>Offers a way to configure the root directory for where declaration files are emitted.</p>\n<pre><code>example\n├── index.ts\n├── package.json\n└── tsconfig.json\n</code></pre>\n<p>with this <code>tsconfig.json</code>:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;declaration&quot;: true,\n &quot;declarationDir&quot;: &quot;./types&quot;\n }\n}\n</code></pre>\n<p>Would place the d.ts for the <code>index.ts</code> in a <code>types</code> folder:</p>\n<pre><code>example\n├── index.js\n├── index.ts\n├── package.json\n├── tsconfig.json\n└── types\n └── index.d.ts\n</code></pre>\n"

},

"diagnostics": {

"description": "Used to output diagnostic information for debugging. This command is a subset of [`extendedDiagnostics`](https://typescriptlang.org/tsconfig/#extendedDiagnostics) which are more user-facing results, and easier to interpret.\n\nIf you have been asked by a TypeScript compiler engineer to give the results using this flag in a compile, in which there is no harm in using [`extendedDiagnostics`](https://typescriptlang.org/tsconfig/#extendedDiagnostics) instead.",

"type": ["boolean", "null"],

"markdownDescription": "Used to output diagnostic information for debugging. This command is a subset of [`extendedDiagnostics`](https://typescriptlang.org/tsconfig/#extendedDiagnostics) which are more user-facing results, and easier to interpret.\n\nIf you have been asked by a TypeScript compiler engineer to give the results using this flag in a compile, in which there is no harm in using [`extendedDiagnostics`](https://typescriptlang.org/tsconfig/#extendedDiagnostics) instead.",

"x-intellij-html-description": "<p>Used to output diagnostic information for debugging. This command is a subset of <a href=\"https://typescriptlang.org/tsconfig/#extendedDiagnostics\"><code>extendedDiagnostics</code></a> which are more user-facing results, and easier to interpret.</p>\n<p>If you have been asked by a TypeScript compiler engineer to give the results using this flag in a compile, in which there is no harm in using <a href=\"https://typescriptlang.org/tsconfig/#extendedDiagnostics\"><code>extendedDiagnostics</code></a> instead.</p>\n"

},

"disableReferencedProjectLoad": {

"description": "In multi-project TypeScript programs, TypeScript will load all of the available projects into memory in order to provide accurate results for editor responses which require a full knowledge graph like 'Find All References'.\n\nIf your project is large, you can use the flag `disableReferencedProjectLoad` to disable the automatic loading of all projects. Instead, projects are loaded dynamically as you open files through your editor.",

"type": ["boolean", "null"],

"markdownDescription": "In multi-project TypeScript programs, TypeScript will load all of the available projects into memory in order to provide accurate results for editor responses which require a full knowledge graph like 'Find All References'.\n\nIf your project is large, you can use the flag `disableReferencedProjectLoad` to disable the automatic loading of all projects. Instead, projects are loaded dynamically as you open files through your editor.",

"x-intellij-html-description": "<p>In multi-project TypeScript programs, TypeScript will load all of the available projects into memory in order to provide accurate results for editor responses which require a full knowledge graph like &#39;Find All References&#39;.</p>\n<p>If your project is large, you can use the flag <code>disableReferencedProjectLoad</code> to disable the automatic loading of all projects. Instead, projects are loaded dynamically as you open files through your editor.</p>\n"

},

"noPropertyAccessFromIndexSignature": {

"description": "This setting ensures consistency between accessing a field via the \"dot\" (`obj.key`) syntax, and \"indexed\" (`obj[\"key\"]`) and the way which the property is declared in the type.\n\nWithout this flag, TypeScript will allow you to use the dot syntax to access fields which are not defined:\n\n```ts twoslash\n// @errors: 4111\ndeclare function getSettings(): GameSettings;\n// ---cut---\ninterface GameSettings {\n // Known up-front properties\n speed: \"fast\" | \"medium\" | \"slow\";\n quality: \"high\" | \"low\";\n\n // Assume anything unknown to the interface\n // is a string.\n [key: string]: string;\n}\n\nconst settings = getSettings();\nsettings.speed;\n// ^?\nsettings.quality;\n// ^?\n\n// Unknown key accessors are allowed on\n// this object, and are `string`\nsettings.username;\n// ^?\n```\n\nTurning the flag on will raise an error because the unknown field uses dot syntax instead of indexed syntax.\n\n```ts twoslash\n// @errors: 4111\n// @noPropertyAccessFromIndexSignature\ndeclare function getSettings(): GameSettings;\ninterface GameSettings {\n speed: \"fast\" | \"medium\" | \"slow\";\n quality: \"high\" | \"low\";\n [key: string]: string;\n}\n// ---cut---\nconst settings = getSettings();\nsettings.speed;\nsettings.quality;\n\n// This would need to be settings[\"username\"];\nsettings.username;\n// ^?\n```\n\nThe goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.",

"type": ["boolean", "null"],

"markdownDescription": "This setting ensures consistency between accessing a field via the \"dot\" (`obj.key`) syntax, and \"indexed\" (`obj[\"key\"]`) and the way which the property is declared in the type.\n\nWithout this flag, TypeScript will allow you to use the dot syntax to access fields which are not defined:\n\n```ts twoslash\n// @errors: 4111\ndeclare function getSettings(): GameSettings;\n// ---cut---\ninterface GameSettings {\n // Known up-front properties\n speed: \"fast\" | \"medium\" | \"slow\";\n quality: \"high\" | \"low\";\n\n // Assume anything unknown to the interface\n // is a string.\n [key: string]: string;\n}\n\nconst settings = getSettings();\nsettings.speed;\n// ^?\nsettings.quality;\n// ^?\n\n// Unknown key accessors are allowed on\n// this object, and are `string`\nsettings.username;\n// ^?\n```\n\nTurning the flag on will raise an error because the unknown field uses dot syntax instead of indexed syntax.\n\n```ts twoslash\n// @errors: 4111\n// @noPropertyAccessFromIndexSignature\ndeclare function getSettings(): GameSettings;\ninterface GameSettings {\n speed: \"fast\" | \"medium\" | \"slow\";\n quality: \"high\" | \"low\";\n [key: string]: string;\n}\n// ---cut---\nconst settings = getSettings();\nsettings.speed;\nsettings.quality;\n\n// This would need to be settings[\"username\"];\nsettings.username;\n// ^?\n```\n\nThe goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.",

"x-intellij-html-description": "<p>This setting ensures consistency between accessing a field via the &quot;dot&quot; (<code>obj.key</code>) syntax, and &quot;indexed&quot; (<code>obj[&quot;key&quot;]</code>) and the way which the property is declared in the type.</p>\n<p>Without this flag, TypeScript will allow you to use the dot syntax to access fields which are not defined:</p>\n<pre><code class=\"language-ts\">// @errors: 4111\ndeclare function getSettings(): GameSettings;\n// ---cut---\ninterface GameSettings {\n // Known up-front properties\n speed: &quot;fast&quot; | &quot;medium&quot; | &quot;slow&quot;;\n quality: &quot;high&quot; | &quot;low&quot;;\n\n // Assume anything unknown to the interface\n // is a string.\n [key: string]: string;\n}\n\nconst settings = getSettings();\nsettings.speed;\n// ^?\nsettings.quality;\n// ^?\n\n// Unknown key accessors are allowed on\n// this object, and are `string`\nsettings.username;\n// ^?\n</code></pre>\n<p>Turning the flag on will raise an error because the unknown field uses dot syntax instead of indexed syntax.</p>\n<pre><code class=\"language-ts\">// @errors: 4111\n// @noPropertyAccessFromIndexSignature\ndeclare function getSettings(): GameSettings;\ninterface GameSettings {\n speed: &quot;fast&quot; | &quot;medium&quot; | &quot;slow&quot;;\n quality: &quot;high&quot; | &quot;low&quot;;\n [key: string]: string;\n}\n// ---cut---\nconst settings = getSettings();\nsettings.speed;\nsettings.quality;\n\n// This would need to be settings[&quot;username&quot;];\nsettings.username;\n// ^?\n</code></pre>\n<p>The goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.</p>\n"

},

"emitBOM": {

"description": "Controls whether TypeScript will emit a [byte order mark (BOM)](https://wikipedia.org/wiki/Byte_order_mark) when writing output files.\nSome runtime environments require a BOM to correctly interpret a JavaScript files; others require that it is not present.\nThe default value of `false` is generally best unless you have a reason to change it.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Controls whether TypeScript will emit a [byte order mark (BOM)](https://wikipedia.org/wiki/Byte_order_mark) when writing output files.\nSome runtime environments require a BOM to correctly interpret a JavaScript files; others require that it is not present.\nThe default value of `false` is generally best unless you have a reason to change it.",

"x-intellij-html-description": "<p>Controls whether TypeScript will emit a <a href=\"https://wikipedia.org/wiki/Byte_order_mark\">byte order mark (BOM)</a> when writing output files.\nSome runtime environments require a BOM to correctly interpret a JavaScript files; others require that it is not present.\nThe default value of <code>false</code> is generally best unless you have a reason to change it.</p>\n"

},

"emitDeclarationOnly": {

"description": "_Only_ emit `.d.ts` files; do not emit `.js` files.\n\nThis setting is useful in two cases:\n\n- You are using a transpiler other than TypeScript to generate your JavaScript.\n- You are using TypeScript to only generate `d.ts` files for your consumers.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "_Only_ emit `.d.ts` files; do not emit `.js` files.\n\nThis setting is useful in two cases:\n\n- You are using a transpiler other than TypeScript to generate your JavaScript.\n- You are using TypeScript to only generate `d.ts` files for your consumers.",

"x-intellij-html-description": "<p><em>Only</em> emit <code>.d.ts</code> files; do not emit <code>.js</code> files.</p>\n<p>This setting is useful in two cases:</p>\n<ul>\n<li>You are using a transpiler other than TypeScript to generate your JavaScript.</li>\n<li>You are using TypeScript to only generate <code>d.ts</code> files for your consumers.</li>\n</ul>\n"

},

"erasableSyntaxOnly": {

"description": "Node.js [supports running TypeScript files directly](https://nodejs.org/api/typescript.html#type-stripping) as of v23.6;\nhowever, only TypeScript-specific syntax that does not have runtime semantics are supported under this mode.\nIn other words, it must be possible to easily *erase* any TypeScript-specific syntax from a file, leaving behind a valid JavaScript file.\n\nThat means the following constructs are not supported:\n\n* `enum` declarations\n* `namespace`s and `module`s with runtime code\n* parameter properties in classes\n* Non-ECMAScript `import =` and `export =` assignments\n* `<prefix>`-style type assertions\n\n```ts\n// ❌ error: An `import ... = require(...)` alias\nimport foo = require(\"foo\");\n\n// ❌ error: A namespace with runtime code.\nnamespace container {\n foo.method();\n\n export type Bar = string;\n}\n\n// ❌ error: An `import =` alias\nimport Bar = container.Bar;\n\nclass Point {\n // ❌ error: Parameter properties\n constructor(public x: number, public y: number) { }\n}\n\n// ❌ error: An `export =` assignment.\nexport = Point;\n\n// ❌ error: An enum declaration.\nenum Direction {\n Up,\n Down,\n Left,\n Right,\n}\n\n// ❌ error: <prefix>-style type assertion.\nconst num = <number>1;\n```\n\nSimilar tools like [ts-blank-space](https://github.com/bloomberg/ts-blank-space) or [Amaro](https://github.com/nodejs/amaro) (the underlying library for type-stripping in Node.js) have the same limitations.\nThese tools will provide helpful error messages if they encounter code that doesn't meet these requirements, but you still won't find out your code doesn't work until you actually try to run it.\n\nThe `--erasableSyntaxOnly` flag will cause TypeScript to error on most TypeScript-specific constructs that have runtime behavior.\n\n```ts\nclass C {\n constructor(public x: number) { }\n // ~~~~~~~~~~~~~~~~\n // error! This syntax is not allowed when 'erasableSyntaxOnly' is enabled.\n }\n}\n```\n\nTypically, you will want to combine this flag with the `--verbatimModuleSyntax`, which ensures that a module contains the appropriate import syntax, and that import elision does not take place.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Node.js [supports running TypeScript files directly](https://nodejs.org/api/typescript.html#type-stripping) as of v23.6;\nhowever, only TypeScript-specific syntax that does not have runtime semantics are supported under this mode.\nIn other words, it must be possible to easily *erase* any TypeScript-specific syntax from a file, leaving behind a valid JavaScript file.\n\nThat means the following constructs are not supported:\n\n* `enum` declarations\n* `namespace`s and `module`s with runtime code\n* parameter properties in classes\n* Non-ECMAScript `import =` and `export =` assignments\n* `<prefix>`-style type assertions\n\n```ts\n// ❌ error: An `import ... = require(...)` alias\nimport foo = require(\"foo\");\n\n// ❌ error: A namespace with runtime code.\nnamespace container {\n foo.method();\n\n export type Bar = string;\n}\n\n// ❌ error: An `import =` alias\nimport Bar = container.Bar;\n\nclass Point {\n // ❌ error: Parameter properties\n constructor(public x: number, public y: number) { }\n}\n\n// ❌ error: An `export =` assignment.\nexport = Point;\n\n// ❌ error: An enum declaration.\nenum Direction {\n Up,\n Down,\n Left,\n Right,\n}\n\n// ❌ error: <prefix>-style type assertion.\nconst num = <number>1;\n```\n\nSimilar tools like [ts-blank-space](https://github.com/bloomberg/ts-blank-space) or [Amaro](https://github.com/nodejs/amaro) (the underlying library for type-stripping in Node.js) have the same limitations.\nThese tools will provide helpful error messages if they encounter code that doesn't meet these requirements, but you still won't find out your code doesn't work until you actually try to run it.\n\nThe `--erasableSyntaxOnly` flag will cause TypeScript to error on most TypeScript-specific constructs that have runtime behavior.\n\n```ts\nclass C {\n constructor(public x: number) { }\n // ~~~~~~~~~~~~~~~~\n // error! This syntax is not allowed when 'erasableSyntaxOnly' is enabled.\n }\n}\n```\n\nTypically, you will want to combine this flag with the `--verbatimModuleSyntax`, which ensures that a module contains the appropriate import syntax, and that import elision does not take place.",

"x-intellij-html-description": "<p>Node.js <a href=\"https://nodejs.org/api/typescript.html#type-stripping\">supports running TypeScript files directly</a> as of v23.6;\nhowever, only TypeScript-specific syntax that does not have runtime semantics are supported under this mode.\nIn other words, it must be possible to easily <em>erase</em> any TypeScript-specific syntax from a file, leaving behind a valid JavaScript file.</p>\n<p>That means the following constructs are not supported:</p>\n<ul>\n<li><code>enum</code> declarations</li>\n<li><code>namespace</code>s and <code>module</code>s with runtime code</li>\n<li>parameter properties in classes</li>\n<li>Non-ECMAScript <code>import =</code> and <code>export =</code> assignments</li>\n<li><code>&lt;prefix&gt;</code>-style type assertions</li>\n</ul>\n<pre><code class=\"language-ts\">// ❌ error: An `import ... = require(...)` alias\nimport foo = require(&quot;foo&quot;);\n\n// ❌ error: A namespace with runtime code.\nnamespace container {\n foo.method();\n\n export type Bar = string;\n}\n\n// ❌ error: An `import =` alias\nimport Bar = container.Bar;\n\nclass Point {\n // ❌ error: Parameter properties\n constructor(public x: number, public y: number) { }\n}\n\n// ❌ error: An `export =` assignment.\nexport = Point;\n\n// ❌ error: An enum declaration.\nenum Direction {\n Up,\n Down,\n Left,\n Right,\n}\n\n// ❌ error: &lt;prefix&gt;-style type assertion.\nconst num = &lt;number&gt;1;\n</code></pre>\n<p>Similar tools like <a href=\"https://github.com/bloomberg/ts-blank-space\">ts-blank-space</a> or <a href=\"https://github.com/nodejs/amaro\">Amaro</a> (the underlying library for type-stripping in Node.js) have the same limitations.\nThese tools will provide helpful error messages if they encounter code that doesn&#39;t meet these requirements, but you still won&#39;t find out your code doesn&#39;t work until you actually try to run it.</p>\n<p>The <code>--erasableSyntaxOnly</code> flag will cause TypeScript to error on most TypeScript-specific constructs that have runtime behavior.</p>\n<pre><code class=\"language-ts\">class C {\n constructor(public x: number) { }\n // ~~~~~~~~~~~~~~~~\n // error! This syntax is not allowed when &#39;erasableSyntaxOnly&#39; is enabled.\n }\n}\n</code></pre>\n<p>Typically, you will want to combine this flag with the <code>--verbatimModuleSyntax</code>, which ensures that a module contains the appropriate import syntax, and that import elision does not take place.</p>\n"

},

"exactOptionalPropertyTypes": {

"description": "With exactOptionalPropertyTypes enabled, TypeScript applies stricter rules around how it handles properties on `type` or `interfaces` which have a `?` prefix.\n\nFor example, this interface declares that there is a property which can be one of two strings: 'dark' or 'light' or it should not be in the object.\n\n```ts\ninterface UserDefaults {\n // The absence of a value represents 'system'\n colorThemeOverride?: \"dark\" | \"light\";\n}\n```\n\nWithout this flag enabled, there are three values which you can set `colorThemeOverride` to be: \"dark\", \"light\" and `undefined`.\n\nSetting the value to `undefined` will allow most JavaScript runtime checks for the existence to fail, which is effectively falsy. However, this isn't quite accurate; `colorThemeOverride: undefined` is not the same as `colorThemeOverride` not being defined. For example, `\"colorThemeOverride\" in settings` would have different behavior with `undefined` as the key compared to not being defined.\n\n`exactOptionalPropertyTypes` makes TypeScript truly enforce the definition provided as an optional property:\n\n```ts twoslash\n// @exactOptionalPropertyTypes\n// @errors: 2322 2412\ninterface UserDefaults {\n colorThemeOverride?: \"dark\" | \"light\";\n}\ndeclare function getUserSettings(): UserDefaults;\n// ---cut---\nconst settings = getUserSettings();\nsettings.colorThemeOverride = \"dark\";\nsettings.colorThemeOverride = \"light\";\n\n// But not:\nsettings.colorThemeOverride = undefined;\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "With exactOptionalPropertyTypes enabled, TypeScript applies stricter rules around how it handles properties on `type` or `interfaces` which have a `?` prefix.\n\nFor example, this interface declares that there is a property which can be one of two strings: 'dark' or 'light' or it should not be in the object.\n\n```ts\ninterface UserDefaults {\n // The absence of a value represents 'system'\n colorThemeOverride?: \"dark\" | \"light\";\n}\n```\n\nWithout this flag enabled, there are three values which you can set `colorThemeOverride` to be: \"dark\", \"light\" and `undefined`.\n\nSetting the value to `undefined` will allow most JavaScript runtime checks for the existence to fail, which is effectively falsy. However, this isn't quite accurate; `colorThemeOverride: undefined` is not the same as `colorThemeOverride` not being defined. For example, `\"colorThemeOverride\" in settings` would have different behavior with `undefined` as the key compared to not being defined.\n\n`exactOptionalPropertyTypes` makes TypeScript truly enforce the definition provided as an optional property:\n\n```ts twoslash\n// @exactOptionalPropertyTypes\n// @errors: 2322 2412\ninterface UserDefaults {\n colorThemeOverride?: \"dark\" | \"light\";\n}\ndeclare function getUserSettings(): UserDefaults;\n// ---cut---\nconst settings = getUserSettings();\nsettings.colorThemeOverride = \"dark\";\nsettings.colorThemeOverride = \"light\";\n\n// But not:\nsettings.colorThemeOverride = undefined;\n```",

"x-intellij-html-description": "<p>With exactOptionalPropertyTypes enabled, TypeScript applies stricter rules around how it handles properties on <code>type</code> or <code>interfaces</code> which have a <code>?</code> prefix.</p>\n<p>For example, this interface declares that there is a property which can be one of two strings: &#39;dark&#39; or &#39;light&#39; or it should not be in the object.</p>\n<pre><code class=\"language-ts\">interface UserDefaults {\n // The absence of a value represents &#39;system&#39;\n colorThemeOverride?: &quot;dark&quot; | &quot;light&quot;;\n}\n</code></pre>\n<p>Without this flag enabled, there are three values which you can set <code>colorThemeOverride</code> to be: &quot;dark&quot;, &quot;light&quot; and <code>undefined</code>.</p>\n<p>Setting the value to <code>undefined</code> will allow most JavaScript runtime checks for the existence to fail, which is effectively falsy. However, this isn&#39;t quite accurate; <code>colorThemeOverride: undefined</code> is not the same as <code>colorThemeOverride</code> not being defined. For example, <code>&quot;colorThemeOverride&quot; in settings</code> would have different behavior with <code>undefined</code> as the key compared to not being defined.</p>\n<p><code>exactOptionalPropertyTypes</code> makes TypeScript truly enforce the definition provided as an optional property:</p>\n<pre><code class=\"language-ts\">// @exactOptionalPropertyTypes\n// @errors: 2322 2412\ninterface UserDefaults {\n colorThemeOverride?: &quot;dark&quot; | &quot;light&quot;;\n}\ndeclare function getUserSettings(): UserDefaults;\n// ---cut---\nconst settings = getUserSettings();\nsettings.colorThemeOverride = &quot;dark&quot;;\nsettings.colorThemeOverride = &quot;light&quot;;\n\n// But not:\nsettings.colorThemeOverride = undefined;\n</code></pre>\n"

},

"incremental": {

"description": "Enable incremental compilation. Requires TypeScript version 3.4 or later.",

"type": ["boolean", "null"]

},

"tsBuildInfoFile": {

"description": "This setting lets you specify a file for storing incremental compilation information as a part of composite projects which enables faster\nbuilding of larger TypeScript codebases. You can read more about composite projects [in the handbook](https://typescriptlang.org/docs/handbook/project-references.html).\n\nThe default depends on a combination of other settings:\n\n- If `outFile` is set, the default is `<outFile>.tsbuildinfo`.\n- If `rootDir` and `outDir` are set, then the file is `<outDir>/<relative path to config from rootDir>/<config name>.tsbuildinfo`\n For example, if `rootDir` is `src`, `outDir` is `dest`, and the config is\n `./tsconfig.json`, then the default is `./tsconfig.tsbuildinfo`\n as the relative path from `src/` to `./tsconfig.json` is `../`.\n- If `outDir` is set, then the default is `<outDir>/<config name>.tsbuildInfo`\n- Otherwise, the default is `<config name>.tsbuildInfo`",

"default": ".tsbuildinfo",

"type": ["string", "null"],

"markdownDescription": "This setting lets you specify a file for storing incremental compilation information as a part of composite projects which enables faster\nbuilding of larger TypeScript codebases. You can read more about composite projects [in the handbook](https://typescriptlang.org/docs/handbook/project-references.html).\n\nThe default depends on a combination of other settings:\n\n- If `outFile` is set, the default is `<outFile>.tsbuildinfo`.\n- If `rootDir` and `outDir` are set, then the file is `<outDir>/<relative path to config from rootDir>/<config name>.tsbuildinfo`\n For example, if `rootDir` is `src`, `outDir` is `dest`, and the config is\n `./tsconfig.json`, then the default is `./tsconfig.tsbuildinfo`\n as the relative path from `src/` to `./tsconfig.json` is `../`.\n- If `outDir` is set, then the default is `<outDir>/<config name>.tsbuildInfo`\n- Otherwise, the default is `<config name>.tsbuildInfo`",

"x-intellij-html-description": "<p>This setting lets you specify a file for storing incremental compilation information as a part of composite projects which enables faster\nbuilding of larger TypeScript codebases. You can read more about composite projects <a href=\"https://typescriptlang.org/docs/handbook/project-references.html\">in the handbook</a>.</p>\n<p>The default depends on a combination of other settings:</p>\n<ul>\n<li>If <code>outFile</code> is set, the default is <code>&lt;outFile&gt;.tsbuildinfo</code>.</li>\n<li>If <code>rootDir</code> and <code>outDir</code> are set, then the file is <code>&lt;outDir&gt;/&lt;relative path to config from rootDir&gt;/&lt;config name&gt;.tsbuildinfo</code>\nFor example, if <code>rootDir</code> is <code>src</code>, <code>outDir</code> is <code>dest</code>, and the config is\n<code>./tsconfig.json</code>, then the default is <code>./tsconfig.tsbuildinfo</code>\nas the relative path from <code>src/</code> to <code>./tsconfig.json</code> is <code>../</code>.</li>\n<li>If <code>outDir</code> is set, then the default is <code>&lt;outDir&gt;/&lt;config name&gt;.tsbuildInfo</code></li>\n<li>Otherwise, the default is <code>&lt;config name&gt;.tsbuildInfo</code></li>\n</ul>\n"

},

"inlineSourceMap": {

"description": "When set, instead of writing out a `.js.map` file to provide source maps, TypeScript will embed the source map content in the `.js` files.\nAlthough this results in larger JS files, it can be convenient in some scenarios.\nFor example, you might want to debug JS files on a webserver that doesn't allow `.map` files to be served.\n\nMutually exclusive with [`sourceMap`](https://typescriptlang.org/tsconfig/#sourceMap).\n\nFor example, with this TypeScript:\n\n```ts\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nConverts to this JavaScript:\n\n```ts twoslash\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nThen enable building it with `inlineSourceMap` enabled there is a comment at the bottom of the file which includes\na source-map for the file.\n\n```ts twoslash\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "When set, instead of writing out a `.js.map` file to provide source maps, TypeScript will embed the source map content in the `.js` files.\nAlthough this results in larger JS files, it can be convenient in some scenarios.\nFor example, you might want to debug JS files on a webserver that doesn't allow `.map` files to be served.\n\nMutually exclusive with [`sourceMap`](https://typescriptlang.org/tsconfig/#sourceMap).\n\nFor example, with this TypeScript:\n\n```ts\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nConverts to this JavaScript:\n\n```ts twoslash\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nThen enable building it with `inlineSourceMap` enabled there is a comment at the bottom of the file which includes\na source-map for the file.\n\n```ts twoslash\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```",

"x-intellij-html-description": "<p>When set, instead of writing out a <code>.js.map</code> file to provide source maps, TypeScript will embed the source map content in the <code>.js</code> files.\nAlthough this results in larger JS files, it can be convenient in some scenarios.\nFor example, you might want to debug JS files on a webserver that doesn&#39;t allow <code>.map</code> files to be served.</p>\n<p>Mutually exclusive with <a href=\"https://typescriptlang.org/tsconfig/#sourceMap\"><code>sourceMap</code></a>.</p>\n<p>For example, with this TypeScript:</p>\n<pre><code class=\"language-ts\">const helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n<p>Converts to this JavaScript:</p>\n<pre><code class=\"language-ts\">// @showEmit\nconst helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n<p>Then enable building it with <code>inlineSourceMap</code> enabled there is a comment at the bottom of the file which includes\na source-map for the file.</p>\n<pre><code class=\"language-ts\">// @inlineSourceMap\n// @showEmit\nconst helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n"

},

"inlineSources": {

"description": "When set, TypeScript will include the original content of the `.ts` file as an embedded string in the source map (using the source map's `sourcesContent` property).\nThis is often useful in the same cases as [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap).\n\nRequires either [`sourceMap`](https://typescriptlang.org/tsconfig/#sourceMap) or [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) to be set.\n\nFor example, with this TypeScript:\n\n```ts twoslash\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nBy default converts to this JavaScript:\n\n```ts twoslash\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nThen enable building it with `inlineSources` and [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) enabled there is a comment at the bottom of the file which includes\na source-map for the file.\nNote that the end is different from the example in [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) because the source-map now contains the original source code also.\n\n```ts twoslash\n// @inlineSources\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "When set, TypeScript will include the original content of the `.ts` file as an embedded string in the source map (using the source map's `sourcesContent` property).\nThis is often useful in the same cases as [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap).\n\nRequires either [`sourceMap`](https://typescriptlang.org/tsconfig/#sourceMap) or [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) to be set.\n\nFor example, with this TypeScript:\n\n```ts twoslash\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nBy default converts to this JavaScript:\n\n```ts twoslash\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nThen enable building it with `inlineSources` and [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) enabled there is a comment at the bottom of the file which includes\na source-map for the file.\nNote that the end is different from the example in [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) because the source-map now contains the original source code also.\n\n```ts twoslash\n// @inlineSources\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```",

"x-intellij-html-description": "<p>When set, TypeScript will include the original content of the <code>.ts</code> file as an embedded string in the source map (using the source map&#39;s <code>sourcesContent</code> property).\nThis is often useful in the same cases as <a href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"><code>inlineSourceMap</code></a>.</p>\n<p>Requires either <a href=\"https://typescriptlang.org/tsconfig/#sourceMap\"><code>sourceMap</code></a> or <a href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"><code>inlineSourceMap</code></a> to be set.</p>\n<p>For example, with this TypeScript:</p>\n<pre><code class=\"language-ts\">const helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n<p>By default converts to this JavaScript:</p>\n<pre><code class=\"language-ts\">// @showEmit\nconst helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n<p>Then enable building it with <code>inlineSources</code> and <a href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"><code>inlineSourceMap</code></a> enabled there is a comment at the bottom of the file which includes\na source-map for the file.\nNote that the end is different from the example in <a href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"><code>inlineSourceMap</code></a> because the source-map now contains the original source code also.</p>\n<pre><code class=\"language-ts\">// @inlineSources\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n"

},

"jsx": {

"description": "Controls how JSX constructs are emitted in JavaScript files.\nThis only affects output of JS files that started in `.tsx` files.\n\n- `react-jsx`: Emit `.js` files with the JSX changed to `_jsx` calls optimized for production\n- `react-jsxdev`: Emit `.js` files with the JSX changed to `_jsx` calls for development only\n- `preserve`: Emit `.jsx` files with the JSX unchanged\n- `react-native`: Emit `.js` files with the JSX unchanged\n- `react`: Emit `.js` files with JSX changed to the equivalent `React.createElement` calls\n\n### For example\n\nThis sample code:\n\n```tsx\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nReact: `\"react-jsx\"`^{[[1]](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html)}\n\n```tsx twoslash\ndeclare module JSX {\n interface Element {}\n interface IntrinsicElements {\n [s: string]: any;\n }\n}\n// @showEmit\n// @noErrors\n// @jsx: react-jsx\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nReact dev transform: `\"react-jsxdev\"`^{[[1]](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html)}\n\n```tsx twoslash\ndeclare module JSX {\n interface Element {}\n interface IntrinsicElements {\n [s: string]: any;\n }\n}\n// @showEmit\n// @noErrors\n// @jsx: react-jsxdev\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nPreserve: `\"preserve\"`\n\n```tsx twoslash\ndeclare module JSX {\n interface Element {}\n interface IntrinsicElements {\n [s: string]: any;\n }\n}\n// @showEmit\n// @noErrors\n// @jsx: preserve\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nReact Native: `\"react-native\"`\n\n```tsx twoslash\ndeclare module JSX {\n interface Element {}\n interface IntrinsicElements {\n [s: string]: any;\n }\n}\n// @showEmit\n// @noErrors\n// @jsx: react-native\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\n\nLegacy React runtime: `\"react\"`\n\n```tsx twoslash\ndeclare module JSX {\n interface Element {}\n interface IntrinsicElements {\n [s: string]: any;\n }\n}\n// @showEmit\n// @noErrors\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nThis option can be used on a per-file basis too using an `@jsxRuntime` comment.\n\nAlways use the classic runtime (`\"react\"`) for this file:\n\n```tsx\n/* @jsxRuntime classic */\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nAlways use the automatic runtime (`\"react-jsx\"`) for this file:\n\n```tsx\n/* @jsxRuntime automatic */\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```",

"enum": [

"preserve",

"react",

"react-jsx",

"react-jsxdev",

"react-native"

]

},

"reactNamespace": {

"description": "Use [`jsxFactory`](https://typescriptlang.org/tsconfig/#jsxFactory) instead. Specify the object invoked for `createElement` when targeting `react` for TSX files.",

"type": ["string", "null"],

"default": "React",

"markdownDescription": "Use [`jsxFactory`](https://typescriptlang.org/tsconfig/#jsxFactory) instead. Specify the object invoked for `createElement` when targeting `react` for TSX files.",

"x-intellij-html-description": "<p>Use <a href=\"https://typescriptlang.org/tsconfig/#jsxFactory\"><code>jsxFactory</code></a> instead. Specify the object invoked for <code>createElement</code> when targeting <code>react</code> for TSX files.</p>\n"

},

"jsxFactory": {

"description": "Changes the function called in `.js` files when compiling JSX Elements using the classic JSX runtime.\nThe most common change is to use `\"h\"` or `\"preact.h\"` instead of the default `\"React.createElement\"` if using `preact`.\n\nFor example, this TSX file:\n\n```tsx\nimport { h } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nWith `jsxFactory: \"h\"` looks like:\n\n```tsx twoslash\n// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nThis option can be used on a per-file basis too similar to [Babel's `/** @jsx h */` directive](https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#custom).\n\n```tsx twoslash\n/** @jsx h */\nimport { h } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nThe factory chosen will also affect where the `JSX` namespace is looked up (for type checking information) before falling back to the global one.\n\nIf the factory is defined as `React.createElement` (the default), the compiler will check for `React.JSX` before checking for a global `JSX`. If the factory is defined as `h`, it will check for `h.JSX` before a global `JSX`.",

"type": ["string", "null"],

"default": "React.createElement",

"markdownDescription": "Changes the function called in `.js` files when compiling JSX Elements using the classic JSX runtime.\nThe most common change is to use `\"h\"` or `\"preact.h\"` instead of the default `\"React.createElement\"` if using `preact`.\n\nFor example, this TSX file:\n\n```tsx\nimport { h } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nWith `jsxFactory: \"h\"` looks like:\n\n```tsx twoslash\n// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nThis option can be used on a per-file basis too similar to [Babel's `/** @jsx h */` directive](https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#custom).\n\n```tsx twoslash\n/** @jsx h */\nimport { h } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nThe factory chosen will also affect where the `JSX` namespace is looked up (for type checking information) before falling back to the global one.\n\nIf the factory is defined as `React.createElement` (the default), the compiler will check for `React.JSX` before checking for a global `JSX`. If the factory is defined as `h`, it will check for `h.JSX` before a global `JSX`.",

"x-intellij-html-description": "<p>Changes the function called in <code>.js</code> files when compiling JSX Elements using the classic JSX runtime.\nThe most common change is to use <code>&quot;h&quot;</code> or <code>&quot;preact.h&quot;</code> instead of the default <code>&quot;React.createElement&quot;</code> if using <code>preact</code>.</p>\n<p>For example, this TSX file:</p>\n<pre><code class=\"language-tsx\">import { h } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; &lt;div&gt;Hello&lt;/div&gt;;\n</code></pre>\n<p>With <code>jsxFactory: &quot;h&quot;</code> looks like:</p>\n<pre><code class=\"language-tsx\">// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; &lt;div&gt;Hello&lt;/div&gt;;\n</code></pre>\n<p>This option can be used on a per-file basis too similar to <a href=\"https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#custom\">Babel&#39;s <code>/** @jsx h */</code> directive</a>.</p>\n<pre><code class=\"language-tsx\">/** @jsx h */\nimport { h } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; &lt;div&gt;Hello&lt;/div&gt;;\n</code></pre>\n<p>The factory chosen will also affect where the <code>JSX</code> namespace is looked up (for type checking information) before falling back to the global one.</p>\n<p>If the factory is defined as <code>React.createElement</code> (the default), the compiler will check for <code>React.JSX</code> before checking for a global <code>JSX</code>. If the factory is defined as <code>h</code>, it will check for <code>h.JSX</code> before a global <code>JSX</code>.</p>\n"

},

"jsxFragmentFactory": {

"description": "Specify the JSX fragment factory function to use when targeting react JSX emit with [`jsxFactory`](https://typescriptlang.org/tsconfig/#jsxFactory) compiler option is specified, e.g. `Fragment`.\n\nFor example with this TSConfig:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"target\": \"esnext\",\n \"module\": \"commonjs\",\n \"jsx\": \"react\",\n \"jsxFactory\": \"h\",\n \"jsxFragmentFactory\": \"Fragment\"\n }\n}\n```\n\nThis TSX file:\n\n```tsx\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n <>\n <div>Hello</div>\n </>\n);\n```\n\nWould look like:\n\n```tsx twoslash\n// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @jsxFragmentFactory: Fragment\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n <>\n <div>Hello</div>\n </>\n);\n```\n\nThis option can be used on a per-file basis too similar to [Babel's `/* @jsxFrag h */` directive](https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#fragments).\n\nFor example:\n\n```tsx twoslash\n/** @jsx h */\n/** @jsxFrag Fragment */\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n <>\n <div>Hello</div>\n </>\n);\n```",

"type": ["string", "null"],

"default": "React.Fragment",

"markdownDescription": "Specify the JSX fragment factory function to use when targeting react JSX emit with [`jsxFactory`](https://typescriptlang.org/tsconfig/#jsxFactory) compiler option is specified, e.g. `Fragment`.\n\nFor example with this TSConfig:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"target\": \"esnext\",\n \"module\": \"commonjs\",\n \"jsx\": \"react\",\n \"jsxFactory\": \"h\",\n \"jsxFragmentFactory\": \"Fragment\"\n }\n}\n```\n\nThis TSX file:\n\n```tsx\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n <>\n <div>Hello</div>\n </>\n);\n```\n\nWould look like:\n\n```tsx twoslash\n// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @jsxFragmentFactory: Fragment\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n <>\n <div>Hello</div>\n </>\n);\n```\n\nThis option can be used on a per-file basis too similar to [Babel's `/* @jsxFrag h */` directive](https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#fragments).\n\nFor example:\n\n```tsx twoslash\n/** @jsx h */\n/** @jsxFrag Fragment */\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n <>\n <div>Hello</div>\n </>\n);\n```",

"x-intellij-html-description": "<p>Specify the JSX fragment factory function to use when targeting react JSX emit with <a href=\"https://typescriptlang.org/tsconfig/#jsxFactory\"><code>jsxFactory</code></a> compiler option is specified, e.g. <code>Fragment</code>.</p>\n<p>For example with this TSConfig:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;target&quot;: &quot;esnext&quot;,\n &quot;module&quot;: &quot;commonjs&quot;,\n &quot;jsx&quot;: &quot;react&quot;,\n &quot;jsxFactory&quot;: &quot;h&quot;,\n &quot;jsxFragmentFactory&quot;: &quot;Fragment&quot;\n }\n}\n</code></pre>\n<p>This TSX file:</p>\n<pre><code class=\"language-tsx\">import { h, Fragment } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; (\n &lt;&gt;\n &lt;div&gt;Hello&lt;/div&gt;\n &lt;/&gt;\n);\n</code></pre>\n<p>Would look like:</p>\n<pre><code class=\"language-tsx\">// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @jsxFragmentFactory: Fragment\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; (\n &lt;&gt;\n &lt;div&gt;Hello&lt;/div&gt;\n &lt;/&gt;\n);\n</code></pre>\n<p>This option can be used on a per-file basis too similar to <a href=\"https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#fragments\">Babel&#39;s <code>/* @jsxFrag h */</code> directive</a>.</p>\n<p>For example:</p>\n<pre><code class=\"language-tsx\">/** @jsx h */\n/** @jsxFrag Fragment */\n\nimport { h, Fragment } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; (\n &lt;&gt;\n &lt;div&gt;Hello&lt;/div&gt;\n &lt;/&gt;\n);\n</code></pre>\n"

},

"jsxImportSource": {

"description": "Declares the module specifier to be used for importing the `jsx` and `jsxs` factory functions when using [`jsx`](https://typescriptlang.org/tsconfig/#jsx) as `\"react-jsx\"` or `\"react-jsxdev\"` which were introduced in TypeScript 4.1.\n\nWith [React 17](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html) the library supports a new form of JSX transformation via a separate import.\n\nFor example with this code:\n\n```tsx\nimport React from \"react\";\n\nfunction App() {\n return <h1>Hello World</h1>;\n}\n```\n\nUsing this TSConfig:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"target\": \"esnext\",\n \"module\": \"commonjs\",\n \"jsx\": \"react-jsx\"\n }\n}\n```\n\nThe emitted JavaScript from TypeScript is:\n\n```tsx twoslash\n// @showEmit\n// @noErrors\n// @jsx: react-jsx\n// @module: commonjs\n// @target: esnext\ndeclare module JSX {\n interface Element {}\n interface IntrinsicElements {\n [s: string]: any;\n }\n}\nimport React from \"react\";\n\nfunction App() {\n return <h1>Hello World</h1>;\n}\n```\n\nFor example if you wanted to use `\"jsxImportSource\": \"preact\"`, you need a tsconfig like:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"target\": \"esnext\",\n \"module\": \"commonjs\",\n \"jsx\": \"react-jsx\",\n \"jsxImportSource\": \"preact\",\n \"types\": [\"preact\"]\n }\n}\n```\n\nWhich generates code like:\n\n```tsx twoslash\n// @showEmit\n// @jsxImportSource: preact\n// @types: preact\n// @jsx: react-jsx\n// @target: esnext\n// @module: commonjs\n// @noErrors\n\nexport function App() {\n return <h1>Hello World</h1>;\n}\n```\n\nAlternatively, you can use a per-file pragma to set this option, for example:\n\n```tsx\n/** @jsxImportSource preact */\n\nexport function App() {\n return <h1>Hello World</h1>;\n}\n```\n\nWould add `preact/jsx-runtime` as an import for the `_jsx` factory.\n\n_Note:_ In order for this to work like you would expect, your `tsx` file must include an `export` or `import` so that it is considered a module.",

"type": ["string", "null"],

"default": "react",

"markdownDescription": "Declares the module specifier to be used for importing the `jsx` and `jsxs` factory functions when using [`jsx`](https://typescriptlang.org/tsconfig/#jsx) as `\"react-jsx\"` or `\"react-jsxdev\"` which were introduced in TypeScript 4.1.\n\nWith [React 17](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html) the library supports a new form of JSX transformation via a separate import.\n\nFor example with this code:\n\n```tsx\nimport React from \"react\";\n\nfunction App() {\n return <h1>Hello World</h1>;\n}\n```\n\nUsing this TSConfig:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"target\": \"esnext\",\n \"module\": \"commonjs\",\n \"jsx\": \"react-jsx\"\n }\n}\n```\n\nThe emitted JavaScript from TypeScript is:\n\n```tsx twoslash\n// @showEmit\n// @noErrors\n// @jsx: react-jsx\n// @module: commonjs\n// @target: esnext\ndeclare module JSX {\n interface Element {}\n interface IntrinsicElements {\n [s: string]: any;\n }\n}\nimport React from \"react\";\n\nfunction App() {\n return <h1>Hello World</h1>;\n}\n```\n\nFor example if you wanted to use `\"jsxImportSource\": \"preact\"`, you need a tsconfig like:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"target\": \"esnext\",\n \"module\": \"commonjs\",\n \"jsx\": \"react-jsx\",\n \"jsxImportSource\": \"preact\",\n \"types\": [\"preact\"]\n }\n}\n```\n\nWhich generates code like:\n\n```tsx twoslash\n// @showEmit\n// @jsxImportSource: preact\n// @types: preact\n// @jsx: react-jsx\n// @target: esnext\n// @module: commonjs\n// @noErrors\n\nexport function App() {\n return <h1>Hello World</h1>;\n}\n```\n\nAlternatively, you can use a per-file pragma to set this option, for example:\n\n```tsx\n/** @jsxImportSource preact */\n\nexport function App() {\n return <h1>Hello World</h1>;\n}\n```\n\nWould add `preact/jsx-runtime` as an import for the `_jsx` factory.\n\n_Note:_ In order for this to work like you would expect, your `tsx` file must include an `export` or `import` so that it is considered a module.",

"x-intellij-html-description": "<p>Declares the module specifier to be used for importing the <code>jsx</code> and <code>jsxs</code> factory functions when using <a href=\"https://typescriptlang.org/tsconfig/#jsx\"><code>jsx</code></a> as <code>&quot;react-jsx&quot;</code> or <code>&quot;react-jsxdev&quot;</code> which were introduced in TypeScript 4.1.</p>\n<p>With <a href=\"https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html\">React 17</a> the library supports a new form of JSX transformation via a separate import.</p>\n<p>For example with this code:</p>\n<pre><code class=\"language-tsx\">import React from &quot;react&quot;;\n\nfunction App() {\n return &lt;h1&gt;Hello World&lt;/h1&gt;;\n}\n</code></pre>\n<p>Using this TSConfig:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;target&quot;: &quot;esnext&quot;,\n &quot;module&quot;: &quot;commonjs&quot;,\n &quot;jsx&quot;: &quot;react-jsx&quot;\n }\n}\n</code></pre>\n<p>The emitted JavaScript from TypeScript is:</p>\n<pre><code class=\"language-tsx\">// @showEmit\n// @noErrors\n// @jsx: react-jsx\n// @module: commonjs\n// @target: esnext\ndeclare module JSX {\n interface Element {}\n interface IntrinsicElements {\n [s: string]: any;\n }\n}\nimport React from &quot;react&quot;;\n\nfunction App() {\n return &lt;h1&gt;Hello World&lt;/h1&gt;;\n}\n</code></pre>\n<p>For example if you wanted to use <code>&quot;jsxImportSource&quot;: &quot;preact&quot;</code>, you need a tsconfig like:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;target&quot;: &quot;esnext&quot;,\n &quot;module&quot;: &quot;commonjs&quot;,\n &quot;jsx&quot;: &quot;react-jsx&quot;,\n &quot;jsxImportSource&quot;: &quot;preact&quot;,\n &quot;types&quot;: [&quot;preact&quot;]\n }\n}\n</code></pre>\n<p>Which generates code like:</p>\n<pre><code class=\"language-tsx\">// @showEmit\n// @jsxImportSource: preact\n// @types: preact\n// @jsx: react-jsx\n// @target: esnext\n// @module: commonjs\n// @noErrors\n\nexport function App() {\n return &lt;h1&gt;Hello World&lt;/h1&gt;;\n}\n</code></pre>\n<p>Alternatively, you can use a per-file pragma to set this option, for example:</p>\n<pre><code class=\"language-tsx\">/** @jsxImportSource preact */\n\nexport function App() {\n return &lt;h1&gt;Hello World&lt;/h1&gt;;\n}\n</code></pre>\n<p>Would add <code>preact/jsx-runtime</code> as an import for the <code>_jsx</code> factory.</p>\n<p><em>Note:</em> In order for this to work like you would expect, your <code>tsx</code> file must include an <code>export</code> or <code>import</code> so that it is considered a module.</p>\n"

},

"listFiles": {

"description": "Print names of files part of the compilation. This is useful when you are not sure that TypeScript has\nincluded a file you expected.\n\nFor example:\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nWith:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"listFiles\": true\n }\n}\n```\n\nWould echo paths like:\n\n```\n$ npm run tsc\npath/to/example/node_modules/typescript/lib/lib.d.ts\npath/to/example/node_modules/typescript/lib/lib.es5.d.ts\npath/to/example/node_modules/typescript/lib/lib.dom.d.ts\npath/to/example/node_modules/typescript/lib/lib.webworker.importscripts.d.ts\npath/to/example/node_modules/typescript/lib/lib.scripthost.d.ts\npath/to/example/index.ts\n```\n\nNote if using TypeScript 4.2, prefer [`explainFiles`](https://typescriptlang.org/tsconfig/#explainFiles) which offers an explanation of why a file was added too.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Print names of files part of the compilation. This is useful when you are not sure that TypeScript has\nincluded a file you expected.\n\nFor example:\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nWith:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"listFiles\": true\n }\n}\n```\n\nWould echo paths like:\n\n```\n$ npm run tsc\npath/to/example/node_modules/typescript/lib/lib.d.ts\npath/to/example/node_modules/typescript/lib/lib.es5.d.ts\npath/to/example/node_modules/typescript/lib/lib.dom.d.ts\npath/to/example/node_modules/typescript/lib/lib.webworker.importscripts.d.ts\npath/to/example/node_modules/typescript/lib/lib.scripthost.d.ts\npath/to/example/index.ts\n```\n\nNote if using TypeScript 4.2, prefer [`explainFiles`](https://typescriptlang.org/tsconfig/#explainFiles) which offers an explanation of why a file was added too.",

"x-intellij-html-description": "<p>Print names of files part of the compilation. This is useful when you are not sure that TypeScript has\nincluded a file you expected.</p>\n<p>For example:</p>\n<pre><code>example\n├── index.ts\n├── package.json\n└── tsconfig.json\n</code></pre>\n<p>With:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;listFiles&quot;: true\n }\n}\n</code></pre>\n<p>Would echo paths like:</p>\n<pre><code>$ npm run tsc\npath/to/example/node_modules/typescript/lib/lib.d.ts\npath/to/example/node_modules/typescript/lib/lib.es5.d.ts\npath/to/example/node_modules/typescript/lib/lib.dom.d.ts\npath/to/example/node_modules/typescript/lib/lib.webworker.importscripts.d.ts\npath/to/example/node_modules/typescript/lib/lib.scripthost.d.ts\npath/to/example/index.ts\n</code></pre>\n<p>Note if using TypeScript 4.2, prefer <a href=\"https://typescriptlang.org/tsconfig/#explainFiles\"><code>explainFiles</code></a> which offers an explanation of why a file was added too.</p>\n"

},

"mapRoot": {

"description": "Specify the location where debugger should locate map files instead of generated locations.\nThis string is treated verbatim inside the source-map, for example:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"sourceMap\": true,\n \"mapRoot\": \"https://my-website.com/debug/sourcemaps/\"\n }\n}\n```\n\nWould declare that `index.js` will have sourcemaps at `https://my-website.com/debug/sourcemaps/index.js.map`.",

"type": ["string", "null"],

"markdownDescription": "Specify the location where debugger should locate map files instead of generated locations.\nThis string is treated verbatim inside the source-map, for example:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"sourceMap\": true,\n \"mapRoot\": \"https://my-website.com/debug/sourcemaps/\"\n }\n}\n```\n\nWould declare that `index.js` will have sourcemaps at `https://my-website.com/debug/sourcemaps/index.js.map`.",

"x-intellij-html-description": "<p>Specify the location where debugger should locate map files instead of generated locations.\nThis string is treated verbatim inside the source-map, for example:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;sourceMap&quot;: true,\n &quot;mapRoot&quot;: &quot;https://my-website.com/debug/sourcemaps/&quot;\n }\n}\n</code></pre>\n<p>Would declare that <code>index.js</code> will have sourcemaps at <code>https://my-website.com/debug/sourcemaps/index.js.map</code>.</p>\n"

},

"module": {

"description": "Sets the module system for the program. See the [theory behind TypeScript’s `module` option](https://typescriptlang.org/docs/handbook/modules/theory.html#the-module-output-format) and [its reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#the-module-compiler-option) for more information. You very likely want `\"nodenext\"` for modern Node.js projects and `preserve` or `esnext` for code that will be bundled.\n\nChanging `module` affects [`moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution) which [also has a reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option).\n\nHere's some example output for this file:\n\n```ts twoslash\n// @filename: constants.ts\nexport const valueOfPi = 3.142;\n// ---cut---\n// @filename: index.ts\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `CommonJS`\n\n```ts twoslash\n// @showEmit\n// @module: commonjs\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `UMD`\n\n```ts twoslash\n// @showEmit\n// @module: umd\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `AMD`\n\n```ts twoslash\n// @showEmit\n// @module: amd\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `System`\n\n```ts twoslash\n// @showEmit\n// @module: system\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `ESNext`\n\n```ts twoslash\n// @showEmit\n// @module: esnext\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `ES2015`/`ES6`/`ES2020`/`ES2022`\n\n```ts twoslash\n// @showEmit\n// @module: es2015\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\nIn addition to the base functionality of `ES2015`/`ES6`, `ES2020` adds support for [dynamic `import`s](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import), and [`import.meta`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta) while `ES2022` further adds support for [top level `await`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await#top_level_await).\n\n#### `node16`/`node18`/`node20`/`nodenext`\n\nThe `node16`, `node18`, `node20`, and `nodenext` modes integrate with Node's [native ECMAScript Module support](https://nodejs.org/api/esm.html). The emitted JavaScript uses either `CommonJS` or `ES2020` output depending on the file extension and the value of the `type` setting in the nearest `package.json`. Module resolution also works differently. You can learn more in the [handbook](https://typescriptlang.org/docs/handbook/esm-node.html) and [Modules Reference](https://typescriptlang.org/docs/handbook/modules/reference.html#node16-node18-node20-nodenext).\n\n- `node16` is available from TypeScript 4.7\n- `node18` is available from TypeScript 5.8 as a replacement for `node16`, with added support for import attributes.\n- `node20` adds support for require(ESM).\n- `nodenext` is available from TypeScript 4.7, but its behavior changes with the latest stable versions of Node.js. `--module nodenext` implies the floating `--target esnext`.\n\n#### `preserve`\n\nIn `--module preserve` ([added](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-4.html#support-for-require-calls-in---moduleresolution-bundler-and---module-preserve) in TypeScript 5.4), ECMAScript imports and exports written in input files are preserved in the output, and CommonJS-style `import x = require(\"...\")` and `export = ...` statements are emitted as CommonJS `require` and `module.exports`. In other words, the format of each individual import or export statement is preserved, rather than being coerced into a single format for the whole compilation (or even a whole file).\n\n```ts twoslash\n// @showEmit\n// @module: preserve\n// @noErrors\nimport { valueOfPi } from \"./constants\";\nimport constants = require(\"./constants\");\n\nexport const piSquared = valueOfPi * constants.valueOfPi;\n```\n\nWhile it’s rare to need to mix imports and require calls in the same file, this `module` mode best reflects the capabilities of most modern bundlers, as well as the Bun runtime.\n\n> Why care about TypeScript’s `module` emit with a bundler or with Bun, where you’re likely also setting `noEmit`? TypeScript’s type checking and module resolution behavior are affected by the module format that it _would_ emit. Setting `module` gives TypeScript information about how your bundler or runtime will process imports and exports, which ensures that the types you see on imported values accurately reflect what will happen at runtime or after bundling.\n\n#### `None`\n\n```ts twoslash\n// @showEmit\n// @module: none\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```",

"type": ["string", "null"],

"anyOf": [

{

"enum": [

"commonjs",

"amd",

"system",

"umd",

"es6",

"es2015",

"es2020",

"esnext",

"none",

"es2022",

"node16",

"node18",

"node20",

"nodenext",

"preserve"

]

},

{

"pattern": "^([Cc][Oo][Mm][Mm][Oo][Nn][Jj][Ss]|[AaUu][Mm][Dd]|[Ss][Yy][Ss][Tt][Ee][Mm]|[Ee][Ss]([356]|20(1[567]|2[02])|[Nn][Ee][Xx][Tt])|[Nn][Oo][dD][Ee](1[68]|20)|[Nn][Oo][Dd][Ee][Nn][Ee][Xx][Tt]|[Nn][Oo][Nn][Ee]|[Pp][Rr][Ee][Ss][Ee][Rr][Vv][Ee])$"

}

],

"markdownDescription": "Sets the module system for the program. See the [theory behind TypeScript’s `module` option](https://typescriptlang.org/docs/handbook/modules/theory.html#the-module-output-format) and [its reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#the-module-compiler-option) for more information. You very likely want `\"nodenext\"` for modern Node.js projects and `preserve` or `esnext` for code that will be bundled.\n\nChanging `module` affects [`moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution) which [also has a reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option).\n\nHere's some example output for this file:\n\n```ts twoslash\n// @filename: constants.ts\nexport const valueOfPi = 3.142;\n// ---cut---\n// @filename: index.ts\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `CommonJS`\n\n```ts twoslash\n// @showEmit\n// @module: commonjs\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `UMD`\n\n```ts twoslash\n// @showEmit\n// @module: umd\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `AMD`\n\n```ts twoslash\n// @showEmit\n// @module: amd\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `System`\n\n```ts twoslash\n// @showEmit\n// @module: system\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `ESNext`\n\n```ts twoslash\n// @showEmit\n// @module: esnext\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `ES2015`/`ES6`/`ES2020`/`ES2022`\n\n```ts twoslash\n// @showEmit\n// @module: es2015\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\nIn addition to the base functionality of `ES2015`/`ES6`, `ES2020` adds support for [dynamic `import`s](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import), and [`import.meta`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta) while `ES2022` further adds support for [top level `await`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await#top_level_await).\n\n#### `node16`/`node18`/`node20`/`nodenext`\n\nThe `node16`, `node18`, `node20`, and `nodenext` modes integrate with Node's [native ECMAScript Module support](https://nodejs.org/api/esm.html). The emitted JavaScript uses either `CommonJS` or `ES2020` output depending on the file extension and the value of the `type` setting in the nearest `package.json`. Module resolution also works differently. You can learn more in the [handbook](https://typescriptlang.org/docs/handbook/esm-node.html) and [Modules Reference](https://typescriptlang.org/docs/handbook/modules/reference.html#node16-node18-node20-nodenext).\n\n- `node16` is available from TypeScript 4.7\n- `node18` is available from TypeScript 5.8 as a replacement for `node16`, with added support for import attributes.\n- `node20` adds support for require(ESM).\n- `nodenext` is available from TypeScript 4.7, but its behavior changes with the latest stable versions of Node.js. `--module nodenext` implies the floating `--target esnext`.\n\n#### `preserve`\n\nIn `--module preserve` ([added](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-4.html#support-for-require-calls-in---moduleresolution-bundler-and---module-preserve) in TypeScript 5.4), ECMAScript imports and exports written in input files are preserved in the output, and CommonJS-style `import x = require(\"...\")` and `export = ...` statements are emitted as CommonJS `require` and `module.exports`. In other words, the format of each individual import or export statement is preserved, rather than being coerced into a single format for the whole compilation (or even a whole file).\n\n```ts twoslash\n// @showEmit\n// @module: preserve\n// @noErrors\nimport { valueOfPi } from \"./constants\";\nimport constants = require(\"./constants\");\n\nexport const piSquared = valueOfPi * constants.valueOfPi;\n```\n\nWhile it’s rare to need to mix imports and require calls in the same file, this `module` mode best reflects the capabilities of most modern bundlers, as well as the Bun runtime.\n\n> Why care about TypeScript’s `module` emit with a bundler or with Bun, where you’re likely also setting `noEmit`? TypeScript’s type checking and module resolution behavior are affected by the module format that it _would_ emit. Setting `module` gives TypeScript information about how your bundler or runtime will process imports and exports, which ensures that the types you see on imported values accurately reflect what will happen at runtime or after bundling.\n\n#### `None`\n\n```ts twoslash\n// @showEmit\n// @module: none\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```",

"x-intellij-html-description": "<p>Sets the module system for the program. See the <a href=\"https://typescriptlang.org/docs/handbook/modules/theory.html#the-module-output-format\">theory behind TypeScript’s <code>module</code> option</a> and <a href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#the-module-compiler-option\">its reference page</a> for more information. You very likely want <code>&quot;nodenext&quot;</code> for modern Node.js projects and <code>preserve</code> or <code>esnext</code> for code that will be bundled.</p>\n<p>Changing <code>module</code> affects <a href=\"https://typescriptlang.org/tsconfig/#moduleResolution\"><code>moduleResolution</code></a> which <a href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option\">also has a reference page</a>.</p>\n<p>Here&#39;s some example output for this file:</p>\n<pre><code class=\"language-ts\">// @filename: constants.ts\nexport const valueOfPi = 3.142;\n// ---cut---\n// @filename: index.ts\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>CommonJS</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: commonjs\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>UMD</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: umd\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>AMD</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: amd\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>System</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: system\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>ESNext</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: esnext\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>ES2015</code>/<code>ES6</code>/<code>ES2020</code>/<code>ES2022</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: es2015\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<p>In addition to the base functionality of <code>ES2015</code>/<code>ES6</code>, <code>ES2020</code> adds support for <a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import\">dynamic <code>import</code>s</a>, and <a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta\"><code>import.meta</code></a> while <code>ES2022</code> further adds support for <a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await#top_level_await\">top level <code>await</code></a>.</p>\n<h4><code>node16</code>/<code>node18</code>/<code>node20</code>/<code>nodenext</code></h4>\n<p>The <code>node16</code>, <code>node18</code>, <code>node20</code>, and <code>nodenext</code> modes integrate with Node&#39;s <a href=\"https://nodejs.org/api/esm.html\">native ECMAScript Module support</a>. The emitted JavaScript uses either <code>CommonJS</code> or <code>ES2020</code> output depending on the file extension and the value of the <code>type</code> setting in the nearest <code>package.json</code>. Module resolution also works differently. You can learn more in the <a href=\"https://typescriptlang.org/docs/handbook/esm-node.html\">handbook</a> and <a href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#node16-node18-node20-nodenext\">Modules Reference</a>.</p>\n<ul>\n<li><code>node16</code> is available from TypeScript 4.7</li>\n<li><code>node18</code> is available from TypeScript 5.8 as a replacement for <code>node16</code>, with added support for import attributes.</li>\n<li><code>node20</code> adds support for require(ESM).</li>\n<li><code>nodenext</code> is available from TypeScript 4.7, but its behavior changes with the latest stable versions of Node.js. <code>--module nodenext</code> implies the floating <code>--target esnext</code>.</li>\n</ul>\n<h4><code>preserve</code></h4>\n<p>In <code>--module preserve</code> (<a href=\"https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-4.html#support-for-require-calls-in---moduleresolution-bundler-and---module-preserve\">added</a> in TypeScript 5.4), ECMAScript imports and exports written in input files are preserved in the output, and CommonJS-style <code>import x = require(&quot;...&quot;)</code> and <code>export = ...</code> statements are emitted as CommonJS <code>require</code> and <code>module.exports</code>. In other words, the format of each individual import or export statement is preserved, rather than being coerced into a single format for the whole compilation (or even a whole file).</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: preserve\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\nimport constants = require(&quot;./constants&quot;);\n\nexport const piSquared = valueOfPi * constants.valueOfPi;\n</code></pre>\n<p>While it’s rare to need to mix imports and require calls in the same file, this <code>module</code> mode best reflects the capabilities of most modern bundlers, as well as the Bun runtime.</p>\n<blockquote>\n<p>Why care about TypeScript’s <code>module</code> emit with a bundler or with Bun, where you’re likely also setting <code>noEmit</code>? TypeScript’s type checking and module resolution behavior are affected by the module format that it <em>would</em> emit. Setting <code>module</code> gives TypeScript information about how your bundler or runtime will process imports and exports, which ensures that the types you see on imported values accurately reflect what will happen at runtime or after bundling.</p>\n</blockquote>\n<h4><code>None</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: none\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n"

},

"moduleResolution": {

"description": "Specify the module resolution strategy:\n\n- `'node16'` or `'nodenext'` for modern versions of Node.js. Node.js v12 and later supports both ECMAScript imports and CommonJS `require`, which resolve using different algorithms. These `moduleResolution` values, when combined with the corresponding [`module`](https://typescriptlang.org/tsconfig/#module) values, picks the right algorithm for each resolution based on whether Node.js will see an `import` or `require` in the output JavaScript code.\n- `'node10'` (previously called `'node'`) for Node.js versions older than v10, which only support CommonJS `require`. You probably won't need to use `node10` in modern code.\n- `'bundler'` for use with bundlers. Like `node16` and `nodenext`, this mode supports package.json `\"imports\"` and `\"exports\"`, but unlike the Node.js resolution modes, `bundler` never requires file extensions on relative paths in imports.\n- `'classic'` was used in TypeScript before the release of 1.6. `classic` should not be used.\n\nThere are reference pages explaining the [theory behind TypeScript’s module resolution](https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution) and the [details of each option](https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option).",

"type": ["string", "null"],

"anyOf": [

{

"enum": [

"classic",

"node",

"node10",

"node16",

"nodenext",

"bundler"

],

"markdownEnumDescriptions": [

"It’s recommended to use `\"node16\"` instead",

"Deprecated, use `\"node10\"` in TypeScript 5.0+ instead",

"It’s recommended to use `\"node16\"` instead",

"This is the recommended setting for libraries and Node.js applications",

"This is the recommended setting for libraries and Node.js applications",

"This is the recommended setting in TypeScript 5.0+ for applications that use a bundler"

]

},

{

"pattern": "^(([Nn]ode)|([Nn]ode1[06])|([Nn]ode[Nn]ext)|([Cc]lassic)|([Bb]undler))$"

}

],

"markdownDescription": "Specify the module resolution strategy:\n\n- `'node16'` or `'nodenext'` for modern versions of Node.js. Node.js v12 and later supports both ECMAScript imports and CommonJS `require`, which resolve using different algorithms. These `moduleResolution` values, when combined with the corresponding [`module`](https://typescriptlang.org/tsconfig/#module) values, picks the right algorithm for each resolution based on whether Node.js will see an `import` or `require` in the output JavaScript code.\n- `'node10'` (previously called `'node'`) for Node.js versions older than v10, which only support CommonJS `require`. You probably won't need to use `node10` in modern code.\n- `'bundler'` for use with bundlers. Like `node16` and `nodenext`, this mode supports package.json `\"imports\"` and `\"exports\"`, but unlike the Node.js resolution modes, `bundler` never requires file extensions on relative paths in imports.\n- `'classic'` was used in TypeScript before the release of 1.6. `classic` should not be used.\n\nThere are reference pages explaining the [theory behind TypeScript’s module resolution](https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution) and the [details of each option](https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option).",

"x-intellij-html-description": "<p>Specify the module resolution strategy:</p>\n<ul>\n<li><code>&#39;node16&#39;</code> or <code>&#39;nodenext&#39;</code> for modern versions of Node.js. Node.js v12 and later supports both ECMAScript imports and CommonJS <code>require</code>, which resolve using different algorithms. These <code>moduleResolution</code> values, when combined with the corresponding <a href=\"https://typescriptlang.org/tsconfig/#module\"><code>module</code></a> values, picks the right algorithm for each resolution based on whether Node.js will see an <code>import</code> or <code>require</code> in the output JavaScript code.</li>\n<li><code>&#39;node10&#39;</code> (previously called <code>&#39;node&#39;</code>) for Node.js versions older than v10, which only support CommonJS <code>require</code>. You probably won&#39;t need to use <code>node10</code> in modern code.</li>\n<li><code>&#39;bundler&#39;</code> for use with bundlers. Like <code>node16</code> and <code>nodenext</code>, this mode supports package.json <code>&quot;imports&quot;</code> and <code>&quot;exports&quot;</code>, but unlike the Node.js resolution modes, <code>bundler</code> never requires file extensions on relative paths in imports.</li>\n<li><code>&#39;classic&#39;</code> was used in TypeScript before the release of 1.6. <code>classic</code> should not be used.</li>\n</ul>\n<p>There are reference pages explaining the <a href=\"https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution\">theory behind TypeScript’s module resolution</a> and the <a href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option\">details of each option</a>.</p>\n"

},

"moduleSuffixes": {

"description": "Provides a way to override the default list of file name suffixes to search when resolving a module.\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"moduleSuffixes\": [\".ios\", \".native\", \"\"]\n }\n}\n```\n\nGiven the above configuration, an import like the following:\n\n```ts\nimport * as foo from \"./foo\";\n```\n\nTypeScript will look for the relative files `./foo.ios.ts`, `./foo.native.ts`, and finally `./foo.ts`.\n\nNote the empty string `\"\"` in [`moduleSuffixes`](https://typescriptlang.org/tsconfig/#moduleSuffixes) which is necessary for TypeScript to also look-up `./foo.ts`.\n\nThis feature can be useful for React Native projects where each target platform can use a separate tsconfig.json with differing `moduleSuffixes`.",

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string"

},

"markdownDescription": "Provides a way to override the default list of file name suffixes to search when resolving a module.\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"moduleSuffixes\": [\".ios\", \".native\", \"\"]\n }\n}\n```\n\nGiven the above configuration, an import like the following:\n\n```ts\nimport * as foo from \"./foo\";\n```\n\nTypeScript will look for the relative files `./foo.ios.ts`, `./foo.native.ts`, and finally `./foo.ts`.\n\nNote the empty string `\"\"` in [`moduleSuffixes`](https://typescriptlang.org/tsconfig/#moduleSuffixes) which is necessary for TypeScript to also look-up `./foo.ts`.\n\nThis feature can be useful for React Native projects where each target platform can use a separate tsconfig.json with differing `moduleSuffixes`.",

"x-intellij-html-description": "<p>Provides a way to override the default list of file name suffixes to search when resolving a module.</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;moduleSuffixes&quot;: [&quot;.ios&quot;, &quot;.native&quot;, &quot;&quot;]\n }\n}\n</code></pre>\n<p>Given the above configuration, an import like the following:</p>\n<pre><code class=\"language-ts\">import * as foo from &quot;./foo&quot;;\n</code></pre>\n<p>TypeScript will look for the relative files <code>./foo.ios.ts</code>, <code>./foo.native.ts</code>, and finally <code>./foo.ts</code>.</p>\n<p>Note the empty string <code>&quot;&quot;</code> in <a href=\"https://typescriptlang.org/tsconfig/#moduleSuffixes\"><code>moduleSuffixes</code></a> which is necessary for TypeScript to also look-up <code>./foo.ts</code>.</p>\n<p>This feature can be useful for React Native projects where each target platform can use a separate tsconfig.json with differing <code>moduleSuffixes</code>.</p>\n"

},

"newLine": {

"description": "Specify the end of line sequence to be used when emitting files: 'CRLF' (dos) or 'LF' (unix).",

"type": ["string", "null"],

"default": "lf",

"anyOf": [

{

"enum": ["crlf", "lf"]

},

{

"pattern": "^(CRLF|LF|crlf|lf)$"

}

],

"markdownDescription": "Specify the end of line sequence to be used when emitting files: 'CRLF' (dos) or 'LF' (unix).",

"x-intellij-html-description": "<p>Specify the end of line sequence to be used when emitting files: &#39;CRLF&#39; (dos) or &#39;LF&#39; (unix).</p>\n"

},

"noEmit": {

"description": "Do not emit compiler output files like JavaScript source code, source-maps or declarations.\n\nThis makes room for another tool like [Babel](https://babeljs.io/), or [swc](https://github.com/swc-project/swc) to handle converting the TypeScript file to a file which can run inside a JavaScript environment.\n\nYou can then use TypeScript as a tool for providing editor integration, and as a source code type-checker.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Do not emit compiler output files like JavaScript source code, source-maps or declarations.\n\nThis makes room for another tool like [Babel](https://babeljs.io/), or [swc](https://github.com/swc-project/swc) to handle converting the TypeScript file to a file which can run inside a JavaScript environment.\n\nYou can then use TypeScript as a tool for providing editor integration, and as a source code type-checker.",

"x-intellij-html-description": "<p>Do not emit compiler output files like JavaScript source code, source-maps or declarations.</p>\n<p>This makes room for another tool like <a href=\"https://babeljs.io/\">Babel</a>, or <a href=\"https://github.com/swc-project/swc\">swc</a> to handle converting the TypeScript file to a file which can run inside a JavaScript environment.</p>\n<p>You can then use TypeScript as a tool for providing editor integration, and as a source code type-checker.</p>\n"

},

"noEmitHelpers": {

"description": "Instead of importing helpers with [`importHelpers`](https://typescriptlang.org/tsconfig/#importHelpers), you can provide implementations in the global scope for the helpers you use and completely turn off emitting of helper functions.\n\nFor example, using this `async` function in ES5 requires a `await`-like function and `generator`-like function to run:\n\n```ts twoslash\nconst getAPI = async (url: string) => {\n // Get API\n return {};\n};\n```\n\nWhich creates quite a lot of JavaScript:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\nconst getAPI = async (url: string) => {\n // Get API\n return {};\n};\n```\n\nWhich can be switched out with your own globals via this flag:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\n// @noEmitHelpers\nconst getAPI = async (url: string) => {\n // Get API\n return {};\n};\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Instead of importing helpers with [`importHelpers`](https://typescriptlang.org/tsconfig/#importHelpers), you can provide implementations in the global scope for the helpers you use and completely turn off emitting of helper functions.\n\nFor example, using this `async` function in ES5 requires a `await`-like function and `generator`-like function to run:\n\n```ts twoslash\nconst getAPI = async (url: string) => {\n // Get API\n return {};\n};\n```\n\nWhich creates quite a lot of JavaScript:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\nconst getAPI = async (url: string) => {\n // Get API\n return {};\n};\n```\n\nWhich can be switched out with your own globals via this flag:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\n// @noEmitHelpers\nconst getAPI = async (url: string) => {\n // Get API\n return {};\n};\n```",

"x-intellij-html-description": "<p>Instead of importing helpers with <a href=\"https://typescriptlang.org/tsconfig/#importHelpers\"><code>importHelpers</code></a>, you can provide implementations in the global scope for the helpers you use and completely turn off emitting of helper functions.</p>\n<p>For example, using this <code>async</code> function in ES5 requires a <code>await</code>-like function and <code>generator</code>-like function to run:</p>\n<pre><code class=\"language-ts\">const getAPI = async (url: string) =&gt; {\n // Get API\n return {};\n};\n</code></pre>\n<p>Which creates quite a lot of JavaScript:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @target: ES5\nconst getAPI = async (url: string) =&gt; {\n // Get API\n return {};\n};\n</code></pre>\n<p>Which can be switched out with your own globals via this flag:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @target: ES5\n// @noEmitHelpers\nconst getAPI = async (url: string) =&gt; {\n // Get API\n return {};\n};\n</code></pre>\n"

},

"noEmitOnError": {

"description": "Do not emit compiler output files like JavaScript source code, source-maps or declarations if any errors were reported.\n\nThis defaults to `false`, making it easier to work with TypeScript in a watch-like environment where you may want to see results of changes to your code in another environment before making sure all errors are resolved.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Do not emit compiler output files like JavaScript source code, source-maps or declarations if any errors were reported.\n\nThis defaults to `false`, making it easier to work with TypeScript in a watch-like environment where you may want to see results of changes to your code in another environment before making sure all errors are resolved.",

"x-intellij-html-description": "<p>Do not emit compiler output files like JavaScript source code, source-maps or declarations if any errors were reported.</p>\n<p>This defaults to <code>false</code>, making it easier to work with TypeScript in a watch-like environment where you may want to see results of changes to your code in another environment before making sure all errors are resolved.</p>\n"

},

"noImplicitAny": {

"description": "In some cases where no type annotations are present, TypeScript will fall back to a type of `any` for a variable when it cannot infer the type.\n\nThis can cause some errors to be missed, for example:\n\n```ts twoslash\n// @noImplicitAny: false\nfunction fn(s) {\n // No error?\n console.log(s.subtr(3));\n}\nfn(42);\n```\n\nTurning on `noImplicitAny` however TypeScript will issue an error whenever it would have inferred `any`:\n\n```ts twoslash\n// @errors: 7006\nfunction fn(s) {\n console.log(s.subtr(3));\n}\n```",

"type": ["boolean", "null"],

"markdownDescription": "In some cases where no type annotations are present, TypeScript will fall back to a type of `any` for a variable when it cannot infer the type.\n\nThis can cause some errors to be missed, for example:\n\n```ts twoslash\n// @noImplicitAny: false\nfunction fn(s) {\n // No error?\n console.log(s.subtr(3));\n}\nfn(42);\n```\n\nTurning on `noImplicitAny` however TypeScript will issue an error whenever it would have inferred `any`:\n\n```ts twoslash\n// @errors: 7006\nfunction fn(s) {\n console.log(s.subtr(3));\n}\n```",

"x-intellij-html-description": "<p>In some cases where no type annotations are present, TypeScript will fall back to a type of <code>any</code> for a variable when it cannot infer the type.</p>\n<p>This can cause some errors to be missed, for example:</p>\n<pre><code class=\"language-ts\">// @noImplicitAny: false\nfunction fn(s) {\n // No error?\n console.log(s.subtr(3));\n}\nfn(42);\n</code></pre>\n<p>Turning on <code>noImplicitAny</code> however TypeScript will issue an error whenever it would have inferred <code>any</code>:</p>\n<pre><code class=\"language-ts\">// @errors: 7006\nfunction fn(s) {\n console.log(s.subtr(3));\n}\n</code></pre>\n"

},

"noImplicitThis": {

"description": "Raise error on 'this' expressions with an implied 'any' type.\n\nFor example, the class below returns a function which tries to access `this.width` and `this.height` – but the context\nfor `this` inside the function inside `getAreaFunction` is not the instance of the Rectangle.\n\n```ts twoslash\n// @errors: 2683\nclass Rectangle {\n width: number;\n height: number;\n\n constructor(width: number, height: number) {\n this.width = width;\n this.height = height;\n }\n\n getAreaFunction() {\n return function () {\n return this.width * this.height;\n };\n }\n}\n```",

"type": ["boolean", "null"],

"markdownDescription": "Raise error on 'this' expressions with an implied 'any' type.\n\nFor example, the class below returns a function which tries to access `this.width` and `this.height` – but the context\nfor `this` inside the function inside `getAreaFunction` is not the instance of the Rectangle.\n\n```ts twoslash\n// @errors: 2683\nclass Rectangle {\n width: number;\n height: number;\n\n constructor(width: number, height: number) {\n this.width = width;\n this.height = height;\n }\n\n getAreaFunction() {\n return function () {\n return this.width * this.height;\n };\n }\n}\n```",

"x-intellij-html-description": "<p>Raise error on &#39;this&#39; expressions with an implied &#39;any&#39; type.</p>\n<p>For example, the class below returns a function which tries to access <code>this.width</code> and <code>this.height</code> – but the context\nfor <code>this</code> inside the function inside <code>getAreaFunction</code> is not the instance of the Rectangle.</p>\n<pre><code class=\"language-ts\">// @errors: 2683\nclass Rectangle {\n width: number;\n height: number;\n\n constructor(width: number, height: number) {\n this.width = width;\n this.height = height;\n }\n\n getAreaFunction() {\n return function () {\n return this.width * this.height;\n };\n }\n}\n</code></pre>\n"

},

"noUnusedLocals": {

"description": "Report errors on unused local variables.\n\n```ts twoslash\n// @noUnusedLocals\n// @errors: 6133\nconst createKeyboard = (modelID: number) => {\n const defaultModelID = 23;\n return { type: \"keyboard\", modelID };\n};\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Report errors on unused local variables.\n\n```ts twoslash\n// @noUnusedLocals\n// @errors: 6133\nconst createKeyboard = (modelID: number) => {\n const defaultModelID = 23;\n return { type: \"keyboard\", modelID };\n};\n```",

"x-intellij-html-description": "<p>Report errors on unused local variables.</p>\n<pre><code class=\"language-ts\">// @noUnusedLocals\n// @errors: 6133\nconst createKeyboard = (modelID: number) =&gt; {\n const defaultModelID = 23;\n return { type: &quot;keyboard&quot;, modelID };\n};\n</code></pre>\n"

},

"noUnusedParameters": {

"description": "Report errors on unused parameters in functions.\n\n```ts twoslash\n// @noUnusedParameters\n// @errors: 6133\nconst createDefaultKeyboard = (modelID: number) => {\n const defaultModelID = 23;\n return { type: \"keyboard\", modelID: defaultModelID };\n};\n```\n\nParameters declaration with names starting with an underscore (`_`) are exempt from the unused parameter checking. e.g.:\n\n```ts twoslash\n// @noUnusedParameters\nconst createDefaultKeyboard = (_modelID: number) => {\n return { type: \"keyboard\" };\n};\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Report errors on unused parameters in functions.\n\n```ts twoslash\n// @noUnusedParameters\n// @errors: 6133\nconst createDefaultKeyboard = (modelID: number) => {\n const defaultModelID = 23;\n return { type: \"keyboard\", modelID: defaultModelID };\n};\n```\n\nParameters declaration with names starting with an underscore (`_`) are exempt from the unused parameter checking. e.g.:\n\n```ts twoslash\n// @noUnusedParameters\nconst createDefaultKeyboard = (_modelID: number) => {\n return { type: \"keyboard\" };\n};\n```",

"x-intellij-html-description": "<p>Report errors on unused parameters in functions.</p>\n<pre><code class=\"language-ts\">// @noUnusedParameters\n// @errors: 6133\nconst createDefaultKeyboard = (modelID: number) =&gt; {\n const defaultModelID = 23;\n return { type: &quot;keyboard&quot;, modelID: defaultModelID };\n};\n</code></pre>\n<p>Parameters declaration with names starting with an underscore (<code>_</code>) are exempt from the unused parameter checking. e.g.:</p>\n<pre><code class=\"language-ts\">// @noUnusedParameters\nconst createDefaultKeyboard = (_modelID: number) =&gt; {\n return { type: &quot;keyboard&quot; };\n};\n</code></pre>\n"

},

"noLib": {

"description": "Disables the automatic inclusion of any library files.\nIf this option is set, `lib` is ignored.\n\nTypeScript _cannot_ compile anything without a set of interfaces for key primitives like: `Array`, `Boolean`, `Function`, `IArguments`, `Number`, `Object`, `RegExp`, and `String`. It is expected that if you use `noLib` you will be including your own type definitions for these.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Disables the automatic inclusion of any library files.\nIf this option is set, `lib` is ignored.\n\nTypeScript _cannot_ compile anything without a set of interfaces for key primitives like: `Array`, `Boolean`, `Function`, `IArguments`, `Number`, `Object`, `RegExp`, and `String`. It is expected that if you use `noLib` you will be including your own type definitions for these.",

"x-intellij-html-description": "<p>Disables the automatic inclusion of any library files.\nIf this option is set, <code>lib</code> is ignored.</p>\n<p>TypeScript <em>cannot</em> compile anything without a set of interfaces for key primitives like: <code>Array</code>, <code>Boolean</code>, <code>Function</code>, <code>IArguments</code>, <code>Number</code>, <code>Object</code>, <code>RegExp</code>, and <code>String</code>. It is expected that if you use <code>noLib</code> you will be including your own type definitions for these.</p>\n"

},

"noResolve": {

"description": "By default, TypeScript will examine the initial set of files for `import` and `<reference` directives and add these resolved files to your program.\n\nIf `noResolve` is set, this process doesn't happen.\nHowever, `import` statements are still checked to see if they resolve to a valid module, so you'll need to make sure this is satisfied by some other means.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "By default, TypeScript will examine the initial set of files for `import` and `<reference` directives and add these resolved files to your program.\n\nIf `noResolve` is set, this process doesn't happen.\nHowever, `import` statements are still checked to see if they resolve to a valid module, so you'll need to make sure this is satisfied by some other means.",

"x-intellij-html-description": "<p>By default, TypeScript will examine the initial set of files for <code>import</code> and <code>&lt;reference</code> directives and add these resolved files to your program.</p>\n<p>If <code>noResolve</code> is set, this process doesn&#39;t happen.\nHowever, <code>import</code> statements are still checked to see if they resolve to a valid module, so you&#39;ll need to make sure this is satisfied by some other means.</p>\n"

},

"noStrictGenericChecks": {

"description": "TypeScript will unify type parameters when comparing two generic functions.\n\n```ts twoslash\n// @errors: 2322\n\ntype A = <T, U>(x: T, y: U) => [T, U];\ntype B = <S>(x: S, y: S) => [S, S];\n\nfunction f(a: A, b: B) {\n b = a; // Ok\n a = b; // Error\n}\n```\n\nThis flag can be used to remove that check.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "TypeScript will unify type parameters when comparing two generic functions.\n\n```ts twoslash\n// @errors: 2322\n\ntype A = <T, U>(x: T, y: U) => [T, U];\ntype B = <S>(x: S, y: S) => [S, S];\n\nfunction f(a: A, b: B) {\n b = a; // Ok\n a = b; // Error\n}\n```\n\nThis flag can be used to remove that check.",

"x-intellij-html-description": "<p>TypeScript will unify type parameters when comparing two generic functions.</p>\n<pre><code class=\"language-ts\">// @errors: 2322\n\ntype A = &lt;T, U&gt;(x: T, y: U) =&gt; [T, U];\ntype B = &lt;S&gt;(x: S, y: S) =&gt; [S, S];\n\nfunction f(a: A, b: B) {\n b = a; // Ok\n a = b; // Error\n}\n</code></pre>\n<p>This flag can be used to remove that check.</p>\n"

},

"out": {

"description": "Deprecated setting. Use `outFile` instead.",

"type": ["string", "null"],

"markdownDescription": "Deprecated setting. Use `outFile` instead.\n\nSee more: https://www.typescriptlang.org/tsconfig#out"

},

"skipDefaultLibCheck": {

"description": "Use [`skipLibCheck`](https://typescriptlang.org/tsconfig/#skipLibCheck) instead. Skip type checking of default library declaration files.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Use [`skipLibCheck`](https://typescriptlang.org/tsconfig/#skipLibCheck) instead. Skip type checking of default library declaration files.",

"x-intellij-html-description": "<p>Use <a href=\"https://typescriptlang.org/tsconfig/#skipLibCheck\"><code>skipLibCheck</code></a> instead. Skip type checking of default library declaration files.</p>\n"

},

"skipLibCheck": {

"description": "Skip type checking of declaration files.\n\nThis can save time during compilation at the expense of type-system accuracy. For example, two libraries could\ndefine two copies of the same `type` in an inconsistent way. Rather than doing a full check of all `d.ts` files, TypeScript\nwill type check the code you specifically refer to in your app's source code.\n\nA common case where you might think to use `skipLibCheck` is when there are two copies of a library's types in\nyour `node_modules`. In these cases, you should consider using a feature like [yarn's resolutions](https://yarnpkg.com/lang/en/docs/selective-version-resolutions/)\nto ensure there is only one copy of that dependency in your tree or investigate how to ensure there is\nonly one copy by understanding the dependency resolution to fix the issue without additional tooling.\n\nAnother possibility is when you are migrating between TypeScript releases and the changes cause breakages in node_modules and the JS standard libraries which you do not want to deal with during the TypeScript update. \n\nNote, that if these issues come from the TypeScript standard library you can replace the library using [TypeScript 4.5's lib replacement](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#supporting-lib-from-node_modules) technique.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Skip type checking of declaration files.\n\nThis can save time during compilation at the expense of type-system accuracy. For example, two libraries could\ndefine two copies of the same `type` in an inconsistent way. Rather than doing a full check of all `d.ts` files, TypeScript\nwill type check the code you specifically refer to in your app's source code.\n\nA common case where you might think to use `skipLibCheck` is when there are two copies of a library's types in\nyour `node_modules`. In these cases, you should consider using a feature like [yarn's resolutions](https://yarnpkg.com/lang/en/docs/selective-version-resolutions/)\nto ensure there is only one copy of that dependency in your tree or investigate how to ensure there is\nonly one copy by understanding the dependency resolution to fix the issue without additional tooling.\n\nAnother possibility is when you are migrating between TypeScript releases and the changes cause breakages in node_modules and the JS standard libraries which you do not want to deal with during the TypeScript update. \n\nNote, that if these issues come from the TypeScript standard library you can replace the library using [TypeScript 4.5's lib replacement](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#supporting-lib-from-node_modules) technique.",

"x-intellij-html-description": "<p>Skip type checking of declaration files.</p>\n<p>This can save time during compilation at the expense of type-system accuracy. For example, two libraries could\ndefine two copies of the same <code>type</code> in an inconsistent way. Rather than doing a full check of all <code>d.ts</code> files, TypeScript\nwill type check the code you specifically refer to in your app&#39;s source code.</p>\n<p>A common case where you might think to use <code>skipLibCheck</code> is when there are two copies of a library&#39;s types in\nyour <code>node_modules</code>. In these cases, you should consider using a feature like <a href=\"https://yarnpkg.com/lang/en/docs/selective-version-resolutions/\">yarn&#39;s resolutions</a>\nto ensure there is only one copy of that dependency in your tree or investigate how to ensure there is\nonly one copy by understanding the dependency resolution to fix the issue without additional tooling.</p>\n<p>Another possibility is when you are migrating between TypeScript releases and the changes cause breakages in node_modules and the JS standard libraries which you do not want to deal with during the TypeScript update. </p>\n<p>Note, that if these issues come from the TypeScript standard library you can replace the library using <a href=\"https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#supporting-lib-from-node_modules\">TypeScript 4.5&#39;s lib replacement</a> technique.</p>\n"

},

"outFile": {

"description": "If specified, all _global_ (non-module) files will be concatenated into the single output file specified.\n\nIf `module` is `system` or `amd`, all module files will also be concatenated into this file after all global content.\n\nNote: `outFile` cannot be used unless `module` is `None`, `System`, or `AMD`.\nThis option _cannot_ be used to bundle CommonJS or ES6 modules.",

"type": ["string", "null"],

"markdownDescription": "If specified, all _global_ (non-module) files will be concatenated into the single output file specified.\n\nIf `module` is `system` or `amd`, all module files will also be concatenated into this file after all global content.\n\nNote: `outFile` cannot be used unless `module` is `None`, `System`, or `AMD`.\nThis option _cannot_ be used to bundle CommonJS or ES6 modules.",

"x-intellij-html-description": "<p>If specified, all <em>global</em> (non-module) files will be concatenated into the single output file specified.</p>\n<p>If <code>module</code> is <code>system</code> or <code>amd</code>, all module files will also be concatenated into this file after all global content.</p>\n<p>Note: <code>outFile</code> cannot be used unless <code>module</code> is <code>None</code>, <code>System</code>, or <code>AMD</code>.\nThis option <em>cannot</em> be used to bundle CommonJS or ES6 modules.</p>\n"

},

"outDir": {

"description": "If specified, `.js` (as well as `.d.ts`, `.js.map`, etc.) files will be emitted into this directory.\nThe directory structure of the original source files is preserved; see [`rootDir`](https://typescriptlang.org/tsconfig/#rootDir) if the computed root is not what you intended.\n\nIf not specified, `.js` files will be emitted in the same directory as the `.ts` files they were generated from:\n\n```sh\n$ tsc\n\nexample\n├── index.js\n└── index.ts\n```\n\nWith a `tsconfig.json` like this:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"outDir\": \"dist\"\n }\n}\n```\n\nRunning `tsc` with these settings moves the files into the specified `dist` folder:\n\n```sh\n$ tsc\n\nexample\n├── dist\n│ └── index.js\n├── index.ts\n└── tsconfig.json\n```",

"type": ["string", "null"],

"markdownDescription": "If specified, `.js` (as well as `.d.ts`, `.js.map`, etc.) files will be emitted into this directory.\nThe directory structure of the original source files is preserved; see [`rootDir`](https://typescriptlang.org/tsconfig/#rootDir) if the computed root is not what you intended.\n\nIf not specified, `.js` files will be emitted in the same directory as the `.ts` files they were generated from:\n\n```sh\n$ tsc\n\nexample\n├── index.js\n└── index.ts\n```\n\nWith a `tsconfig.json` like this:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"outDir\": \"dist\"\n }\n}\n```\n\nRunning `tsc` with these settings moves the files into the specified `dist` folder:\n\n```sh\n$ tsc\n\nexample\n├── dist\n│ └── index.js\n├── index.ts\n└── tsconfig.json\n```",

"x-intellij-html-description": "<p>If specified, <code>.js</code> (as well as <code>.d.ts</code>, <code>.js.map</code>, etc.) files will be emitted into this directory.\nThe directory structure of the original source files is preserved; see <a href=\"https://typescriptlang.org/tsconfig/#rootDir\"><code>rootDir</code></a> if the computed root is not what you intended.</p>\n<p>If not specified, <code>.js</code> files will be emitted in the same directory as the <code>.ts</code> files they were generated from:</p>\n<pre><code class=\"language-sh\">$ tsc\n\nexample\n├── index.js\n└── index.ts\n</code></pre>\n<p>With a <code>tsconfig.json</code> like this:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;outDir&quot;: &quot;dist&quot;\n }\n}\n</code></pre>\n<p>Running <code>tsc</code> with these settings moves the files into the specified <code>dist</code> folder:</p>\n<pre><code class=\"language-sh\">$ tsc\n\nexample\n├── dist\n│ └── index.js\n├── index.ts\n└── tsconfig.json\n</code></pre>\n"

},

"preserveConstEnums": {

"description": "Do not erase `const enum` declarations in generated code. `const enum`s provide a way to reduce the overall memory footprint\nof your application at runtime by emitting the enum value instead of a reference.\n\nFor example with this TypeScript:\n\n```ts twoslash\nconst enum Album {\n JimmyEatWorldFutures = 1,\n TubRingZooHypothesis = 2,\n DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n console.log(\"That is a great choice.\");\n}\n```\n\nThe default `const enum` behavior is to convert any `Album.Something` to the corresponding number literal, and to remove a reference\nto the enum from the JavaScript completely.\n\n```ts twoslash\n// @showEmit\nconst enum Album {\n JimmyEatWorldFutures = 1,\n TubRingZooHypothesis = 2,\n DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n console.log(\"That is a great choice.\");\n}\n```\n\nWith `preserveConstEnums` set to `true`, the `enum` exists at runtime and the numbers are still emitted.\n\n```ts twoslash\n// @preserveConstEnums: true\n// @showEmit\nconst enum Album {\n JimmyEatWorldFutures = 1,\n TubRingZooHypothesis = 2,\n DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n console.log(\"That is a great choice.\");\n}\n```\n\nThis essentially makes such `const enums` a source-code feature only, with no runtime traces.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Do not erase `const enum` declarations in generated code. `const enum`s provide a way to reduce the overall memory footprint\nof your application at runtime by emitting the enum value instead of a reference.\n\nFor example with this TypeScript:\n\n```ts twoslash\nconst enum Album {\n JimmyEatWorldFutures = 1,\n TubRingZooHypothesis = 2,\n DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n console.log(\"That is a great choice.\");\n}\n```\n\nThe default `const enum` behavior is to convert any `Album.Something` to the corresponding number literal, and to remove a reference\nto the enum from the JavaScript completely.\n\n```ts twoslash\n// @showEmit\nconst enum Album {\n JimmyEatWorldFutures = 1,\n TubRingZooHypothesis = 2,\n DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n console.log(\"That is a great choice.\");\n}\n```\n\nWith `preserveConstEnums` set to `true`, the `enum` exists at runtime and the numbers are still emitted.\n\n```ts twoslash\n// @preserveConstEnums: true\n// @showEmit\nconst enum Album {\n JimmyEatWorldFutures = 1,\n TubRingZooHypothesis = 2,\n DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n console.log(\"That is a great choice.\");\n}\n```\n\nThis essentially makes such `const enums` a source-code feature only, with no runtime traces.",

"x-intellij-html-description": "<p>Do not erase <code>const enum</code> declarations in generated code. <code>const enum</code>s provide a way to reduce the overall memory footprint\nof your application at runtime by emitting the enum value instead of a reference.</p>\n<p>For example with this TypeScript:</p>\n<pre><code class=\"language-ts\">const enum Album {\n JimmyEatWorldFutures = 1,\n TubRingZooHypothesis = 2,\n DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n console.log(&quot;That is a great choice.&quot;);\n}\n</code></pre>\n<p>The default <code>const enum</code> behavior is to convert any <code>Album.Something</code> to the corresponding number literal, and to remove a reference\nto the enum from the JavaScript completely.</p>\n<pre><code class=\"language-ts\">// @showEmit\nconst enum Album {\n JimmyEatWorldFutures = 1,\n TubRingZooHypothesis = 2,\n DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n console.log(&quot;That is a great choice.&quot;);\n}\n</code></pre>\n<p>With <code>preserveConstEnums</code> set to <code>true</code>, the <code>enum</code> exists at runtime and the numbers are still emitted.</p>\n<pre><code class=\"language-ts\">// @preserveConstEnums: true\n// @showEmit\nconst enum Album {\n JimmyEatWorldFutures = 1,\n TubRingZooHypothesis = 2,\n DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n console.log(&quot;That is a great choice.&quot;);\n}\n</code></pre>\n<p>This essentially makes such <code>const enums</code> a source-code feature only, with no runtime traces.</p>\n"

},

"preserveSymlinks": {

"description": "This is to reflect the same flag in Node.js; which does not resolve the real path of symlinks.\n\nThis flag also exhibits the opposite behavior to Webpack’s `resolve.symlinks` option (i.e. setting TypeScript’s `preserveSymlinks` to true parallels setting Webpack’s `resolve.symlinks` to false, and vice-versa).\n\nWith this enabled, references to modules and packages (e.g. `import`s and `/// <reference type=\"...\" />` directives) are all resolved relative to the location of the symbolic link file, rather than relative to the path that the symbolic link resolves to.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "This is to reflect the same flag in Node.js; which does not resolve the real path of symlinks.\n\nThis flag also exhibits the opposite behavior to Webpack’s `resolve.symlinks` option (i.e. setting TypeScript’s `preserveSymlinks` to true parallels setting Webpack’s `resolve.symlinks` to false, and vice-versa).\n\nWith this enabled, references to modules and packages (e.g. `import`s and `/// <reference type=\"...\" />` directives) are all resolved relative to the location of the symbolic link file, rather than relative to the path that the symbolic link resolves to.",

"x-intellij-html-description": "<p>This is to reflect the same flag in Node.js; which does not resolve the real path of symlinks.</p>\n<p>This flag also exhibits the opposite behavior to Webpack’s <code>resolve.symlinks</code> option (i.e. setting TypeScript’s <code>preserveSymlinks</code> to true parallels setting Webpack’s <code>resolve.symlinks</code> to false, and vice-versa).</p>\n<p>With this enabled, references to modules and packages (e.g. <code>import</code>s and <code>/// &lt;reference type=&quot;...&quot; /&gt;</code> directives) are all resolved relative to the location of the symbolic link file, rather than relative to the path that the symbolic link resolves to.</p>\n"

},

"preserveValueImports": {

"description": "Deprecated in favor of [`verbatimModuleSyntax`](https://typescriptlang.org/tsconfig/#verbatimModuleSyntax).\n\nThere are some cases where TypeScript can't detect that you're using an import. For example, take the following code:\n\n```ts\nimport { Animal } from \"./animal.js\";\n\neval(\"console.log(new Animal().isDangerous())\");\n```\n\nor code using 'Compiles to HTML' languages like Svelte or Vue. `preserveValueImports` will prevent TypeScript from removing the import, even if it appears unused.\n\nWhen combined with [`isolatedModules`](https://typescriptlang.org/tsconfig/#isolatedModules): imported types _must_ be marked as type-only because compilers that process single files at a time have no way of knowing whether imports are values that appear unused, or a type that must be removed in order to avoid a runtime crash.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Deprecated in favor of [`verbatimModuleSyntax`](https://typescriptlang.org/tsconfig/#verbatimModuleSyntax).\n\nThere are some cases where TypeScript can't detect that you're using an import. For example, take the following code:\n\n```ts\nimport { Animal } from \"./animal.js\";\n\neval(\"console.log(new Animal().isDangerous())\");\n```\n\nor code using 'Compiles to HTML' languages like Svelte or Vue. `preserveValueImports` will prevent TypeScript from removing the import, even if it appears unused.\n\nWhen combined with [`isolatedModules`](https://typescriptlang.org/tsconfig/#isolatedModules): imported types _must_ be marked as type-only because compilers that process single files at a time have no way of knowing whether imports are values that appear unused, or a type that must be removed in order to avoid a runtime crash.",

"x-intellij-html-description": "<p>Deprecated in favor of <a href=\"https://typescriptlang.org/tsconfig/#verbatimModuleSyntax\"><code>verbatimModuleSyntax</code></a>.</p>\n<p>There are some cases where TypeScript can&#39;t detect that you&#39;re using an import. For example, take the following code:</p>\n<pre><code class=\"language-ts\">import { Animal } from &quot;./animal.js&quot;;\n\neval(&quot;console.log(new Animal().isDangerous())&quot;);\n</code></pre>\n<p>or code using &#39;Compiles to HTML&#39; languages like Svelte or Vue. <code>preserveValueImports</code> will prevent TypeScript from removing the import, even if it appears unused.</p>\n<p>When combined with <a href=\"https://typescriptlang.org/tsconfig/#isolatedModules\"><code>isolatedModules</code></a>: imported types <em>must</em> be marked as type-only because compilers that process single files at a time have no way of knowing whether imports are values that appear unused, or a type that must be removed in order to avoid a runtime crash.</p>\n"

},

"preserveWatchOutput": {

"description": "Whether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.",

"type": ["boolean", "null"],

"markdownDescription": "Whether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.",

"x-intellij-html-description": "<p>Whether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.</p>\n"

},

"pretty": {

"description": "Stylize errors and messages using color and context, this is on by default &mdash; offers you a chance to have less terse,\nsingle colored messages from the compiler.",

"type": ["boolean", "null"],

"default": true,

"markdownDescription": "Stylize errors and messages using color and context, this is on by default &mdash; offers you a chance to have less terse,\nsingle colored messages from the compiler.",

"x-intellij-html-description": "<p>Stylize errors and messages using color and context, this is on by default &mdash; offers you a chance to have less terse,\nsingle colored messages from the compiler.</p>\n"

},

"removeComments": {

"description": "Strips all comments from TypeScript files when converting into JavaScript. Defaults to `false`.\n\nFor example, this is a TypeScript file which has a JSDoc comment:\n\n```ts\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nWhen `removeComments` is set to `true`:\n\n```ts twoslash\n// @showEmit\n// @removeComments: true\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nWithout setting `removeComments` or having it as `false`:\n\n```ts twoslash\n// @showEmit\n// @removeComments: false\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nThis means that your comments will show up in the JavaScript code.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Strips all comments from TypeScript files when converting into JavaScript. Defaults to `false`.\n\nFor example, this is a TypeScript file which has a JSDoc comment:\n\n```ts\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nWhen `removeComments` is set to `true`:\n\n```ts twoslash\n// @showEmit\n// @removeComments: true\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nWithout setting `removeComments` or having it as `false`:\n\n```ts twoslash\n// @showEmit\n// @removeComments: false\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nThis means that your comments will show up in the JavaScript code.",

"x-intellij-html-description": "<p>Strips all comments from TypeScript files when converting into JavaScript. Defaults to <code>false</code>.</p>\n<p>For example, this is a TypeScript file which has a JSDoc comment:</p>\n<pre><code class=\"language-ts\">/** The translation of &#39;Hello world&#39; into Portuguese */\nexport const helloWorldPTBR = &quot;Olá Mundo&quot;;\n</code></pre>\n<p>When <code>removeComments</code> is set to <code>true</code>:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @removeComments: true\n/** The translation of &#39;Hello world&#39; into Portuguese */\nexport const helloWorldPTBR = &quot;Olá Mundo&quot;;\n</code></pre>\n<p>Without setting <code>removeComments</code> or having it as <code>false</code>:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @removeComments: false\n/** The translation of &#39;Hello world&#39; into Portuguese */\nexport const helloWorldPTBR = &quot;Olá Mundo&quot;;\n</code></pre>\n<p>This means that your comments will show up in the JavaScript code.</p>\n"

},

"rewriteRelativeImportExtensions": {

"description": "Rewrite `.ts`, `.tsx`, `.mts`, and `.cts` file extensions in relative import paths to their JavaScript equivalent in output files.\n \nFor more information, see the [TypeScript 5.7 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-5-7.html#path-rewriting-for-relative-paths).",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Rewrite `.ts`, `.tsx`, `.mts`, and `.cts` file extensions in relative import paths to their JavaScript equivalent in output files.\n \nFor more information, see the [TypeScript 5.7 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-5-7.html#path-rewriting-for-relative-paths).",

"x-intellij-html-description": "<p>Rewrite <code>.ts</code>, <code>.tsx</code>, <code>.mts</code>, and <code>.cts</code> file extensions in relative import paths to their JavaScript equivalent in output files.</p>\n<p>For more information, see the <a href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-5-7.html#path-rewriting-for-relative-paths\">TypeScript 5.7 release notes</a>.</p>\n"

},

"rootDir": {

"description": "**Default**: The longest common path of all non-declaration input files. If [`composite`](https://typescriptlang.org/tsconfig/#composite) is set, the default is instead the directory containing the `tsconfig.json` file.\n\nWhen TypeScript compiles files, it keeps the same directory structure in the output directory as exists in the input directory.\n\nFor example, let's say you have some input files:\n\n```\nMyProj\n├── tsconfig.json\n├── core\n│ ├── a.ts\n│ ├── b.ts\n│ ├── sub\n│ │ ├── c.ts\n├── types.d.ts\n```\n\nThe inferred value for `rootDir` is the longest common path of all non-declaration input files, which in this case is `core/`.\n\nIf your [`outDir`](https://typescriptlang.org/tsconfig/#outDir) was `dist`, TypeScript would write this tree:\n\n```\nMyProj\n├── dist\n│ ├── a.js\n│ ├── b.js\n│ ├── sub\n│ │ ├── c.js\n```\n\nHowever, you may have intended for `core` to be part of the output directory structure.\nBy setting `rootDir: \".\"` in `tsconfig.json`, TypeScript would write this tree:\n\n```\nMyProj\n├── dist\n│ ├── core\n│ │ ├── a.js\n│ │ ├── b.js\n│ │ ├── sub\n│ │ │ ├── c.js\n```\n\nImportantly, `rootDir` **does not affect which files become part of the compilation**.\nIt has no interaction with the [`include`](https://typescriptlang.org/tsconfig/#include), [`exclude`](https://typescriptlang.org/tsconfig/#exclude), or [`files`](https://typescriptlang.org/tsconfig/#files) `tsconfig.json` settings.\n\nNote that TypeScript will never write an output file to a directory outside of [`outDir`](https://typescriptlang.org/tsconfig/#outDir), and will never skip emitting a file.\nFor this reason, `rootDir` also enforces that all files which need to be emitted are underneath the `rootDir` path.\n\nFor example, let's say you had this tree:\n\n```\nMyProj\n├── tsconfig.json\n├── core\n│ ├── a.ts\n│ ├── b.ts\n├── helpers.ts\n```\n\nIt would be an error to specify `rootDir` as `core` _and_ [`include`](https://typescriptlang.org/tsconfig/#include) as `*` because it creates a file (`helpers.ts`) that would need to be emitted _outside_ the [`outDir`](https://typescriptlang.org/tsconfig/#outDir) (i.e. `../helpers.js`).",

"type": ["string", "null"],

"markdownDescription": "**Default**: The longest common path of all non-declaration input files. If [`composite`](https://typescriptlang.org/tsconfig/#composite) is set, the default is instead the directory containing the `tsconfig.json` file.\n\nWhen TypeScript compiles files, it keeps the same directory structure in the output directory as exists in the input directory.\n\nFor example, let's say you have some input files:\n\n```\nMyProj\n├── tsconfig.json\n├── core\n│ ├── a.ts\n│ ├── b.ts\n│ ├── sub\n│ │ ├── c.ts\n├── types.d.ts\n```\n\nThe inferred value for `rootDir` is the longest common path of all non-declaration input files, which in this case is `core/`.\n\nIf your [`outDir`](https://typescriptlang.org/tsconfig/#outDir) was `dist`, TypeScript would write this tree:\n\n```\nMyProj\n├── dist\n│ ├── a.js\n│ ├── b.js\n│ ├── sub\n│ │ ├── c.js\n```\n\nHowever, you may have intended for `core` to be part of the output directory structure.\nBy setting `rootDir: \".\"` in `tsconfig.json`, TypeScript would write this tree:\n\n```\nMyProj\n├── dist\n│ ├── core\n│ │ ├── a.js\n│ │ ├── b.js\n│ │ ├── sub\n│ │ │ ├── c.js\n```\n\nImportantly, `rootDir` **does not affect which files become part of the compilation**.\nIt has no interaction with the [`include`](https://typescriptlang.org/tsconfig/#include), [`exclude`](https://typescriptlang.org/tsconfig/#exclude), or [`files`](https://typescriptlang.org/tsconfig/#files) `tsconfig.json` settings.\n\nNote that TypeScript will never write an output file to a directory outside of [`outDir`](https://typescriptlang.org/tsconfig/#outDir), and will never skip emitting a file.\nFor this reason, `rootDir` also enforces that all files which need to be emitted are underneath the `rootDir` path.\n\nFor example, let's say you had this tree:\n\n```\nMyProj\n├── tsconfig.json\n├── core\n│ ├── a.ts\n│ ├── b.ts\n├── helpers.ts\n```\n\nIt would be an error to specify `rootDir` as `core` _and_ [`include`](https://typescriptlang.org/tsconfig/#include) as `*` because it creates a file (`helpers.ts`) that would need to be emitted _outside_ the [`outDir`](https://typescriptlang.org/tsconfig/#outDir) (i.e. `../helpers.js`).",

"x-intellij-html-description": "<p><strong>Default</strong>: The longest common path of all non-declaration input files. If <a href=\"https://typescriptlang.org/tsconfig/#composite\"><code>composite</code></a> is set, the default is instead the directory containing the <code>tsconfig.json</code> file.</p>\n<p>When TypeScript compiles files, it keeps the same directory structure in the output directory as exists in the input directory.</p>\n<p>For example, let&#39;s say you have some input files:</p>\n<pre><code>MyProj\n├── tsconfig.json\n├── core\n│ ├── a.ts\n│ ├── b.ts\n│ ├── sub\n│ │ ├── c.ts\n├── types.d.ts\n</code></pre>\n<p>The inferred value for <code>rootDir</code> is the longest common path of all non-declaration input files, which in this case is <code>core/</code>.</p>\n<p>If your <a href=\"https://typescriptlang.org/tsconfig/#outDir\"><code>outDir</code></a> was <code>dist</code>, TypeScript would write this tree:</p>\n<pre><code>MyProj\n├── dist\n│ ├── a.js\n│ ├── b.js\n│ ├── sub\n│ │ ├── c.js\n</code></pre>\n<p>However, you may have intended for <code>core</code> to be part of the output directory structure.\nBy setting <code>rootDir: &quot;.&quot;</code> in <code>tsconfig.json</code>, TypeScript would write this tree:</p>\n<pre><code>MyProj\n├── dist\n│ ├── core\n│ │ ├── a.js\n│ │ ├── b.js\n│ │ ├── sub\n│ │ │ ├── c.js\n</code></pre>\n<p>Importantly, <code>rootDir</code> <strong>does not affect which files become part of the compilation</strong>.\nIt has no interaction with the <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a>, <a href=\"https://typescriptlang.org/tsconfig/#exclude\"><code>exclude</code></a>, or <a href=\"https://typescriptlang.org/tsconfig/#files\"><code>files</code></a> <code>tsconfig.json</code> settings.</p>\n<p>Note that TypeScript will never write an output file to a directory outside of <a href=\"https://typescriptlang.org/tsconfig/#outDir\"><code>outDir</code></a>, and will never skip emitting a file.\nFor this reason, <code>rootDir</code> also enforces that all files which need to be emitted are underneath the <code>rootDir</code> path.</p>\n<p>For example, let&#39;s say you had this tree:</p>\n<pre><code>MyProj\n├── tsconfig.json\n├── core\n│ ├── a.ts\n│ ├── b.ts\n├── helpers.ts\n</code></pre>\n<p>It would be an error to specify <code>rootDir</code> as <code>core</code> <em>and</em> <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a> as <code>*</code> because it creates a file (<code>helpers.ts</code>) that would need to be emitted <em>outside</em> the <a href=\"https://typescriptlang.org/tsconfig/#outDir\"><code>outDir</code></a> (i.e. <code>../helpers.js</code>).</p>\n"

},

"isolatedModules": {

"description": "While you can use TypeScript to produce JavaScript code from TypeScript code, it's also common to use other transpilers such as [Babel](https://babeljs.io/) to do this.\nHowever, other transpilers only operate on a single file at a time, which means they can't apply code transforms that depend on understanding the full type system.\nThis restriction also applies to TypeScript's `ts.transpileModule` API which is used by some build tools.\n\nThese limitations can cause runtime problems with some TypeScript features like `const enum`s and `namespace`s.\nSetting the `isolatedModules` flag tells TypeScript to warn you if you write certain code that can't be correctly interpreted by a single-file transpilation process.\n\nIt does not change the behavior of your code, or otherwise change the behavior of TypeScript's checking and emitting process.\n\nSome examples of code which does not work when `isolatedModules` is enabled.\n\n#### Exports of Non-Value Identifiers\n\nIn TypeScript, you can import a _type_ and then subsequently export it:\n\n```ts twoslash\n// @noErrors\nimport { someType, someFunction } from \"someModule\";\n\nsomeFunction();\n\nexport { someType, someFunction };\n```\n\nBecause there's no value for `someType`, the emitted `export` will not try to export it (this would be a runtime error in JavaScript):\n\n```js\nexport { someFunction };\n```\n\nSingle-file transpilers don't know whether `someType` produces a value or not, so it's an error to export a name that only refers to a type.\n\n#### Non-Module Files\n\nIf `isolatedModules` is set, namespaces are only allowed in _modules_ (which means it has some form of `import`/`export`). An error occurs if a namespace is found in a non-module file:\n\n```ts twoslash\n// @errors: 1277\n// @isolatedModules\nnamespace Instantiated {\n export const x = 1;\n}\n```\n\nThis restriction doesn't apply to `.d.ts` files.\n\n#### References to `const enum` members\n\nIn TypeScript, when you reference a `const enum` member, the reference is replaced by its actual value in the emitted JavaScript. Changing this TypeScript:\n\n```ts twoslash\ndeclare const enum Numbers {\n Zero = 0,\n One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n```\n\nTo this JavaScript:\n\n```ts twoslash\n// @showEmit\n// @removeComments\ndeclare const enum Numbers {\n Zero = 0,\n One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n```\n\nWithout knowledge of the values of these members, other transpilers can't replace the references to `Numbers`, which would be a runtime error if left alone (since there are no `Numbers` object at runtime).\nBecause of this, when `isolatedModules` is set, it is an error to reference an ambient `const enum` member.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "While you can use TypeScript to produce JavaScript code from TypeScript code, it's also common to use other transpilers such as [Babel](https://babeljs.io/) to do this.\nHowever, other transpilers only operate on a single file at a time, which means they can't apply code transforms that depend on understanding the full type system.\nThis restriction also applies to TypeScript's `ts.transpileModule` API which is used by some build tools.\n\nThese limitations can cause runtime problems with some TypeScript features like `const enum`s and `namespace`s.\nSetting the `isolatedModules` flag tells TypeScript to warn you if you write certain code that can't be correctly interpreted by a single-file transpilation process.\n\nIt does not change the behavior of your code, or otherwise change the behavior of TypeScript's checking and emitting process.\n\nSome examples of code which does not work when `isolatedModules` is enabled.\n\n#### Exports of Non-Value Identifiers\n\nIn TypeScript, you can import a _type_ and then subsequently export it:\n\n```ts twoslash\n// @noErrors\nimport { someType, someFunction } from \"someModule\";\n\nsomeFunction();\n\nexport { someType, someFunction };\n```\n\nBecause there's no value for `someType`, the emitted `export` will not try to export it (this would be a runtime error in JavaScript):\n\n```js\nexport { someFunction };\n```\n\nSingle-file transpilers don't know whether `someType` produces a value or not, so it's an error to export a name that only refers to a type.\n\n#### Non-Module Files\n\nIf `isolatedModules` is set, namespaces are only allowed in _modules_ (which means it has some form of `import`/`export`). An error occurs if a namespace is found in a non-module file:\n\n```ts twoslash\n// @errors: 1277\n// @isolatedModules\nnamespace Instantiated {\n export const x = 1;\n}\n```\n\nThis restriction doesn't apply to `.d.ts` files.\n\n#### References to `const enum` members\n\nIn TypeScript, when you reference a `const enum` member, the reference is replaced by its actual value in the emitted JavaScript. Changing this TypeScript:\n\n```ts twoslash\ndeclare const enum Numbers {\n Zero = 0,\n One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n```\n\nTo this JavaScript:\n\n```ts twoslash\n// @showEmit\n// @removeComments\ndeclare const enum Numbers {\n Zero = 0,\n One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n```\n\nWithout knowledge of the values of these members, other transpilers can't replace the references to `Numbers`, which would be a runtime error if left alone (since there are no `Numbers` object at runtime).\nBecause of this, when `isolatedModules` is set, it is an error to reference an ambient `const enum` member.",

"x-intellij-html-description": "<p>While you can use TypeScript to produce JavaScript code from TypeScript code, it&#39;s also common to use other transpilers such as <a href=\"https://babeljs.io/\">Babel</a> to do this.\nHowever, other transpilers only operate on a single file at a time, which means they can&#39;t apply code transforms that depend on understanding the full type system.\nThis restriction also applies to TypeScript&#39;s <code>ts.transpileModule</code> API which is used by some build tools.</p>\n<p>These limitations can cause runtime problems with some TypeScript features like <code>const enum</code>s and <code>namespace</code>s.\nSetting the <code>isolatedModules</code> flag tells TypeScript to warn you if you write certain code that can&#39;t be correctly interpreted by a single-file transpilation process.</p>\n<p>It does not change the behavior of your code, or otherwise change the behavior of TypeScript&#39;s checking and emitting process.</p>\n<p>Some examples of code which does not work when <code>isolatedModules</code> is enabled.</p>\n<h4>Exports of Non-Value Identifiers</h4>\n<p>In TypeScript, you can import a <em>type</em> and then subsequently export it:</p>\n<pre><code class=\"language-ts\">// @noErrors\nimport { someType, someFunction } from &quot;someModule&quot;;\n\nsomeFunction();\n\nexport { someType, someFunction };\n</code></pre>\n<p>Because there&#39;s no value for <code>someType</code>, the emitted <code>export</code> will not try to export it (this would be a runtime error in JavaScript):</p>\n<pre><code class=\"language-js\">export { someFunction };\n</code></pre>\n<p>Single-file transpilers don&#39;t know whether <code>someType</code> produces a value or not, so it&#39;s an error to export a name that only refers to a type.</p>\n<h4>Non-Module Files</h4>\n<p>If <code>isolatedModules</code> is set, namespaces are only allowed in <em>modules</em> (which means it has some form of <code>import</code>/<code>export</code>). An error occurs if a namespace is found in a non-module file:</p>\n<pre><code class=\"language-ts\">// @errors: 1277\n// @isolatedModules\nnamespace Instantiated {\n export const x = 1;\n}\n</code></pre>\n<p>This restriction doesn&#39;t apply to <code>.d.ts</code> files.</p>\n<h4>References to <code>const enum</code> members</h4>\n<p>In TypeScript, when you reference a <code>const enum</code> member, the reference is replaced by its actual value in the emitted JavaScript. Changing this TypeScript:</p>\n<pre><code class=\"language-ts\">declare const enum Numbers {\n Zero = 0,\n One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n</code></pre>\n<p>To this JavaScript:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @removeComments\ndeclare const enum Numbers {\n Zero = 0,\n One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n</code></pre>\n<p>Without knowledge of the values of these members, other transpilers can&#39;t replace the references to <code>Numbers</code>, which would be a runtime error if left alone (since there are no <code>Numbers</code> object at runtime).\nBecause of this, when <code>isolatedModules</code> is set, it is an error to reference an ambient <code>const enum</code> member.</p>\n"

},

"sourceMap": {

"description": "Enables the generation of [sourcemap files](https://developer.mozilla.org/docs/Tools/Debugger/How_to/Use_a_source_map).\nThese files allow debuggers and other tools to display the original TypeScript source code when actually working with the emitted JavaScript files.\nSource map files are emitted as `.js.map` (or `.jsx.map`) files next to the corresponding `.js` output file.\n\nThe `.js` files will in turn contain a sourcemap comment to indicate where the files are to external tools, for example:\n\n```ts\n// helloWorld.ts\nexport declare const helloWorld = \"hi\";\n```\n\nCompiling with `sourceMap` set to `true` creates the following JavaScript file:\n\n```js\n// helloWorld.js\n\"use strict\";\nObject.defineProperty(exports, \"__esModule\", { value: true });\nexports.helloWorld = \"hi\";\n//# sourceMappingURL=// helloWorld.js.map\n```\n\nAnd this also generates this json map:\n\n```json\n// helloWorld.js.map\n{\n \"version\": 3,\n \"file\": \"ex.js\",\n \"sourceRoot\": \"\",\n \"sources\": [\"../ex.ts\"],\n \"names\": [],\n \"mappings\": \";;AAAa,QAAA,UAAU,GAAG,IAAI,CAAA\"\n}\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Enables the generation of [sourcemap files](https://developer.mozilla.org/docs/Tools/Debugger/How_to/Use_a_source_map).\nThese files allow debuggers and other tools to display the original TypeScript source code when actually working with the emitted JavaScript files.\nSource map files are emitted as `.js.map` (or `.jsx.map`) files next to the corresponding `.js` output file.\n\nThe `.js` files will in turn contain a sourcemap comment to indicate where the files are to external tools, for example:\n\n```ts\n// helloWorld.ts\nexport declare const helloWorld = \"hi\";\n```\n\nCompiling with `sourceMap` set to `true` creates the following JavaScript file:\n\n```js\n// helloWorld.js\n\"use strict\";\nObject.defineProperty(exports, \"__esModule\", { value: true });\nexports.helloWorld = \"hi\";\n//# sourceMappingURL=// helloWorld.js.map\n```\n\nAnd this also generates this json map:\n\n```json\n// helloWorld.js.map\n{\n \"version\": 3,\n \"file\": \"ex.js\",\n \"sourceRoot\": \"\",\n \"sources\": [\"../ex.ts\"],\n \"names\": [],\n \"mappings\": \";;AAAa,QAAA,UAAU,GAAG,IAAI,CAAA\"\n}\n```",

"x-intellij-html-description": "<p>Enables the generation of <a href=\"https://developer.mozilla.org/docs/Tools/Debugger/How_to/Use_a_source_map\">sourcemap files</a>.\nThese files allow debuggers and other tools to display the original TypeScript source code when actually working with the emitted JavaScript files.\nSource map files are emitted as <code>.js.map</code> (or <code>.jsx.map</code>) files next to the corresponding <code>.js</code> output file.</p>\n<p>The <code>.js</code> files will in turn contain a sourcemap comment to indicate where the files are to external tools, for example:</p>\n<pre><code class=\"language-ts\">// helloWorld.ts\nexport declare const helloWorld = &quot;hi&quot;;\n</code></pre>\n<p>Compiling with <code>sourceMap</code> set to <code>true</code> creates the following JavaScript file:</p>\n<pre><code class=\"language-js\">// helloWorld.js\n&quot;use strict&quot;;\nObject.defineProperty(exports, &quot;__esModule&quot;, { value: true });\nexports.helloWorld = &quot;hi&quot;;\n//# sourceMappingURL=// helloWorld.js.map\n</code></pre>\n<p>And this also generates this json map:</p>\n<pre><code class=\"language-json\">// helloWorld.js.map\n{\n &quot;version&quot;: 3,\n &quot;file&quot;: &quot;ex.js&quot;,\n &quot;sourceRoot&quot;: &quot;&quot;,\n &quot;sources&quot;: [&quot;../ex.ts&quot;],\n &quot;names&quot;: [],\n &quot;mappings&quot;: &quot;;;AAAa,QAAA,UAAU,GAAG,IAAI,CAAA&quot;\n}\n</code></pre>\n"

},

"sourceRoot": {

"description": "Specify the location where a debugger should locate TypeScript files instead of relative source locations.\nThis string is treated verbatim inside the source-map where you can use a path or a URL:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"sourceMap\": true,\n \"sourceRoot\": \"https://my-website.com/debug/source/\"\n }\n}\n```\n\nWould declare that `index.js` will have a source file at `https://my-website.com/debug/source/index.ts`.",

"type": ["string", "null"],

"markdownDescription": "Specify the location where a debugger should locate TypeScript files instead of relative source locations.\nThis string is treated verbatim inside the source-map where you can use a path or a URL:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"sourceMap\": true,\n \"sourceRoot\": \"https://my-website.com/debug/source/\"\n }\n}\n```\n\nWould declare that `index.js` will have a source file at `https://my-website.com/debug/source/index.ts`.",

"x-intellij-html-description": "<p>Specify the location where a debugger should locate TypeScript files instead of relative source locations.\nThis string is treated verbatim inside the source-map where you can use a path or a URL:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;sourceMap&quot;: true,\n &quot;sourceRoot&quot;: &quot;https://my-website.com/debug/source/&quot;\n }\n}\n</code></pre>\n<p>Would declare that <code>index.js</code> will have a source file at <code>https://my-website.com/debug/source/index.ts</code>.</p>\n"

},

"suppressExcessPropertyErrors": {

"description": "This disables reporting of excess property errors, such as the one shown in the following example:\n\n```ts twoslash\n// @errors: 2322\ntype Point = { x: number; y: number };\nconst p: Point = { x: 1, y: 3, m: 10 };\n```\n\nThis flag was added to help people migrate to the stricter checking of new object literals in [TypeScript 1.6](https://typescriptlang.org/docs/handbook/release-notes/typescript-1-6.html#stricter-object-literal-assignment-checks).\n\nWe don't recommend using this flag in a modern codebase, you can suppress one-off cases where you need it using `// @ts-ignore`.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "This disables reporting of excess property errors, such as the one shown in the following example:\n\n```ts twoslash\n// @errors: 2322\ntype Point = { x: number; y: number };\nconst p: Point = { x: 1, y: 3, m: 10 };\n```\n\nThis flag was added to help people migrate to the stricter checking of new object literals in [TypeScript 1.6](https://typescriptlang.org/docs/handbook/release-notes/typescript-1-6.html#stricter-object-literal-assignment-checks).\n\nWe don't recommend using this flag in a modern codebase, you can suppress one-off cases where you need it using `// @ts-ignore`.",

"x-intellij-html-description": "<p>This disables reporting of excess property errors, such as the one shown in the following example:</p>\n<pre><code class=\"language-ts\">// @errors: 2322\ntype Point = { x: number; y: number };\nconst p: Point = { x: 1, y: 3, m: 10 };\n</code></pre>\n<p>This flag was added to help people migrate to the stricter checking of new object literals in <a href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-1-6.html#stricter-object-literal-assignment-checks\">TypeScript 1.6</a>.</p>\n<p>We don&#39;t recommend using this flag in a modern codebase, you can suppress one-off cases where you need it using <code>// @ts-ignore</code>.</p>\n"

},

"suppressImplicitAnyIndexErrors": {

"description": "Turning `suppressImplicitAnyIndexErrors` on suppresses reporting the error about implicit anys when indexing into objects, as shown in the following example:\n\n```ts twoslash\n// @noImplicitAny: true\n// @suppressImplicitAnyIndexErrors: false\n// @strict: true\n// @errors: 7053\nconst obj = { x: 10 };\nconsole.log(obj[\"foo\"]);\n```\n\nUsing `suppressImplicitAnyIndexErrors` is quite a drastic approach. It is recommended to use a `@ts-ignore` comment instead:\n\n```ts twoslash\n// @noImplicitAny: true\n// @strict: true\nconst obj = { x: 10 };\n// @ts-ignore\nconsole.log(obj[\"foo\"]);\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Turning `suppressImplicitAnyIndexErrors` on suppresses reporting the error about implicit anys when indexing into objects, as shown in the following example:\n\n```ts twoslash\n// @noImplicitAny: true\n// @suppressImplicitAnyIndexErrors: false\n// @strict: true\n// @errors: 7053\nconst obj = { x: 10 };\nconsole.log(obj[\"foo\"]);\n```\n\nUsing `suppressImplicitAnyIndexErrors` is quite a drastic approach. It is recommended to use a `@ts-ignore` comment instead:\n\n```ts twoslash\n// @noImplicitAny: true\n// @strict: true\nconst obj = { x: 10 };\n// @ts-ignore\nconsole.log(obj[\"foo\"]);\n```",

"x-intellij-html-description": "<p>Turning <code>suppressImplicitAnyIndexErrors</code> on suppresses reporting the error about implicit anys when indexing into objects, as shown in the following example:</p>\n<pre><code class=\"language-ts\">// @noImplicitAny: true\n// @suppressImplicitAnyIndexErrors: false\n// @strict: true\n// @errors: 7053\nconst obj = { x: 10 };\nconsole.log(obj[&quot;foo&quot;]);\n</code></pre>\n<p>Using <code>suppressImplicitAnyIndexErrors</code> is quite a drastic approach. It is recommended to use a <code>@ts-ignore</code> comment instead:</p>\n<pre><code class=\"language-ts\">// @noImplicitAny: true\n// @strict: true\nconst obj = { x: 10 };\n// @ts-ignore\nconsole.log(obj[&quot;foo&quot;]);\n</code></pre>\n"

},

"stripInternal": {

"description": "Do not emit declarations for code that has an `@internal` annotation in its JSDoc comment.\nThis is an internal compiler option; use at your own risk, because the compiler does not check that the result is valid.\nIf you are searching for a tool to handle additional levels of visibility within your `d.ts` files, look at [api-extractor](https://api-extractor.com/).\n\n```ts twoslash\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n return daysInAWeek * dayRate;\n}\n```\n\nWith the flag set to `false` (default):\n\n```ts twoslash\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n return daysInAWeek * dayRate;\n}\n```\n\nWith `stripInternal` set to `true` the `d.ts` emitted will be redacted.\n\n```ts twoslash\n// @stripinternal\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n return daysInAWeek * dayRate;\n}\n```\n\nThe JavaScript output is still the same.",

"type": ["boolean", "null"],

"markdownDescription": "Do not emit declarations for code that has an `@internal` annotation in its JSDoc comment.\nThis is an internal compiler option; use at your own risk, because the compiler does not check that the result is valid.\nIf you are searching for a tool to handle additional levels of visibility within your `d.ts` files, look at [api-extractor](https://api-extractor.com/).\n\n```ts twoslash\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n return daysInAWeek * dayRate;\n}\n```\n\nWith the flag set to `false` (default):\n\n```ts twoslash\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n return daysInAWeek * dayRate;\n}\n```\n\nWith `stripInternal` set to `true` the `d.ts` emitted will be redacted.\n\n```ts twoslash\n// @stripinternal\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n return daysInAWeek * dayRate;\n}\n```\n\nThe JavaScript output is still the same.",

"x-intellij-html-description": "<p>Do not emit declarations for code that has an <code>@internal</code> annotation in its JSDoc comment.\nThis is an internal compiler option; use at your own risk, because the compiler does not check that the result is valid.\nIf you are searching for a tool to handle additional levels of visibility within your <code>d.ts</code> files, look at <a href=\"https://api-extractor.com/\">api-extractor</a>.</p>\n<pre><code class=\"language-ts\">/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n return daysInAWeek * dayRate;\n}\n</code></pre>\n<p>With the flag set to <code>false</code> (default):</p>\n<pre><code class=\"language-ts\">// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n return daysInAWeek * dayRate;\n}\n</code></pre>\n<p>With <code>stripInternal</code> set to <code>true</code> the <code>d.ts</code> emitted will be redacted.</p>\n<pre><code class=\"language-ts\">// @stripinternal\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n return daysInAWeek * dayRate;\n}\n</code></pre>\n<p>The JavaScript output is still the same.</p>\n"

},

"target": {

"description": "Modern browsers support all ES6 features, so `ES6` is a good choice.\nYou might choose to set a lower target if your code is deployed to older environments, or a higher target if your code is guaranteed to run in newer environments.\n\nThe `target` setting changes which JS features are downleveled and which are left intact.\nFor example, an arrow function `() => this` will be turned into an equivalent `function` expression if `target` is ES5 or lower.\n\nChanging `target` also changes the default value of [`lib`](https://typescriptlang.org/tsconfig/#lib).\nYou may \"mix and match\" `target` and `lib` settings as desired, but you could just set `target` for convenience.\n\nFor developer platforms like Node there are baselines for the `target`, depending on the type of platform and its version. You can find a set of community organized TSConfigs at [tsconfig/bases](https://github.com/tsconfig/bases#centralized-recommendations-for-tsconfig-bases), which has configurations for common platforms and their versions.\n\nThe special `ESNext` value refers to the highest version your version of TypeScript supports.\nThis setting should be used with caution, since it doesn't mean the same thing between different TypeScript versions and can make upgrades less predictable.",

"type": ["string", "null"],

"default": "es5",

"anyOf": [

{

"enum": [

"es3",

"es5",

"es6",

"es2015",

"es2016",

"es2017",

"es2018",

"es2019",

"es2020",

"es2021",

"es2022",

"es2023",

"es2024",

"es2025",

"esnext"

]

},

{

"pattern": "^([Ee][Ss]([356]|(20(1[56789]|2[012345]))|[Nn][Ee][Xx][Tt]))$"

}

],

"markdownDescription": "Modern browsers support all ES6 features, so `ES6` is a good choice.\nYou might choose to set a lower target if your code is deployed to older environments, or a higher target if your code is guaranteed to run in newer environments.\n\nThe `target` setting changes which JS features are downleveled and which are left intact.\nFor example, an arrow function `() => this` will be turned into an equivalent `function` expression if `target` is ES5 or lower.\n\nChanging `target` also changes the default value of [`lib`](https://typescriptlang.org/tsconfig/#lib).\nYou may \"mix and match\" `target` and `lib` settings as desired, but you could just set `target` for convenience.\n\nFor developer platforms like Node there are baselines for the `target`, depending on the type of platform and its version. You can find a set of community organized TSConfigs at [tsconfig/bases](https://github.com/tsconfig/bases#centralized-recommendations-for-tsconfig-bases), which has configurations for common platforms and their versions.\n\nThe special `ESNext` value refers to the highest version your version of TypeScript supports.\nThis setting should be used with caution, since it doesn't mean the same thing between different TypeScript versions and can make upgrades less predictable.",

"x-intellij-html-description": "<p>Modern browsers support all ES6 features, so <code>ES6</code> is a good choice.\nYou might choose to set a lower target if your code is deployed to older environments, or a higher target if your code is guaranteed to run in newer environments.</p>\n<p>The <code>target</code> setting changes which JS features are downleveled and which are left intact.\nFor example, an arrow function <code>() =&gt; this</code> will be turned into an equivalent <code>function</code> expression if <code>target</code> is ES5 or lower.</p>\n<p>Changing <code>target</code> also changes the default value of <a href=\"https://typescriptlang.org/tsconfig/#lib\"><code>lib</code></a>.\nYou may &quot;mix and match&quot; <code>target</code> and <code>lib</code> settings as desired, but you could just set <code>target</code> for convenience.</p>\n<p>For developer platforms like Node there are baselines for the <code>target</code>, depending on the type of platform and its version. You can find a set of community organized TSConfigs at <a href=\"https://github.com/tsconfig/bases#centralized-recommendations-for-tsconfig-bases\">tsconfig/bases</a>, which has configurations for common platforms and their versions.</p>\n<p>The special <code>ESNext</code> value refers to the highest version your version of TypeScript supports.\nThis setting should be used with caution, since it doesn&#39;t mean the same thing between different TypeScript versions and can make upgrades less predictable.</p>\n"

},

"useUnknownInCatchVariables": {

"description": "In TypeScript 4.0, support was added to allow changing the type of the variable in a catch clause from `any` to `unknown`. Allowing for code like:\n\n```ts twoslash\n// @useUnknownInCatchVariables\ntry {\n // ...\n} catch (err: unknown) {\n // We have to verify err is an\n // error before using it as one.\n if (err instanceof Error) {\n console.log(err.message);\n }\n}\n```\n\nThis pattern ensures that error handling code becomes more comprehensive because you cannot guarantee that the object being thrown _is_ a Error subclass ahead of time. With the flag `useUnknownInCatchVariables` enabled, then you do not need the additional syntax (`: unknown`) nor a linter rule to try enforce this behavior.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "In TypeScript 4.0, support was added to allow changing the type of the variable in a catch clause from `any` to `unknown`. Allowing for code like:\n\n```ts twoslash\n// @useUnknownInCatchVariables\ntry {\n // ...\n} catch (err: unknown) {\n // We have to verify err is an\n // error before using it as one.\n if (err instanceof Error) {\n console.log(err.message);\n }\n}\n```\n\nThis pattern ensures that error handling code becomes more comprehensive because you cannot guarantee that the object being thrown _is_ a Error subclass ahead of time. With the flag `useUnknownInCatchVariables` enabled, then you do not need the additional syntax (`: unknown`) nor a linter rule to try enforce this behavior.",

"x-intellij-html-description": "<p>In TypeScript 4.0, support was added to allow changing the type of the variable in a catch clause from <code>any</code> to <code>unknown</code>. Allowing for code like:</p>\n<pre><code class=\"language-ts\">// @useUnknownInCatchVariables\ntry {\n // ...\n} catch (err: unknown) {\n // We have to verify err is an\n // error before using it as one.\n if (err instanceof Error) {\n console.log(err.message);\n }\n}\n</code></pre>\n<p>This pattern ensures that error handling code becomes more comprehensive because you cannot guarantee that the object being thrown <em>is</em> a Error subclass ahead of time. With the flag <code>useUnknownInCatchVariables</code> enabled, then you do not need the additional syntax (<code>: unknown</code>) nor a linter rule to try enforce this behavior.</p>\n"

},

"watch": {

"description": "Watch input files.",

"type": ["boolean", "null"]

},

"fallbackPolling": {

"description": "Specify the polling strategy to use when the system runs out of or doesn't support native file watchers. Requires TypeScript version 3.8 or later.",

"enum": [

"fixedPollingInterval",

"priorityPollingInterval",

"dynamicPriorityPolling",

"fixedInterval",

"priorityInterval",

"dynamicPriority",

"fixedChunkSize"

]

},

"watchDirectory": {

"description": "Specify the strategy for watching directories under systems that lack recursive file-watching functionality. Requires TypeScript version 3.8 or later.",

"enum": [

"useFsEvents",

"fixedPollingInterval",

"dynamicPriorityPolling",

"fixedChunkSizePolling"

],

"default": "useFsEvents"

},

"watchFile": {

"description": "Specify the strategy for watching individual files. Requires TypeScript version 3.8 or later.",

"enum": [

"fixedPollingInterval",

"priorityPollingInterval",

"dynamicPriorityPolling",

"useFsEvents",

"useFsEventsOnParentDirectory",

"fixedChunkSizePolling"

],

"default": "useFsEvents"

},

"experimentalDecorators": {

"description": "Enables [experimental support for decorators](https://github.com/tc39/proposal-decorators), which is a version of decorators that predates the TC39 standardization process.\n\nDecorators are a language feature which hasn't yet been fully ratified into the JavaScript specification.\nThis means that the implementation version in TypeScript may differ from the implementation in JavaScript when it is decided by TC39.\n\nYou can find out more about decorator support in TypeScript in [the handbook](https://typescriptlang.org/docs/handbook/decorators.html).",

"type": ["boolean", "null"],

"markdownDescription": "Enables [experimental support for decorators](https://github.com/tc39/proposal-decorators), which is a version of decorators that predates the TC39 standardization process.\n\nDecorators are a language feature which hasn't yet been fully ratified into the JavaScript specification.\nThis means that the implementation version in TypeScript may differ from the implementation in JavaScript when it is decided by TC39.\n\nYou can find out more about decorator support in TypeScript in [the handbook](https://typescriptlang.org/docs/handbook/decorators.html).",

"x-intellij-html-description": "<p>Enables <a href=\"https://github.com/tc39/proposal-decorators\">experimental support for decorators</a>, which is a version of decorators that predates the TC39 standardization process.</p>\n<p>Decorators are a language feature which hasn&#39;t yet been fully ratified into the JavaScript specification.\nThis means that the implementation version in TypeScript may differ from the implementation in JavaScript when it is decided by TC39.</p>\n<p>You can find out more about decorator support in TypeScript in <a href=\"https://typescriptlang.org/docs/handbook/decorators.html\">the handbook</a>.</p>\n"

},

"emitDecoratorMetadata": {

"description": "Enables experimental support for emitting type metadata for decorators which works with the module [`reflect-metadata`](https://www.npmjs.com/package/reflect-metadata).\n\nFor example, here is the TypeScript\n\n```ts twoslash\n// @experimentalDecorators\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n console.log(target);\n console.log(propertyKey);\n console.log(descriptor);\n}\n\nclass Demo {\n @LogMethod\n public foo(bar: number) {\n // do nothing\n }\n}\n\nconst demo = new Demo();\n```\n\nWith `emitDecoratorMetadata` not set to true (default) the emitted JavaScript is:\n\n```ts twoslash\n// @experimentalDecorators\n// @showEmit\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n console.log(target);\n console.log(propertyKey);\n console.log(descriptor);\n}\n\nclass Demo {\n @LogMethod\n public foo(bar: number) {\n // do nothing\n }\n}\n\nconst demo = new Demo();\n```\n\nWith `emitDecoratorMetadata` set to true the emitted JavaScript is:\n\n```ts twoslash\n// @experimentalDecorators\n// @showEmit\n// @emitDecoratorMetadata\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n console.log(target);\n console.log(propertyKey);\n console.log(descriptor);\n}\n\nclass Demo {\n @LogMethod\n public foo(bar: number) {\n // do nothing\n }\n}\n\nconst demo = new Demo();\n```",

"type": ["boolean", "null"],

"markdownDescription": "Enables experimental support for emitting type metadata for decorators which works with the module [`reflect-metadata`](https://www.npmjs.com/package/reflect-metadata).\n\nFor example, here is the TypeScript\n\n```ts twoslash\n// @experimentalDecorators\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n console.log(target);\n console.log(propertyKey);\n console.log(descriptor);\n}\n\nclass Demo {\n @LogMethod\n public foo(bar: number) {\n // do nothing\n }\n}\n\nconst demo = new Demo();\n```\n\nWith `emitDecoratorMetadata` not set to true (default) the emitted JavaScript is:\n\n```ts twoslash\n// @experimentalDecorators\n// @showEmit\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n console.log(target);\n console.log(propertyKey);\n console.log(descriptor);\n}\n\nclass Demo {\n @LogMethod\n public foo(bar: number) {\n // do nothing\n }\n}\n\nconst demo = new Demo();\n```\n\nWith `emitDecoratorMetadata` set to true the emitted JavaScript is:\n\n```ts twoslash\n// @experimentalDecorators\n// @showEmit\n// @emitDecoratorMetadata\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n console.log(target);\n console.log(propertyKey);\n console.log(descriptor);\n}\n\nclass Demo {\n @LogMethod\n public foo(bar: number) {\n // do nothing\n }\n}\n\nconst demo = new Demo();\n```",

"x-intellij-html-description": "<p>Enables experimental support for emitting type metadata for decorators which works with the module <a href=\"https://www.npmjs.com/package/reflect-metadata\"><code>reflect-metadata</code></a>.</p>\n<p>For example, here is the TypeScript</p>\n<pre><code class=\"language-ts\">// @experimentalDecorators\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n console.log(target);\n console.log(propertyKey);\n console.log(descriptor);\n}\n\nclass Demo {\n @LogMethod\n public foo(bar: number) {\n // do nothing\n }\n}\n\nconst demo = new Demo();\n</code></pre>\n<p>With <code>emitDecoratorMetadata</code> not set to true (default) the emitted JavaScript is:</p>\n<pre><code class=\"language-ts\">// @experimentalDecorators\n// @showEmit\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n console.log(target);\n console.log(propertyKey);\n console.log(descriptor);\n}\n\nclass Demo {\n @LogMethod\n public foo(bar: number) {\n // do nothing\n }\n}\n\nconst demo = new Demo();\n</code></pre>\n<p>With <code>emitDecoratorMetadata</code> set to true the emitted JavaScript is:</p>\n<pre><code class=\"language-ts\">// @experimentalDecorators\n// @showEmit\n// @emitDecoratorMetadata\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n console.log(target);\n console.log(propertyKey);\n console.log(descriptor);\n}\n\nclass Demo {\n @LogMethod\n public foo(bar: number) {\n // do nothing\n }\n}\n\nconst demo = new Demo();\n</code></pre>\n"

},

"allowUnusedLabels": {

"description": "When:\n\n- `undefined` (default) provide suggestions as warnings to editors\n- `true` unused labels are ignored\n- `false` raises compiler errors about unused labels\n\nLabels are very rare in JavaScript and typically indicate an attempt to write an object literal:\n\n```ts twoslash\n// @errors: 7028\n// @allowUnusedLabels: false\nfunction verifyAge(age: number) {\n // Forgot 'return' statement\n if (age > 18) {\n verified: true;\n }\n}\n```",

"type": ["boolean", "null"],

"markdownDescription": "When:\n\n- `undefined` (default) provide suggestions as warnings to editors\n- `true` unused labels are ignored\n- `false` raises compiler errors about unused labels\n\nLabels are very rare in JavaScript and typically indicate an attempt to write an object literal:\n\n```ts twoslash\n// @errors: 7028\n// @allowUnusedLabels: false\nfunction verifyAge(age: number) {\n // Forgot 'return' statement\n if (age > 18) {\n verified: true;\n }\n}\n```",

"x-intellij-html-description": "<p>When:</p>\n<ul>\n<li><code>undefined</code> (default) provide suggestions as warnings to editors</li>\n<li><code>true</code> unused labels are ignored</li>\n<li><code>false</code> raises compiler errors about unused labels</li>\n</ul>\n<p>Labels are very rare in JavaScript and typically indicate an attempt to write an object literal:</p>\n<pre><code class=\"language-ts\">// @errors: 7028\n// @allowUnusedLabels: false\nfunction verifyAge(age: number) {\n // Forgot &#39;return&#39; statement\n if (age &gt; 18) {\n verified: true;\n }\n}\n</code></pre>\n"

},

"noImplicitReturns": {

"description": "When enabled, TypeScript will check all code paths in a function to ensure they return a value.\n\n```ts twoslash\n// @errors: 2366 2322\nfunction lookupHeadphonesManufacturer(color: \"blue\" | \"black\"): string {\n if (color === \"blue\") {\n return \"beats\";\n } else {\n \"bose\";\n }\n}\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "When enabled, TypeScript will check all code paths in a function to ensure they return a value.\n\n```ts twoslash\n// @errors: 2366 2322\nfunction lookupHeadphonesManufacturer(color: \"blue\" | \"black\"): string {\n if (color === \"blue\") {\n return \"beats\";\n } else {\n \"bose\";\n }\n}\n```",

"x-intellij-html-description": "<p>When enabled, TypeScript will check all code paths in a function to ensure they return a value.</p>\n<pre><code class=\"language-ts\">// @errors: 2366 2322\nfunction lookupHeadphonesManufacturer(color: &quot;blue&quot; | &quot;black&quot;): string {\n if (color === &quot;blue&quot;) {\n return &quot;beats&quot;;\n } else {\n &quot;bose&quot;;\n }\n}\n</code></pre>\n"

},

"noUncheckedIndexedAccess": {

"description": "TypeScript has a way to describe objects which have unknown keys but known values on an object, via index signatures.\n\n```ts twoslash\ninterface EnvironmentVars {\n NAME: string;\n OS: string;\n\n // Unknown properties are covered by this index signature.\n [propName: string]: string;\n}\n\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n// ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^?\n```\n\nTurning on `noUncheckedIndexedAccess` will add `undefined` to any un-declared field in the type.\n\n```ts twoslash\ninterface EnvironmentVars {\n NAME: string;\n OS: string;\n\n // Unknown properties are covered by this index signature.\n [propName: string]: string;\n}\n// @noUncheckedIndexedAccess\n// ---cut---\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n// ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^?\n```",

"type": ["boolean", "null"],

"markdownDescription": "TypeScript has a way to describe objects which have unknown keys but known values on an object, via index signatures.\n\n```ts twoslash\ninterface EnvironmentVars {\n NAME: string;\n OS: string;\n\n // Unknown properties are covered by this index signature.\n [propName: string]: string;\n}\n\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n// ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^?\n```\n\nTurning on `noUncheckedIndexedAccess` will add `undefined` to any un-declared field in the type.\n\n```ts twoslash\ninterface EnvironmentVars {\n NAME: string;\n OS: string;\n\n // Unknown properties are covered by this index signature.\n [propName: string]: string;\n}\n// @noUncheckedIndexedAccess\n// ---cut---\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n// ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^?\n```",

"x-intellij-html-description": "<p>TypeScript has a way to describe objects which have unknown keys but known values on an object, via index signatures.</p>\n<pre><code class=\"language-ts\">interface EnvironmentVars {\n NAME: string;\n OS: string;\n\n // Unknown properties are covered by this index signature.\n [propName: string]: string;\n}\n\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n// ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^?\n</code></pre>\n<p>Turning on <code>noUncheckedIndexedAccess</code> will add <code>undefined</code> to any un-declared field in the type.</p>\n<pre><code class=\"language-ts\">interface EnvironmentVars {\n NAME: string;\n OS: string;\n\n // Unknown properties are covered by this index signature.\n [propName: string]: string;\n}\n// @noUncheckedIndexedAccess\n// ---cut---\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n// ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^?\n</code></pre>\n"

},

"noFallthroughCasesInSwitch": {

"description": "Report errors for fallthrough cases in switch statements.\nEnsures that any non-empty case inside a switch statement includes either `break`, `return`, or `throw`.\nThis means you won't accidentally ship a case fallthrough bug.\n\n```ts twoslash\n// @noFallthroughCasesInSwitch\n// @errors: 7029\nconst a: number = 6;\n\nswitch (a) {\n case 0:\n console.log(\"even\");\n case 1:\n console.log(\"odd\");\n break;\n}\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Report errors for fallthrough cases in switch statements.\nEnsures that any non-empty case inside a switch statement includes either `break`, `return`, or `throw`.\nThis means you won't accidentally ship a case fallthrough bug.\n\n```ts twoslash\n// @noFallthroughCasesInSwitch\n// @errors: 7029\nconst a: number = 6;\n\nswitch (a) {\n case 0:\n console.log(\"even\");\n case 1:\n console.log(\"odd\");\n break;\n}\n```",

"x-intellij-html-description": "<p>Report errors for fallthrough cases in switch statements.\nEnsures that any non-empty case inside a switch statement includes either <code>break</code>, <code>return</code>, or <code>throw</code>.\nThis means you won&#39;t accidentally ship a case fallthrough bug.</p>\n<pre><code class=\"language-ts\">// @noFallthroughCasesInSwitch\n// @errors: 7029\nconst a: number = 6;\n\nswitch (a) {\n case 0:\n console.log(&quot;even&quot;);\n case 1:\n console.log(&quot;odd&quot;);\n break;\n}\n</code></pre>\n"

},

"noImplicitOverride": {

"description": "When working with classes which use inheritance, it's possible for a sub-class to get \"out of sync\" with the functions it overloads when they are renamed in the base class.\n\nFor example, imagine you are modeling a music album syncing system:\n\n```ts twoslash\nclass Album {\n download() {\n // Default behavior\n }\n}\n\nclass SharedAlbum extends Album {\n download() {\n // Override to get info from many sources\n }\n}\n```\n\nThen when you add support for machine-learning generated playlists, you refactor the `Album` class to have a 'setup' function instead:\n\n```ts twoslash\nclass Album {\n setup() {\n // Default behavior\n }\n}\n\nclass MLAlbum extends Album {\n setup() {\n // Override to get info from algorithm\n }\n}\n\nclass SharedAlbum extends Album {\n download() {\n // Override to get info from many sources\n }\n}\n```\n\nIn this case, TypeScript has provided no warning that `download` on `SharedAlbum` _expected_ to override a function in the base class.\n\nUsing `noImplicitOverride` you can ensure that the sub-classes never go out of sync, by ensuring that functions which override include the keyword `override`.\n\nThe following example has `noImplicitOverride` enabled, and you can see the error received when `override` is missing:\n\n```ts twoslash\n// @noImplicitOverride\n// @errors: 4114\nclass Album {\n setup() {}\n}\n\nclass MLAlbum extends Album {\n override setup() {}\n}\n\nclass SharedAlbum extends Album {\n setup() {}\n}\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "When working with classes which use inheritance, it's possible for a sub-class to get \"out of sync\" with the functions it overloads when they are renamed in the base class.\n\nFor example, imagine you are modeling a music album syncing system:\n\n```ts twoslash\nclass Album {\n download() {\n // Default behavior\n }\n}\n\nclass SharedAlbum extends Album {\n download() {\n // Override to get info from many sources\n }\n}\n```\n\nThen when you add support for machine-learning generated playlists, you refactor the `Album` class to have a 'setup' function instead:\n\n```ts twoslash\nclass Album {\n setup() {\n // Default behavior\n }\n}\n\nclass MLAlbum extends Album {\n setup() {\n // Override to get info from algorithm\n }\n}\n\nclass SharedAlbum extends Album {\n download() {\n // Override to get info from many sources\n }\n}\n```\n\nIn this case, TypeScript has provided no warning that `download` on `SharedAlbum` _expected_ to override a function in the base class.\n\nUsing `noImplicitOverride` you can ensure that the sub-classes never go out of sync, by ensuring that functions which override include the keyword `override`.\n\nThe following example has `noImplicitOverride` enabled, and you can see the error received when `override` is missing:\n\n```ts twoslash\n// @noImplicitOverride\n// @errors: 4114\nclass Album {\n setup() {}\n}\n\nclass MLAlbum extends Album {\n override setup() {}\n}\n\nclass SharedAlbum extends Album {\n setup() {}\n}\n```",

"x-intellij-html-description": "<p>When working with classes which use inheritance, it&#39;s possible for a sub-class to get &quot;out of sync&quot; with the functions it overloads when they are renamed in the base class.</p>\n<p>For example, imagine you are modeling a music album syncing system:</p>\n<pre><code class=\"language-ts\">class Album {\n download() {\n // Default behavior\n }\n}\n\nclass SharedAlbum extends Album {\n download() {\n // Override to get info from many sources\n }\n}\n</code></pre>\n<p>Then when you add support for machine-learning generated playlists, you refactor the <code>Album</code> class to have a &#39;setup&#39; function instead:</p>\n<pre><code class=\"language-ts\">class Album {\n setup() {\n // Default behavior\n }\n}\n\nclass MLAlbum extends Album {\n setup() {\n // Override to get info from algorithm\n }\n}\n\nclass SharedAlbum extends Album {\n download() {\n // Override to get info from many sources\n }\n}\n</code></pre>\n<p>In this case, TypeScript has provided no warning that <code>download</code> on <code>SharedAlbum</code> <em>expected</em> to override a function in the base class.</p>\n<p>Using <code>noImplicitOverride</code> you can ensure that the sub-classes never go out of sync, by ensuring that functions which override include the keyword <code>override</code>.</p>\n<p>The following example has <code>noImplicitOverride</code> enabled, and you can see the error received when <code>override</code> is missing:</p>\n<pre><code class=\"language-ts\">// @noImplicitOverride\n// @errors: 4114\nclass Album {\n setup() {}\n}\n\nclass MLAlbum extends Album {\n override setup() {}\n}\n\nclass SharedAlbum extends Album {\n setup() {}\n}\n</code></pre>\n"

},

"allowUnreachableCode": {

"description": "When:\n\n- `undefined` (default) provide suggestions as warnings to editors\n- `true` unreachable code is ignored\n- `false` raises compiler errors about unreachable code\n\nThese warnings are only about code which is provably unreachable due to the use of JavaScript syntax, for example:\n\n```ts\nfunction fn(n: number) {\n if (n > 5) {\n return true;\n } else {\n return false;\n }\n return true;\n}\n```\n\nWith `\"allowUnreachableCode\": false`:\n\n```ts twoslash\n// @errors: 7027\n// @allowUnreachableCode: false\nfunction fn(n: number) {\n if (n > 5) {\n return true;\n } else {\n return false;\n }\n return true;\n}\n```\n\nThis does not affect errors on the basis of code which _appears_ to be unreachable due to type analysis.",

"type": ["boolean", "null"],

"markdownDescription": "When:\n\n- `undefined` (default) provide suggestions as warnings to editors\n- `true` unreachable code is ignored\n- `false` raises compiler errors about unreachable code\n\nThese warnings are only about code which is provably unreachable due to the use of JavaScript syntax, for example:\n\n```ts\nfunction fn(n: number) {\n if (n > 5) {\n return true;\n } else {\n return false;\n }\n return true;\n}\n```\n\nWith `\"allowUnreachableCode\": false`:\n\n```ts twoslash\n// @errors: 7027\n// @allowUnreachableCode: false\nfunction fn(n: number) {\n if (n > 5) {\n return true;\n } else {\n return false;\n }\n return true;\n}\n```\n\nThis does not affect errors on the basis of code which _appears_ to be unreachable due to type analysis.",

"x-intellij-html-description": "<p>When:</p>\n<ul>\n<li><code>undefined</code> (default) provide suggestions as warnings to editors</li>\n<li><code>true</code> unreachable code is ignored</li>\n<li><code>false</code> raises compiler errors about unreachable code</li>\n</ul>\n<p>These warnings are only about code which is provably unreachable due to the use of JavaScript syntax, for example:</p>\n<pre><code class=\"language-ts\">function fn(n: number) {\n if (n &gt; 5) {\n return true;\n } else {\n return false;\n }\n return true;\n}\n</code></pre>\n<p>With <code>&quot;allowUnreachableCode&quot;: false</code>:</p>\n<pre><code class=\"language-ts\">// @errors: 7027\n// @allowUnreachableCode: false\nfunction fn(n: number) {\n if (n &gt; 5) {\n return true;\n } else {\n return false;\n }\n return true;\n}\n</code></pre>\n<p>This does not affect errors on the basis of code which <em>appears</em> to be unreachable due to type analysis.</p>\n"

},

"forceConsistentCasingInFileNames": {

"description": "TypeScript follows the case sensitivity rules of the file system it's running on.\nThis can be problematic if some developers are working in a case-sensitive file system and others aren't.\nIf a file attempts to import `fileManager.ts` by specifying `./FileManager.ts` the file will be found in a case-insensitive file system, but not on a case-sensitive file system.\n\nWhen this option is set, TypeScript will issue an error if a program tries to include a file by a casing different from the casing on disk.",

"type": ["boolean", "null"],

"default": true,

"markdownDescription": "TypeScript follows the case sensitivity rules of the file system it's running on.\nThis can be problematic if some developers are working in a case-sensitive file system and others aren't.\nIf a file attempts to import `fileManager.ts` by specifying `./FileManager.ts` the file will be found in a case-insensitive file system, but not on a case-sensitive file system.\n\nWhen this option is set, TypeScript will issue an error if a program tries to include a file by a casing different from the casing on disk.",

"x-intellij-html-description": "<p>TypeScript follows the case sensitivity rules of the file system it&#39;s running on.\nThis can be problematic if some developers are working in a case-sensitive file system and others aren&#39;t.\nIf a file attempts to import <code>fileManager.ts</code> by specifying <code>./FileManager.ts</code> the file will be found in a case-insensitive file system, but not on a case-sensitive file system.</p>\n<p>When this option is set, TypeScript will issue an error if a program tries to include a file by a casing different from the casing on disk.</p>\n"

},

"generateCpuProfile": {

"description": "This option gives you the chance to have TypeScript emit a v8 CPU profile during the compiler run. The CPU profile can provide insight into why your builds may be slow.\n\nThis option can only be used from the CLI via: `--generateCpuProfile tsc-output.cpuprofile`.\n\n```sh\nnpm run tsc --generateCpuProfile tsc-output.cpuprofile\n```\n\nThis file can be opened in a chromium based browser like Chrome or Edge Developer in [the CPU profiler](https://developers.google.com/web/tools/chrome-devtools/rendering-tools/js-execution) section.\nYou can learn more about understanding the compilers performance in the [TypeScript wiki section on performance](https://github.com/microsoft/TypeScript/wiki/Performance).",

"type": ["string", "null"],

"default": "profile.cpuprofile",

"markdownDescription": "This option gives you the chance to have TypeScript emit a v8 CPU profile during the compiler run. The CPU profile can provide insight into why your builds may be slow.\n\nThis option can only be used from the CLI via: `--generateCpuProfile tsc-output.cpuprofile`.\n\n```sh\nnpm run tsc --generateCpuProfile tsc-output.cpuprofile\n```\n\nThis file can be opened in a chromium based browser like Chrome or Edge Developer in [the CPU profiler](https://developers.google.com/web/tools/chrome-devtools/rendering-tools/js-execution) section.\nYou can learn more about understanding the compilers performance in the [TypeScript wiki section on performance](https://github.com/microsoft/TypeScript/wiki/Performance).",

"x-intellij-html-description": "<p>This option gives you the chance to have TypeScript emit a v8 CPU profile during the compiler run. The CPU profile can provide insight into why your builds may be slow.</p>\n<p>This option can only be used from the CLI via: <code>--generateCpuProfile tsc-output.cpuprofile</code>.</p>\n<pre><code class=\"language-sh\">npm run tsc --generateCpuProfile tsc-output.cpuprofile\n</code></pre>\n<p>This file can be opened in a chromium based browser like Chrome or Edge Developer in <a href=\"https://developers.google.com/web/tools/chrome-devtools/rendering-tools/js-execution\">the CPU profiler</a> section.\nYou can learn more about understanding the compilers performance in the <a href=\"https://github.com/microsoft/TypeScript/wiki/Performance\">TypeScript wiki section on performance</a>.</p>\n"

},

"baseUrl": {

"description": "Sets a base directory from which to resolve bare specifier module names. For example, in the directory structure:\n\n```\nproject\n├── ex.ts\n├── hello\n│ └── world.ts\n└── tsconfig.json\n```\n\nWith `\"baseUrl\": \"./\"`, TypeScript will look for files starting at the same folder as the `tsconfig.json`:\n\n```ts\nimport { helloWorld } from \"hello/world\";\n\nconsole.log(helloWorld);\n```\n\nThis resolution has higher priority than lookups from `node_modules`.\n\nThis feature was designed for use in conjunction with AMD module loaders in the browser, and is not recommended in any other context. As of TypeScript 4.1, `baseUrl` is no longer required to be set when using [`paths`](https://typescriptlang.org/tsconfig/#paths).",

"type": ["string", "null"],

"markdownDescription": "Sets a base directory from which to resolve bare specifier module names. For example, in the directory structure:\n\n```\nproject\n├── ex.ts\n├── hello\n│ └── world.ts\n└── tsconfig.json\n```\n\nWith `\"baseUrl\": \"./\"`, TypeScript will look for files starting at the same folder as the `tsconfig.json`:\n\n```ts\nimport { helloWorld } from \"hello/world\";\n\nconsole.log(helloWorld);\n```\n\nThis resolution has higher priority than lookups from `node_modules`.\n\nThis feature was designed for use in conjunction with AMD module loaders in the browser, and is not recommended in any other context. As of TypeScript 4.1, `baseUrl` is no longer required to be set when using [`paths`](https://typescriptlang.org/tsconfig/#paths).",

"x-intellij-html-description": "<p>Sets a base directory from which to resolve bare specifier module names. For example, in the directory structure:</p>\n<pre><code>project\n├── ex.ts\n├── hello\n│ └── world.ts\n└── tsconfig.json\n</code></pre>\n<p>With <code>&quot;baseUrl&quot;: &quot;./&quot;</code>, TypeScript will look for files starting at the same folder as the <code>tsconfig.json</code>:</p>\n<pre><code class=\"language-ts\">import { helloWorld } from &quot;hello/world&quot;;\n\nconsole.log(helloWorld);\n</code></pre>\n<p>This resolution has higher priority than lookups from <code>node_modules</code>.</p>\n<p>This feature was designed for use in conjunction with AMD module loaders in the browser, and is not recommended in any other context. As of TypeScript 4.1, <code>baseUrl</code> is no longer required to be set when using <a href=\"https://typescriptlang.org/tsconfig/#paths\"><code>paths</code></a>.</p>\n"

},

"paths": {

"description": "A series of entries which re-map imports to lookup locations relative to the [`baseUrl`](https://typescriptlang.org/tsconfig/#baseUrl) if set, or to the tsconfig file itself otherwise. There is a larger coverage of `paths` in [the `moduleResolution` reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#paths).\n\n`paths` lets you declare how TypeScript should resolve an import in your `require`/`import`s.\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"paths\": {\n \"jquery\": [\"./vendor/jquery/dist/jquery\"]\n }\n }\n}\n```\n\nThis would allow you to be able to write `import \"jquery\"`, and get all of the correct typing locally.\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"paths\": {\n \"app/*\": [\"./src/app/*\"],\n \"config/*\": [\"./src/app/_config/*\"],\n \"environment/*\": [\"./src/environments/*\"],\n \"shared/*\": [\"./src/app/_shared/*\"],\n \"helpers/*\": [\"./src/helpers/*\"],\n \"tests/*\": [\"./src/tests/*\"]\n }\n }\n}\n```\n\nIn this case, you can tell the TypeScript file resolver to support a number of custom prefixes to find code.\n\nNote that this feature does not change how import paths are emitted by `tsc`, so `paths` should only be used to inform TypeScript that another tool has this mapping and will use it at runtime or when bundling.",

"type": ["object", "null"],

"additionalProperties": {

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string",

"description": "Path mapping to be computed relative to baseUrl option."

}

},

"markdownDescription": "A series of entries which re-map imports to lookup locations relative to the [`baseUrl`](https://typescriptlang.org/tsconfig/#baseUrl) if set, or to the tsconfig file itself otherwise. There is a larger coverage of `paths` in [the `moduleResolution` reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#paths).\n\n`paths` lets you declare how TypeScript should resolve an import in your `require`/`import`s.\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"paths\": {\n \"jquery\": [\"./vendor/jquery/dist/jquery\"]\n }\n }\n}\n```\n\nThis would allow you to be able to write `import \"jquery\"`, and get all of the correct typing locally.\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"paths\": {\n \"app/*\": [\"./src/app/*\"],\n \"config/*\": [\"./src/app/_config/*\"],\n \"environment/*\": [\"./src/environments/*\"],\n \"shared/*\": [\"./src/app/_shared/*\"],\n \"helpers/*\": [\"./src/helpers/*\"],\n \"tests/*\": [\"./src/tests/*\"]\n }\n }\n}\n```\n\nIn this case, you can tell the TypeScript file resolver to support a number of custom prefixes to find code.\n\nNote that this feature does not change how import paths are emitted by `tsc`, so `paths` should only be used to inform TypeScript that another tool has this mapping and will use it at runtime or when bundling.",

"x-intellij-html-description": "<p>A series of entries which re-map imports to lookup locations relative to the <a href=\"https://typescriptlang.org/tsconfig/#baseUrl\"><code>baseUrl</code></a> if set, or to the tsconfig file itself otherwise. There is a larger coverage of <code>paths</code> in <a href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#paths\">the <code>moduleResolution</code> reference page</a>.</p>\n<p><code>paths</code> lets you declare how TypeScript should resolve an import in your <code>require</code>/<code>import</code>s.</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;paths&quot;: {\n &quot;jquery&quot;: [&quot;./vendor/jquery/dist/jquery&quot;]\n }\n }\n}\n</code></pre>\n<p>This would allow you to be able to write <code>import &quot;jquery&quot;</code>, and get all of the correct typing locally.</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;paths&quot;: {\n &quot;app/*&quot;: [&quot;./src/app/*&quot;],\n &quot;config/*&quot;: [&quot;./src/app/_config/*&quot;],\n &quot;environment/*&quot;: [&quot;./src/environments/*&quot;],\n &quot;shared/*&quot;: [&quot;./src/app/_shared/*&quot;],\n &quot;helpers/*&quot;: [&quot;./src/helpers/*&quot;],\n &quot;tests/*&quot;: [&quot;./src/tests/*&quot;]\n }\n }\n}\n</code></pre>\n<p>In this case, you can tell the TypeScript file resolver to support a number of custom prefixes to find code.</p>\n<p>Note that this feature does not change how import paths are emitted by <code>tsc</code>, so <code>paths</code> should only be used to inform TypeScript that another tool has this mapping and will use it at runtime or when bundling.</p>\n"

},

"plugins": {

"description": "List of language service plugins to run inside the editor.\n\nLanguage service plugins are a way to provide additional information to a user based on existing TypeScript files. They can enhance existing messages between TypeScript and an editor, or to provide their own error messages.\n\nFor example:\n\n- [ts-sql-plugin](https://github.com/xialvjun/ts-sql-plugin#readme) &mdash; Adds SQL linting with a template strings SQL builder.\n- [typescript-styled-plugin](https://github.com/Microsoft/typescript-styled-plugin) &mdash; Provides CSS linting inside template strings .\n- [typescript-eslint-language-service](https://github.com/Quramy/typescript-eslint-language-service) &mdash; Provides eslint error messaging and fix-its inside the compiler's output.\n- [ts-graphql-plugin](https://github.com/Quramy/ts-graphql-plugin) &mdash; Provides validation and auto-completion inside GraphQL query template strings.\n\nVS Code has the ability for a extension to [automatically include language service plugins](https://code.visualstudio.com/api/references/contribution-points#contributes.typescriptServerPlugins), and so you may have some running in your editor without needing to define them in your `tsconfig.json`.",

"type": ["array", "null"],

"items": {

"type": "object",

"properties": {

"name": {

"description": "Plugin name.",

"type": "string"

}

}

},

"markdownDescription": "List of language service plugins to run inside the editor.\n\nLanguage service plugins are a way to provide additional information to a user based on existing TypeScript files. They can enhance existing messages between TypeScript and an editor, or to provide their own error messages.\n\nFor example:\n\n- [ts-sql-plugin](https://github.com/xialvjun/ts-sql-plugin#readme) &mdash; Adds SQL linting with a template strings SQL builder.\n- [typescript-styled-plugin](https://github.com/Microsoft/typescript-styled-plugin) &mdash; Provides CSS linting inside template strings .\n- [typescript-eslint-language-service](https://github.com/Quramy/typescript-eslint-language-service) &mdash; Provides eslint error messaging and fix-its inside the compiler's output.\n- [ts-graphql-plugin](https://github.com/Quramy/ts-graphql-plugin) &mdash; Provides validation and auto-completion inside GraphQL query template strings.\n\nVS Code has the ability for a extension to [automatically include language service plugins](https://code.visualstudio.com/api/references/contribution-points#contributes.typescriptServerPlugins), and so you may have some running in your editor without needing to define them in your `tsconfig.json`.",

"x-intellij-html-description": "<p>List of language service plugins to run inside the editor.</p>\n<p>Language service plugins are a way to provide additional information to a user based on existing TypeScript files. They can enhance existing messages between TypeScript and an editor, or to provide their own error messages.</p>\n<p>For example:</p>\n<ul>\n<li><a href=\"https://github.com/xialvjun/ts-sql-plugin#readme\">ts-sql-plugin</a> &mdash; Adds SQL linting with a template strings SQL builder.</li>\n<li><a href=\"https://github.com/Microsoft/typescript-styled-plugin\">typescript-styled-plugin</a> &mdash; Provides CSS linting inside template strings .</li>\n<li><a href=\"https://github.com/Quramy/typescript-eslint-language-service\">typescript-eslint-language-service</a> &mdash; Provides eslint error messaging and fix-its inside the compiler&#39;s output.</li>\n<li><a href=\"https://github.com/Quramy/ts-graphql-plugin\">ts-graphql-plugin</a> &mdash; Provides validation and auto-completion inside GraphQL query template strings.</li>\n</ul>\n<p>VS Code has the ability for a extension to <a href=\"https://code.visualstudio.com/api/references/contribution-points#contributes.typescriptServerPlugins\">automatically include language service plugins</a>, and so you may have some running in your editor without needing to define them in your <code>tsconfig.json</code>.</p>\n"

},

"rootDirs": {

"description": "Using `rootDirs`, you can inform the compiler that there are many \"virtual\" directories acting as a single root.\nThis allows the compiler to resolve relative module imports within these \"virtual\" directories, as if they were merged in to one directory.\n\nFor example:\n\n```\n src\n └── views\n └── view1.ts (can import \"./template1\", \"./view2`)\n └── view2.ts (can import \"./template1\", \"./view1`)\n\n generated\n └── templates\n └── views\n └── template1.ts (can import \"./view1\", \"./view2\")\n```\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"rootDirs\": [\"src/views\", \"generated/templates/views\"]\n }\n}\n```\n\nThis does not affect how TypeScript emits JavaScript, it only emulates the assumption that they will be able to\nwork via those relative paths at runtime.\n\n`rootDirs` can be used to provide a separate \"type layer\" to files that are not TypeScript or JavaScript by providing a home for generated `.d.ts` files in another folder. This technique is useful for bundled applications where you use `import` of files that aren't necessarily code:\n\n```sh\n src\n └── index.ts\n └── css\n └── main.css\n └── navigation.css\n\n generated\n └── css\n └── main.css.d.ts\n └── navigation.css.d.ts\n```\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"rootDirs\": [\"src\", \"generated\"]\n }\n}\n```\n\nThis technique lets you generate types ahead of time for the non-code source files. Imports then work naturally based off the source file's location.\nFor example `./src/index.ts` can import the file `./src/css/main.css` and TypeScript will be aware of the bundler's behavior for that filetype via the corresponding generated declaration file.\n\n```ts twoslash\n// @filename: main.css.d.ts\nexport const appClass = \"mainClassF3EC2\";\n// ---cut---\n// @filename: index.ts\nimport { appClass } from \"./main.css\";\n```",

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string"

},

"markdownDescription": "Using `rootDirs`, you can inform the compiler that there are many \"virtual\" directories acting as a single root.\nThis allows the compiler to resolve relative module imports within these \"virtual\" directories, as if they were merged in to one directory.\n\nFor example:\n\n```\n src\n └── views\n └── view1.ts (can import \"./template1\", \"./view2`)\n └── view2.ts (can import \"./template1\", \"./view1`)\n\n generated\n └── templates\n └── views\n └── template1.ts (can import \"./view1\", \"./view2\")\n```\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"rootDirs\": [\"src/views\", \"generated/templates/views\"]\n }\n}\n```\n\nThis does not affect how TypeScript emits JavaScript, it only emulates the assumption that they will be able to\nwork via those relative paths at runtime.\n\n`rootDirs` can be used to provide a separate \"type layer\" to files that are not TypeScript or JavaScript by providing a home for generated `.d.ts` files in another folder. This technique is useful for bundled applications where you use `import` of files that aren't necessarily code:\n\n```sh\n src\n └── index.ts\n └── css\n └── main.css\n └── navigation.css\n\n generated\n └── css\n └── main.css.d.ts\n └── navigation.css.d.ts\n```\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"rootDirs\": [\"src\", \"generated\"]\n }\n}\n```\n\nThis technique lets you generate types ahead of time for the non-code source files. Imports then work naturally based off the source file's location.\nFor example `./src/index.ts` can import the file `./src/css/main.css` and TypeScript will be aware of the bundler's behavior for that filetype via the corresponding generated declaration file.\n\n```ts twoslash\n// @filename: main.css.d.ts\nexport const appClass = \"mainClassF3EC2\";\n// ---cut---\n// @filename: index.ts\nimport { appClass } from \"./main.css\";\n```",

"x-intellij-html-description": "<p>Using <code>rootDirs</code>, you can inform the compiler that there are many &quot;virtual&quot; directories acting as a single root.\nThis allows the compiler to resolve relative module imports within these &quot;virtual&quot; directories, as if they were merged in to one directory.</p>\n<p>For example:</p>\n<pre><code> src\n └── views\n └── view1.ts (can import &quot;./template1&quot;, &quot;./view2`)\n └── view2.ts (can import &quot;./template1&quot;, &quot;./view1`)\n\n generated\n └── templates\n └── views\n └── template1.ts (can import &quot;./view1&quot;, &quot;./view2&quot;)\n</code></pre>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;rootDirs&quot;: [&quot;src/views&quot;, &quot;generated/templates/views&quot;]\n }\n}\n</code></pre>\n<p>This does not affect how TypeScript emits JavaScript, it only emulates the assumption that they will be able to\nwork via those relative paths at runtime.</p>\n<p><code>rootDirs</code> can be used to provide a separate &quot;type layer&quot; to files that are not TypeScript or JavaScript by providing a home for generated <code>.d.ts</code> files in another folder. This technique is useful for bundled applications where you use <code>import</code> of files that aren&#39;t necessarily code:</p>\n<pre><code class=\"language-sh\"> src\n └── index.ts\n └── css\n └── main.css\n └── navigation.css\n\n generated\n └── css\n └── main.css.d.ts\n └── navigation.css.d.ts\n</code></pre>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;rootDirs&quot;: [&quot;src&quot;, &quot;generated&quot;]\n }\n}\n</code></pre>\n<p>This technique lets you generate types ahead of time for the non-code source files. Imports then work naturally based off the source file&#39;s location.\nFor example <code>./src/index.ts</code> can import the file <code>./src/css/main.css</code> and TypeScript will be aware of the bundler&#39;s behavior for that filetype via the corresponding generated declaration file.</p>\n<pre><code class=\"language-ts\">// @filename: main.css.d.ts\nexport const appClass = &quot;mainClassF3EC2&quot;;\n// ---cut---\n// @filename: index.ts\nimport { appClass } from &quot;./main.css&quot;;\n</code></pre>\n"

},

"typeRoots": {

"description": "By default all _visible_ \"`@types`\" packages are included in your compilation.\nPackages in `node_modules/@types` of any enclosing folder are considered _visible_.\nFor example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.\n\nIf `typeRoots` is specified, _only_ packages under `typeRoots` will be included. For example:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"typeRoots\": [\"./typings\", \"./vendor/types\"]\n }\n}\n```\n\nThis config file will include _all_ packages under `./typings` and `./vendor/types`, and no packages from `./node_modules/@types`.\nAll paths are relative to the `tsconfig.json`.",

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string"

},

"markdownDescription": "By default all _visible_ \"`@types`\" packages are included in your compilation.\nPackages in `node_modules/@types` of any enclosing folder are considered _visible_.\nFor example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.\n\nIf `typeRoots` is specified, _only_ packages under `typeRoots` will be included. For example:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"typeRoots\": [\"./typings\", \"./vendor/types\"]\n }\n}\n```\n\nThis config file will include _all_ packages under `./typings` and `./vendor/types`, and no packages from `./node_modules/@types`.\nAll paths are relative to the `tsconfig.json`.",

"x-intellij-html-description": "<p>By default all <em>visible</em> &quot;<code>@types</code>&quot; packages are included in your compilation.\nPackages in <code>node_modules/@types</code> of any enclosing folder are considered <em>visible</em>.\nFor example, that means packages within <code>./node_modules/@types/</code>, <code>../node_modules/@types/</code>, <code>../../node_modules/@types/</code>, and so on.</p>\n<p>If <code>typeRoots</code> is specified, <em>only</em> packages under <code>typeRoots</code> will be included. For example:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;typeRoots&quot;: [&quot;./typings&quot;, &quot;./vendor/types&quot;]\n }\n}\n</code></pre>\n<p>This config file will include <em>all</em> packages under <code>./typings</code> and <code>./vendor/types</code>, and no packages from <code>./node_modules/@types</code>.\nAll paths are relative to the <code>tsconfig.json</code>.</p>\n"

},

"types": {

"description": "By default all _visible_ \"`@types`\" packages are included in your compilation.\nPackages in `node_modules/@types` of any enclosing folder are considered _visible_.\nFor example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.\n\nIf `types` is specified, only packages listed will be included in the global scope. For instance:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"types\": [\"node\", \"jest\", \"express\"]\n }\n}\n```\n\nThis `tsconfig.json` file will _only_ include `./node_modules/@types/node`, `./node_modules/@types/jest` and `./node_modules/@types/express`.\nOther packages under `node_modules/@types/*` will not be included.\n\n### What does this affect?\n\nThis option does not affect how `@types/*` are included in your application code, for example if you had the above `compilerOptions` example with code like:\n\n```ts\nimport * as moment from \"moment\";\n\nmoment().format(\"MMMM Do YYYY, h:mm:ss a\");\n```\n\nThe `moment` import would be fully typed.\n\nWhen you have this option set, by not including a module in the `types` array it:\n\n- Will not add globals to your project (e.g `process` in node, or `expect` in Jest)\n- Will not have exports appear as auto-import recommendations\n\nThis feature differs from [`typeRoots`](https://typescriptlang.org/tsconfig/#typeRoots) in that it is about specifying only the exact types you want included, whereas [`typeRoots`](https://typescriptlang.org/tsconfig/#typeRoots) supports saying you want particular folders.",

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string"

},

"markdownDescription": "By default all _visible_ \"`@types`\" packages are included in your compilation.\nPackages in `node_modules/@types` of any enclosing folder are considered _visible_.\nFor example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.\n\nIf `types` is specified, only packages listed will be included in the global scope. For instance:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"types\": [\"node\", \"jest\", \"express\"]\n }\n}\n```\n\nThis `tsconfig.json` file will _only_ include `./node_modules/@types/node`, `./node_modules/@types/jest` and `./node_modules/@types/express`.\nOther packages under `node_modules/@types/*` will not be included.\n\n### What does this affect?\n\nThis option does not affect how `@types/*` are included in your application code, for example if you had the above `compilerOptions` example with code like:\n\n```ts\nimport * as moment from \"moment\";\n\nmoment().format(\"MMMM Do YYYY, h:mm:ss a\");\n```\n\nThe `moment` import would be fully typed.\n\nWhen you have this option set, by not including a module in the `types` array it:\n\n- Will not add globals to your project (e.g `process` in node, or `expect` in Jest)\n- Will not have exports appear as auto-import recommendations\n\nThis feature differs from [`typeRoots`](https://typescriptlang.org/tsconfig/#typeRoots) in that it is about specifying only the exact types you want included, whereas [`typeRoots`](https://typescriptlang.org/tsconfig/#typeRoots) supports saying you want particular folders.",

"x-intellij-html-description": "<p>By default all <em>visible</em> &quot;<code>@types</code>&quot; packages are included in your compilation.\nPackages in <code>node_modules/@types</code> of any enclosing folder are considered <em>visible</em>.\nFor example, that means packages within <code>./node_modules/@types/</code>, <code>../node_modules/@types/</code>, <code>../../node_modules/@types/</code>, and so on.</p>\n<p>If <code>types</code> is specified, only packages listed will be included in the global scope. For instance:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;types&quot;: [&quot;node&quot;, &quot;jest&quot;, &quot;express&quot;]\n }\n}\n</code></pre>\n<p>This <code>tsconfig.json</code> file will <em>only</em> include <code>./node_modules/@types/node</code>, <code>./node_modules/@types/jest</code> and <code>./node_modules/@types/express</code>.\nOther packages under <code>node_modules/@types/*</code> will not be included.</p>\n<h3>What does this affect?</h3>\n<p>This option does not affect how <code>@types/*</code> are included in your application code, for example if you had the above <code>compilerOptions</code> example with code like:</p>\n<pre><code class=\"language-ts\">import * as moment from &quot;moment&quot;;\n\nmoment().format(&quot;MMMM Do YYYY, h:mm:ss a&quot;);\n</code></pre>\n<p>The <code>moment</code> import would be fully typed.</p>\n<p>When you have this option set, by not including a module in the <code>types</code> array it:</p>\n<ul>\n<li>Will not add globals to your project (e.g <code>process</code> in node, or <code>expect</code> in Jest)</li>\n<li>Will not have exports appear as auto-import recommendations</li>\n</ul>\n<p>This feature differs from <a href=\"https://typescriptlang.org/tsconfig/#typeRoots\"><code>typeRoots</code></a> in that it is about specifying only the exact types you want included, whereas <a href=\"https://typescriptlang.org/tsconfig/#typeRoots\"><code>typeRoots</code></a> supports saying you want particular folders.</p>\n"

},

"traceResolution": {

"description": "Enable tracing of the name resolution process. Requires TypeScript version 2.0 or later.",

"type": ["boolean", "null"],

"default": false

},

"allowJs": {

"description": "Allow JavaScript files to be imported inside your project, instead of just `.ts` and `.tsx` files. For example, this JS file:\n\n```js twoslash\n// @filename: card.js\nexport const defaultCardDeck = \"Heart\";\n```\n\nWhen imported into a TypeScript file will raise an error:\n\n```ts twoslash\n// @errors: 2307\n// @filename: card.js\nmodule.exports.defaultCardDeck = \"Heart\";\n// ---cut---\n// @filename: index.ts\nimport { defaultCardDeck } from \"./card\";\n\nconsole.log(defaultCardDeck);\n```\n\nImports fine with `allowJs` enabled:\n\n```ts twoslash\n// @filename: card.js\nmodule.exports.defaultCardDeck = \"Heart\";\n// ---cut---\n// @allowJs\n// @filename: index.ts\nimport { defaultCardDeck } from \"./card\";\n\nconsole.log(defaultCardDeck);\n```\n\nThis flag can be used as a way to incrementally add TypeScript files into JS projects by allowing the `.ts` and `.tsx` files to live along-side existing JavaScript files.\n\nIt can also be used along-side [`declaration`](https://typescriptlang.org/tsconfig/#declaration) and [`emitDeclarationOnly`](https://typescriptlang.org/tsconfig/#emitDeclarationOnly) to [create declarations for JS files](https://typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html).",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Allow JavaScript files to be imported inside your project, instead of just `.ts` and `.tsx` files. For example, this JS file:\n\n```js twoslash\n// @filename: card.js\nexport const defaultCardDeck = \"Heart\";\n```\n\nWhen imported into a TypeScript file will raise an error:\n\n```ts twoslash\n// @errors: 2307\n// @filename: card.js\nmodule.exports.defaultCardDeck = \"Heart\";\n// ---cut---\n// @filename: index.ts\nimport { defaultCardDeck } from \"./card\";\n\nconsole.log(defaultCardDeck);\n```\n\nImports fine with `allowJs` enabled:\n\n```ts twoslash\n// @filename: card.js\nmodule.exports.defaultCardDeck = \"Heart\";\n// ---cut---\n// @allowJs\n// @filename: index.ts\nimport { defaultCardDeck } from \"./card\";\n\nconsole.log(defaultCardDeck);\n```\n\nThis flag can be used as a way to incrementally add TypeScript files into JS projects by allowing the `.ts` and `.tsx` files to live along-side existing JavaScript files.\n\nIt can also be used along-side [`declaration`](https://typescriptlang.org/tsconfig/#declaration) and [`emitDeclarationOnly`](https://typescriptlang.org/tsconfig/#emitDeclarationOnly) to [create declarations for JS files](https://typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html).",

"x-intellij-html-description": "<p>Allow JavaScript files to be imported inside your project, instead of just <code>.ts</code> and <code>.tsx</code> files. For example, this JS file:</p>\n<pre><code class=\"language-js\">// @filename: card.js\nexport const defaultCardDeck = &quot;Heart&quot;;\n</code></pre>\n<p>When imported into a TypeScript file will raise an error:</p>\n<pre><code class=\"language-ts\">// @errors: 2307\n// @filename: card.js\nmodule.exports.defaultCardDeck = &quot;Heart&quot;;\n// ---cut---\n// @filename: index.ts\nimport { defaultCardDeck } from &quot;./card&quot;;\n\nconsole.log(defaultCardDeck);\n</code></pre>\n<p>Imports fine with <code>allowJs</code> enabled:</p>\n<pre><code class=\"language-ts\">// @filename: card.js\nmodule.exports.defaultCardDeck = &quot;Heart&quot;;\n// ---cut---\n// @allowJs\n// @filename: index.ts\nimport { defaultCardDeck } from &quot;./card&quot;;\n\nconsole.log(defaultCardDeck);\n</code></pre>\n<p>This flag can be used as a way to incrementally add TypeScript files into JS projects by allowing the <code>.ts</code> and <code>.tsx</code> files to live along-side existing JavaScript files.</p>\n<p>It can also be used along-side <a href=\"https://typescriptlang.org/tsconfig/#declaration\"><code>declaration</code></a> and <a href=\"https://typescriptlang.org/tsconfig/#emitDeclarationOnly\"><code>emitDeclarationOnly</code></a> to <a href=\"https://typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html\">create declarations for JS files</a>.</p>\n"

},

"noErrorTruncation": {

"description": "Do not truncate error messages.\n\nWith `false`, the default.\n\n```ts twoslash\n// @errors: 2322 2454\nvar x: {\n propertyWithAnExceedinglyLongName1: string;\n propertyWithAnExceedinglyLongName2: string;\n propertyWithAnExceedinglyLongName3: string;\n propertyWithAnExceedinglyLongName4: string;\n propertyWithAnExceedinglyLongName5: string;\n propertyWithAnExceedinglyLongName6: string;\n propertyWithAnExceedinglyLongName7: string;\n propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of 'x' should be truncated in error message\nvar s: string = x;\n```\n\nWith `true`\n\n```ts twoslash\n// @errors: 2322 2454\n// @noErrorTruncation: true\nvar x: {\n propertyWithAnExceedinglyLongName1: string;\n propertyWithAnExceedinglyLongName2: string;\n propertyWithAnExceedinglyLongName3: string;\n propertyWithAnExceedinglyLongName4: string;\n propertyWithAnExceedinglyLongName5: string;\n propertyWithAnExceedinglyLongName6: string;\n propertyWithAnExceedinglyLongName7: string;\n propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of 'x' should be truncated in error message\nvar s: string = x;\n```",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Do not truncate error messages.\n\nWith `false`, the default.\n\n```ts twoslash\n// @errors: 2322 2454\nvar x: {\n propertyWithAnExceedinglyLongName1: string;\n propertyWithAnExceedinglyLongName2: string;\n propertyWithAnExceedinglyLongName3: string;\n propertyWithAnExceedinglyLongName4: string;\n propertyWithAnExceedinglyLongName5: string;\n propertyWithAnExceedinglyLongName6: string;\n propertyWithAnExceedinglyLongName7: string;\n propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of 'x' should be truncated in error message\nvar s: string = x;\n```\n\nWith `true`\n\n```ts twoslash\n// @errors: 2322 2454\n// @noErrorTruncation: true\nvar x: {\n propertyWithAnExceedinglyLongName1: string;\n propertyWithAnExceedinglyLongName2: string;\n propertyWithAnExceedinglyLongName3: string;\n propertyWithAnExceedinglyLongName4: string;\n propertyWithAnExceedinglyLongName5: string;\n propertyWithAnExceedinglyLongName6: string;\n propertyWithAnExceedinglyLongName7: string;\n propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of 'x' should be truncated in error message\nvar s: string = x;\n```",

"x-intellij-html-description": "<p>Do not truncate error messages.</p>\n<p>With <code>false</code>, the default.</p>\n<pre><code class=\"language-ts\">// @errors: 2322 2454\nvar x: {\n propertyWithAnExceedinglyLongName1: string;\n propertyWithAnExceedinglyLongName2: string;\n propertyWithAnExceedinglyLongName3: string;\n propertyWithAnExceedinglyLongName4: string;\n propertyWithAnExceedinglyLongName5: string;\n propertyWithAnExceedinglyLongName6: string;\n propertyWithAnExceedinglyLongName7: string;\n propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of &#39;x&#39; should be truncated in error message\nvar s: string = x;\n</code></pre>\n<p>With <code>true</code></p>\n<pre><code class=\"language-ts\">// @errors: 2322 2454\n// @noErrorTruncation: true\nvar x: {\n propertyWithAnExceedinglyLongName1: string;\n propertyWithAnExceedinglyLongName2: string;\n propertyWithAnExceedinglyLongName3: string;\n propertyWithAnExceedinglyLongName4: string;\n propertyWithAnExceedinglyLongName5: string;\n propertyWithAnExceedinglyLongName6: string;\n propertyWithAnExceedinglyLongName7: string;\n propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of &#39;x&#39; should be truncated in error message\nvar s: string = x;\n</code></pre>\n"

},

"allowSyntheticDefaultImports": {

"description": "When set to true, `allowSyntheticDefaultImports` allows you to write an import like:\n\n```ts\nimport React from \"react\";\n```\n\ninstead of:\n\n```ts\nimport * as React from \"react\";\n```\n\nWhen the module **does not** explicitly specify a default export.\n\nFor example, without `allowSyntheticDefaultImports` as true:\n\n```ts twoslash\n// @errors: 1259 1192\n// @checkJs\n// @allowJs\n// @esModuleInterop: false\n// @filename: utilFunctions.js\n// @noImplicitAny: false\nconst getStringLength = (str) => str.length;\n\nmodule.exports = {\n getStringLength,\n};\n\n// @filename: index.ts\nimport utils from \"./utilFunctions\";\n\nconst count = utils.getStringLength(\"Check JS\");\n```\n\nThis code raises an error because there isn't a `default` object which you can import. Even though it feels like it should.\nFor convenience, transpilers like Babel will automatically create a default if one isn't created. Making the module look a bit more like:\n\n```js\n// @filename: utilFunctions.js\nconst getStringLength = (str) => str.length;\nconst allFunctions = {\n getStringLength,\n};\n\nmodule.exports = allFunctions;\nmodule.exports.default = allFunctions;\n```\n\nThis flag does not affect the JavaScript emitted by TypeScript, it's only for the type checking.\nThis option brings the behavior of TypeScript in-line with Babel, where extra code is emitted to make using a default export of a module more ergonomic.",

"type": ["boolean", "null"],

"markdownDescription": "When set to true, `allowSyntheticDefaultImports` allows you to write an import like:\n\n```ts\nimport React from \"react\";\n```\n\ninstead of:\n\n```ts\nimport * as React from \"react\";\n```\n\nWhen the module **does not** explicitly specify a default export.\n\nFor example, without `allowSyntheticDefaultImports` as true:\n\n```ts twoslash\n// @errors: 1259 1192\n// @checkJs\n// @allowJs\n// @esModuleInterop: false\n// @filename: utilFunctions.js\n// @noImplicitAny: false\nconst getStringLength = (str) => str.length;\n\nmodule.exports = {\n getStringLength,\n};\n\n// @filename: index.ts\nimport utils from \"./utilFunctions\";\n\nconst count = utils.getStringLength(\"Check JS\");\n```\n\nThis code raises an error because there isn't a `default` object which you can import. Even though it feels like it should.\nFor convenience, transpilers like Babel will automatically create a default if one isn't created. Making the module look a bit more like:\n\n```js\n// @filename: utilFunctions.js\nconst getStringLength = (str) => str.length;\nconst allFunctions = {\n getStringLength,\n};\n\nmodule.exports = allFunctions;\nmodule.exports.default = allFunctions;\n```\n\nThis flag does not affect the JavaScript emitted by TypeScript, it's only for the type checking.\nThis option brings the behavior of TypeScript in-line with Babel, where extra code is emitted to make using a default export of a module more ergonomic.",

"x-intellij-html-description": "<p>When set to true, <code>allowSyntheticDefaultImports</code> allows you to write an import like:</p>\n<pre><code class=\"language-ts\">import React from &quot;react&quot;;\n</code></pre>\n<p>instead of:</p>\n<pre><code class=\"language-ts\">import * as React from &quot;react&quot;;\n</code></pre>\n<p>When the module <strong>does not</strong> explicitly specify a default export.</p>\n<p>For example, without <code>allowSyntheticDefaultImports</code> as true:</p>\n<pre><code class=\"language-ts\">// @errors: 1259 1192\n// @checkJs\n// @allowJs\n// @esModuleInterop: false\n// @filename: utilFunctions.js\n// @noImplicitAny: false\nconst getStringLength = (str) =&gt; str.length;\n\nmodule.exports = {\n getStringLength,\n};\n\n// @filename: index.ts\nimport utils from &quot;./utilFunctions&quot;;\n\nconst count = utils.getStringLength(&quot;Check JS&quot;);\n</code></pre>\n<p>This code raises an error because there isn&#39;t a <code>default</code> object which you can import. Even though it feels like it should.\nFor convenience, transpilers like Babel will automatically create a default if one isn&#39;t created. Making the module look a bit more like:</p>\n<pre><code class=\"language-js\">// @filename: utilFunctions.js\nconst getStringLength = (str) =&gt; str.length;\nconst allFunctions = {\n getStringLength,\n};\n\nmodule.exports = allFunctions;\nmodule.exports.default = allFunctions;\n</code></pre>\n<p>This flag does not affect the JavaScript emitted by TypeScript, it&#39;s only for the type checking.\nThis option brings the behavior of TypeScript in-line with Babel, where extra code is emitted to make using a default export of a module more ergonomic.</p>\n"

},

"noImplicitUseStrict": {

"description": "You shouldn't need this. By default, when emitting a module file to a non-ES6 target, TypeScript emits a `\"use strict\";` prologue at the top of the file.\nThis setting disables the prologue.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "You shouldn't need this. By default, when emitting a module file to a non-ES6 target, TypeScript emits a `\"use strict\";` prologue at the top of the file.\nThis setting disables the prologue.",

"x-intellij-html-description": "<p>You shouldn&#39;t need this. By default, when emitting a module file to a non-ES6 target, TypeScript emits a <code>&quot;use strict&quot;;</code> prologue at the top of the file.\nThis setting disables the prologue.</p>\n"

},

"listEmittedFiles": {

"description": "Print names of generated files part of the compilation to the terminal.\n\nThis flag is useful in two cases:\n\n- You want to transpile TypeScript as a part of a build chain in the terminal where the filenames are processed in the next command.\n- You are not sure that TypeScript has included a file you expected, as a part of debugging the [file inclusion settings](https://typescriptlang.org/tsconfig/#Project_Files_0).\n\nFor example:\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nWith:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"declaration\": true,\n \"listEmittedFiles\": true\n }\n}\n```\n\nWould echo paths like:\n\n```\n$ npm run tsc\n\npath/to/example/index.js\npath/to/example/index.d.ts\n```\n\nNormally, TypeScript would return silently on success.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "Print names of generated files part of the compilation to the terminal.\n\nThis flag is useful in two cases:\n\n- You want to transpile TypeScript as a part of a build chain in the terminal where the filenames are processed in the next command.\n- You are not sure that TypeScript has included a file you expected, as a part of debugging the [file inclusion settings](https://typescriptlang.org/tsconfig/#Project_Files_0).\n\nFor example:\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nWith:\n\n```json tsconfig\n{\n \"compilerOptions\": {\n \"declaration\": true,\n \"listEmittedFiles\": true\n }\n}\n```\n\nWould echo paths like:\n\n```\n$ npm run tsc\n\npath/to/example/index.js\npath/to/example/index.d.ts\n```\n\nNormally, TypeScript would return silently on success.",

"x-intellij-html-description": "<p>Print names of generated files part of the compilation to the terminal.</p>\n<p>This flag is useful in two cases:</p>\n<ul>\n<li>You want to transpile TypeScript as a part of a build chain in the terminal where the filenames are processed in the next command.</li>\n<li>You are not sure that TypeScript has included a file you expected, as a part of debugging the <a href=\"https://typescriptlang.org/tsconfig/#Project_Files_0\">file inclusion settings</a>.</li>\n</ul>\n<p>For example:</p>\n<pre><code>example\n├── index.ts\n├── package.json\n└── tsconfig.json\n</code></pre>\n<p>With:</p>\n<pre><code class=\"language-json\">{\n &quot;compilerOptions&quot;: {\n &quot;declaration&quot;: true,\n &quot;listEmittedFiles&quot;: true\n }\n}\n</code></pre>\n<p>Would echo paths like:</p>\n<pre><code>$ npm run tsc\n\npath/to/example/index.js\npath/to/example/index.d.ts\n</code></pre>\n<p>Normally, TypeScript would return silently on success.</p>\n"

},

"disableSizeLimit": {

"description": "To avoid a possible memory bloat issues when working with very large JavaScript projects, there is an upper limit to the amount of memory TypeScript will allocate. Turning this flag on will remove the limit.",

"type": ["boolean", "null"],

"default": false,

"markdownDescription": "To avoid a possible memory bloat issues when working with very large JavaScript projects, there is an upper limit to the amount of memory TypeScript will allocate. Turning this flag on will remove the limit.",

"x-intellij-html-description": "<p>To avoid a possible memory bloat issues when working with very large JavaScript projects, there is an upper limit to the amount of memory TypeScript will allocate. Turning this flag on will remove the limit.</p>\n"

},

"lib": {

"description": "TypeScript includes a default set of type definitions for built-in JS APIs (like `Math`), as well as type definitions for things found in browser environments (like `document`).\nTypeScript also includes APIs for newer JS features matching the [`target`](https://typescriptlang.org/tsconfig/#target) you specify; for example the definition for `Map` is available if [`target`](https://typescriptlang.org/tsconfig/#target) is `ES6` or newer.\n\nYou may want to change these for a few reasons:\n\n- Your program doesn't run in a browser, so you don't want the `\"dom\"` type definitions\n- Your runtime platform provides certain JavaScript API objects (maybe through polyfills), but doesn't yet support the full syntax of a given ECMAScript version\n- You have polyfills or native implementations for some, but not all, of a higher level ECMAScript version\n\nIn TypeScript 4.5, lib files can be overridden by npm modules, find out more [in the blog](https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#supporting-lib-from-node_modules).\n\n### High Level libraries\n\n| Name | Contents |\n| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `ES5` | Core definitions for all ES5 functionality |\n| `ES2015` | Additional APIs available in ES2015 (also known as ES6) - `array.find`, `Promise`, `Proxy`, `Symbol`, `Map`, `Set`, `Reflect`, etc. |\n| `ES6` | Alias for \"ES2015\" |\n| `ES2016` | Additional APIs available in ES2016 - `array.include`, etc. |\n| `ES7` | Alias for \"ES2016\" |\n| `ES2017` | Additional APIs available in ES2017 - `Object.entries`, `Object.values`, `Atomics`, `SharedArrayBuffer`, `date.formatToParts`, typed arrays, etc. |\n| `ES2018` | Additional APIs available in ES2018 - `async` iterables, `promise.finally`, `Intl.PluralRules`, `regexp.groups`, etc. |\n| `ES2019` | Additional APIs available in ES2019 - `array.flat`, `array.flatMap`, `Object.fromEntries`, `string.trimStart`, `string.trimEnd`, etc. |\n| `ES2020` | Additional APIs available in ES2020 - `string.matchAll`, etc. |\n| `ES2021` | Additional APIs available in ES2021 - `promise.any`, `string.replaceAll` etc. |\n| `ES2022` | Additional APIs available in ES2022 - `array.at`, `RegExp.hasIndices`, etc. |\n| `ES2023` | Additional APIs available in ES2023 - `array.with`, `array.findLast`, `array.findLastIndex`, `array.toSorted`, `array.toReversed`, etc. |\n| `ESNext` | Additional APIs available in ESNext - This changes as the JavaScript specification evolves |\n| `DOM` | [DOM](https://developer.mozilla.org/docs/Glossary/DOM) definitions - `window`, `document`, etc. |\n| `WebWorker` | APIs available in [WebWorker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API/Using_web_workers) contexts |\n| `ScriptHost` | APIs for the [Windows Script Hosting System](https://wikipedia.org/wiki/Windows_Script_Host) |\n\n### Individual library components\n\n| Name |\n| ------------------------- |\n| `DOM.Iterable` |\n| `ES2015.Core` |\n| `ES2015.Collection` |\n| `ES2015.Generator` |\n| `ES2015.Iterable` |\n| `ES2015.Promise` |\n| `ES2015.Proxy` |\n| `ES2015.Reflect` |\n| `ES2015.Symbol` |\n| `ES2015.Symbol.WellKnown` |\n| `ES2016.Array.Include` |\n| `ES2017.object` |\n| `ES2017.Intl` |\n| `ES2017.SharedMemory` |\n| `ES2017.String` |\n| `ES2017.TypedArrays` |\n| `ES2018.Intl` |\n| `ES2018.Promise` |\n| `ES2018.RegExp` |\n| `ES2019.Array` |\n| `ES2019.Object` |\n| `ES2019.String` |\n| `ES2019.Symbol` |\n| `ES2020.String` |\n| `ES2020.Symbol.wellknown` |\n| `ES2021.Promise` |\n| `ES2021.String` |\n| `ES2021.WeakRef` |\n| `ESNext.AsyncIterable` |\n| `ESNext.Array` |\n| `ESNext.Intl` |\n| `ESNext.Symbol` |\n\nThis list may be out of date, you can see the full list in the [TypeScript source code](https://github.com/microsoft/TypeScript/tree/main/src/lib).",

"type": ["array", "null"],

"uniqueItems": true,

"items": {

"type": "string",

"anyOf": [

{

"enum": [

"ES5",

"ES6",

"ES2015",

"ES2015.Collection",

"ES2015.Core",

"ES2015.Generator",

"ES2015.Iterable",

"ES2015.Promise",

"ES2015.Proxy",

"ES2015.Reflect",

"ES2015.Symbol.WellKnown",

"ES2015.Symbol",

"ES2016",

"ES2016.Array.Include",

"ES2017",

"ES2017.Intl",

"ES2017.Object",

"ES2017.SharedMemory",

"ES2017.String",

"ES2017.TypedArrays",

"ES2017.ArrayBuffer",

"ES2018",

"ES2018.AsyncGenerator",

"ES2018.AsyncIterable",

"ES2018.Intl",

"ES2018.Promise",

"ES2018.Regexp",

"ES2019",

"ES2019.Array",

"ES2019.Intl",

"ES2019.Object",

"ES2019.String",

"ES2019.Symbol",

"ES2020",

"ES2020.BigInt",

"ES2020.Promise",

"ES2020.String",

"ES2020.Symbol.WellKnown",

"ESNext",

"ESNext.Array",

"ESNext.AsyncIterable",

"ESNext.BigInt",

"ESNext.Collection",

"ESNext.Intl",

"ESNext.Iterator",

"ESNext.Object",

"ESNext.Promise",

"ESNext.Regexp",

"ESNext.String",

"ESNext.Symbol",

"DOM",

"DOM.AsyncIterable",

"DOM.Iterable",

"ScriptHost",

"WebWorker",

"WebWorker.AsyncIterable",

"WebWorker.ImportScripts",

"Webworker.Iterable",

"ES7",