@effect/tsgo 0.29.0 → 0.31.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (4) hide show
  1. package/dist/effect-tsgo.cjs +68 -3
  2. package/oxlint-schema.json +19699 -0
  3. package/package.json +9 -8
  4. package/schema.json +553 -390
package/schema.json CHANGED
@@ -53,12 +53,13 @@
53
53
  "properties": {
54
54
  "assumeChangesOnlyAffectDirectDependencies": {
55
55
  "default": false,
56
- "description": "Have recompiles in projects that use `incremental` and `watch` mode assume that changes within a file will only affect files directly depending on it.",
57
- "markdownDescription": "Have recompiles in projects that use `incremental` and `watch` mode assume that changes within a file will only affect files directly depending on it.\n\nSee more: https://www.typescriptlang.org/tsconfig#assumeChangesOnlyAffectDirectDependencies",
56
+ "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 \u0026 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.",
57
+ "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 \u0026 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.",
58
58
  "type": [
59
59
  "boolean",
60
60
  "null"
61
- ]
61
+ ],
62
+ "x-intellij-html-description": "\u003cp\u003eWhen 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.\u003c/p\u003e\n\u003cp\u003eThis can be considered a \u0026#39;fast \u0026amp; loose\u0026#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.\u003c/p\u003e\n"
62
63
  },
63
64
  "dry": {
64
65
  "default": false,
@@ -71,38 +72,42 @@
71
72
  "force": {
72
73
  "default": false,
73
74
  "description": "Build all projects, including those that appear to be up to date",
74
- "markdownDescription": "Build all projects, including those that appear to be up to date\n\nSee more: https://www.typescriptlang.org/tsconfig#force",
75
+ "markdownDescription": "Build all projects, including those that appear to be up to date",
75
76
  "type": [
76
77
  "boolean",
77
78
  "null"
78
- ]
79
+ ],
80
+ "x-intellij-html-description": "\u003cp\u003eBuild all projects, including those that appear to be up to date\u003c/p\u003e\n"
79
81
  },
80
82
  "incremental": {
81
83
  "default": false,
82
- "description": "Save .tsbuildinfo files to allow for incremental compilation of projects.",
83
- "markdownDescription": "Save .tsbuildinfo files to allow for incremental compilation of projects.\n\nSee more: https://www.typescriptlang.org/tsconfig#incremental",
84
+ "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).",
85
+ "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).",
84
86
  "type": [
85
87
  "boolean",
86
88
  "null"
87
- ]
89
+ ],
90
+ "x-intellij-html-description": "\u003cp\u003eTells TypeScript to save information about the project graph from the last compilation to files stored on disk. This\ncreates a series of \u003ccode\u003e.tsbuildinfo\u003c/code\u003e 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 \u003ca href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#faster-subsequent-builds-with-the---incremental-flag\"\u003e3.4 release notes\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eTo control which folders you want to the files to be built to, use the config option \u003ca href=\"https://typescriptlang.org/tsconfig/#tsBuildInfoFile\"\u003e\u003ccode\u003etsBuildInfoFile\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n"
88
91
  },
89
92
  "traceResolution": {
90
93
  "default": false,
91
- "description": "Log paths used during the `moduleResolution` process.",
92
- "markdownDescription": "Log paths used during the `moduleResolution` process.\n\nSee more: https://www.typescriptlang.org/tsconfig#traceResolution",
94
+ "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.",
95
+ "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.",
93
96
  "type": [
94
97
  "boolean",
95
98
  "null"
96
- ]
99
+ ],
100
+ "x-intellij-html-description": "\u003cp\u003eWhen you are trying to debug why a module isn\u0026#39;t being included.\nYou can set \u003ccode\u003etraceResolution\u003c/code\u003e to \u003ccode\u003etrue\u003c/code\u003e to have TypeScript print information about its resolution process for each processed file.\u003c/p\u003e\n"
97
101
  },
98
102
  "verbose": {
99
103
  "default": false,
100
104
  "description": "Enable verbose logging",
101
- "markdownDescription": "Enable verbose logging\n\nSee more: https://www.typescriptlang.org/tsconfig#verbose",
105
+ "markdownDescription": "Enable verbose logging",
102
106
  "type": [
103
107
  "boolean",
104
108
  "null"
105
- ]
109
+ ],
110
+ "x-intellij-html-description": "\u003cp\u003eEnable verbose logging\u003c/p\u003e\n"
106
111
  }
107
112
  }
108
113
  }
@@ -125,270 +130,299 @@
125
130
  "description": "Instructs the TypeScript compiler how to compile .ts files.",
126
131
  "properties": {
127
132
  "allowArbitraryExtensions": {
128
- "description": "Enable importing files with any extension, provided a declaration file is present.",
129
- "markdownDescription": "Enable importing files with any extension, provided a declaration file is present.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowArbitraryExtensions",
133
+ "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).",
134
+ "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).",
130
135
  "type": [
131
136
  "boolean",
132
137
  "null"
133
- ]
138
+ ],
139
+ "x-intellij-html-description": "\u003cp\u003eIn TypeScript 5.0, when an import path ends in an extension that isn\u0026#39;t a known JavaScript or TypeScript file extension, the compiler will look for a declaration file for that path in the form of \u003ccode\u003e{file basename}.d.{extension}.ts\u003c/code\u003e.\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:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-css\"\u003e/* app.css */\n.cookie-banner {\n display: none;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// app.d.css.ts\ndeclare const css: {\n cookieBanner: string;\n};\nexport default css;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// App.tsx\nimport styles from \u0026quot;./app.css\u0026quot;;\n\nstyles.cookieBanner; // string\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eBy default, this import will raise an error to let you know that TypeScript doesn\u0026#39;t understand this file type and your runtime might not support importing it.\nBut if you\u0026#39;ve configured your runtime or bundler to handle it, you can suppress the error with the new \u003ccode\u003e--allowArbitraryExtensions\u003c/code\u003e compiler option.\u003c/p\u003e\n\u003cp\u003eNote that historically, a similar effect has often been achievable by adding a declaration file named \u003ccode\u003eapp.css.d.ts\u003c/code\u003e instead of \u003ccode\u003eapp.d.css.ts\u003c/code\u003e - however, this just worked through Node\u0026#39;s \u003ccode\u003erequire\u003c/code\u003e resolution rules for CommonJS.\nStrictly speaking, the former is interpreted as a declaration file for a JavaScript file named \u003ccode\u003eapp.css.js\u003c/code\u003e.\nBecause relative files imports need to include extensions in Node\u0026#39;s ESM support, TypeScript would error on our example in an ESM file under \u003ccode\u003e--moduleResolution node16\u003c/code\u003e or \u003ccode\u003enodenext\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eFor more information, read up \u003ca href=\"https://github.com/microsoft/TypeScript/issues/50133\"\u003ethe proposal for this feature\u003c/a\u003e and \u003ca href=\"https://github.com/microsoft/TypeScript/pull/51435\"\u003eits corresponding pull request\u003c/a\u003e.\u003c/p\u003e\n"
134
140
  },
135
141
  "allowImportingTsExtensions": {
136
- "description": "Allow imports to include TypeScript file extensions. Requires `--moduleResolution bundler` and either `--noEmit` or `--emitDeclarationOnly` to be set.",
137
- "markdownDescription": "Allow imports to include TypeScript file extensions. Requires `--moduleResolution bundler` and either `--noEmit` or `--emitDeclarationOnly` to be set.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowImportingTsExtensions",
142
+ "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.",
143
+ "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.",
138
144
  "type": [
139
145
  "boolean",
140
146
  "null"
141
- ]
147
+ ],
148
+ "x-intellij-html-description": "\u003cp\u003e\u003ccode\u003e--allowImportingTsExtensions\u003c/code\u003e allows TypeScript files to import each other with a TypeScript-specific extension like \u003ccode\u003e.ts\u003c/code\u003e, \u003ccode\u003e.mts\u003c/code\u003e, or \u003ccode\u003e.tsx\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThis flag is only allowed when \u003ccode\u003e--noEmit\u003c/code\u003e or \u003ccode\u003e--emitDeclarationOnly\u003c/code\u003e 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 \u003ccode\u003e.ts\u003c/code\u003e files work.\u003c/p\u003e\n"
142
149
  },
143
150
  "allowJs": {
144
151
  "default": false,
145
- "description": "Allow JavaScript files to be a part of your program. Use the `checkJs` option to get errors from these files.",
146
- "markdownDescription": "Allow JavaScript files to be a part of your program. Use the `checkJs` option to get errors from these files.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowJs",
152
+ "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).",
153
+ "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).",
147
154
  "type": [
148
155
  "boolean",
149
156
  "null"
150
- ]
157
+ ],
158
+ "x-intellij-html-description": "\u003cp\u003eAllow JavaScript files to be imported inside your project, instead of just \u003ccode\u003e.ts\u003c/code\u003e and \u003ccode\u003e.tsx\u003c/code\u003e files. For example, this JS file:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-js\"\u003e// @filename: card.js\nexport const defaultCardDeck = \u0026quot;Heart\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhen imported into a TypeScript file will raise an error:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 2307\n// @filename: card.js\nmodule.exports.defaultCardDeck = \u0026quot;Heart\u0026quot;;\n// ---cut---\n// @filename: index.ts\nimport { defaultCardDeck } from \u0026quot;./card\u0026quot;;\n\nconsole.log(defaultCardDeck);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eImports fine with \u003ccode\u003eallowJs\u003c/code\u003e enabled:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @filename: card.js\nmodule.exports.defaultCardDeck = \u0026quot;Heart\u0026quot;;\n// ---cut---\n// @allowJs\n// @filename: index.ts\nimport { defaultCardDeck } from \u0026quot;./card\u0026quot;;\n\nconsole.log(defaultCardDeck);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis flag can be used as a way to incrementally add TypeScript files into JS projects by allowing the \u003ccode\u003e.ts\u003c/code\u003e and \u003ccode\u003e.tsx\u003c/code\u003e files to live along-side existing JavaScript files.\u003c/p\u003e\n\u003cp\u003eIt can also be used along-side \u003ca href=\"https://typescriptlang.org/tsconfig/#declaration\"\u003e\u003ccode\u003edeclaration\u003c/code\u003e\u003c/a\u003e and \u003ca href=\"https://typescriptlang.org/tsconfig/#emitDeclarationOnly\"\u003e\u003ccode\u003eemitDeclarationOnly\u003c/code\u003e\u003c/a\u003e to \u003ca href=\"https://typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html\"\u003ecreate declarations for JS files\u003c/a\u003e.\u003c/p\u003e\n"
151
159
  },
152
160
  "allowSyntheticDefaultImports": {
153
- "description": "Allow `import x from y` when a module doesn't have a default export.",
154
- "markdownDescription": "Allow `import x from y` when a module doesn't have a default export.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowSyntheticDefaultImports",
161
+ "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) =\u003e 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) =\u003e 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.",
162
+ "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) =\u003e 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) =\u003e 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.",
155
163
  "type": [
156
164
  "boolean",
157
165
  "null"
158
- ]
166
+ ],
167
+ "x-intellij-html-description": "\u003cp\u003eWhen set to true, \u003ccode\u003eallowSyntheticDefaultImports\u003c/code\u003e allows you to write an import like:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eimport React from \u0026quot;react\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003einstead of:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eimport * as React from \u0026quot;react\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhen the module \u003cstrong\u003edoes not\u003c/strong\u003e explicitly specify a default export.\u003c/p\u003e\n\u003cp\u003eFor example, without \u003ccode\u003eallowSyntheticDefaultImports\u003c/code\u003e as true:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 1259 1192\n// @checkJs\n// @allowJs\n// @esModuleInterop: false\n// @filename: utilFunctions.js\n// @noImplicitAny: false\nconst getStringLength = (str) =\u0026gt; str.length;\n\nmodule.exports = {\n getStringLength,\n};\n\n// @filename: index.ts\nimport utils from \u0026quot;./utilFunctions\u0026quot;;\n\nconst count = utils.getStringLength(\u0026quot;Check JS\u0026quot;);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis code raises an error because there isn\u0026#39;t a \u003ccode\u003edefault\u003c/code\u003e 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\u0026#39;t created. Making the module look a bit more like:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-js\"\u003e// @filename: utilFunctions.js\nconst getStringLength = (str) =\u0026gt; str.length;\nconst allFunctions = {\n getStringLength,\n};\n\nmodule.exports = allFunctions;\nmodule.exports.default = allFunctions;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis flag does not affect the JavaScript emitted by TypeScript, it\u0026#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.\u003c/p\u003e\n"
159
168
  },
160
169
  "allowUmdGlobalAccess": {
161
170
  "default": false,
162
- "description": "Allow accessing UMD globals from modules.",
163
- "markdownDescription": "Allow accessing UMD globals from modules.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowUmdGlobalAccess",
171
+ "description": "When set to true, `allowUmdGlobalAccess` lets you access UMD exports as globals from inside module files. A module file is a file that has imports and/or exports. Without this flag, using an export from a UMD module requires an import declaration.\n\nAn example use case for this flag would be a web project where you know the particular library (like jQuery or Lodash) will always be available at runtime, but you can’t access it with an import.",
172
+ "markdownDescription": "When set to true, `allowUmdGlobalAccess` lets you access UMD exports as globals from inside module files. A module file is a file that has imports and/or exports. Without this flag, using an export from a UMD module requires an import declaration.\n\nAn example use case for this flag would be a web project where you know the particular library (like jQuery or Lodash) will always be available at runtime, but you can’t access it with an import.",
164
173
  "type": [
165
174
  "boolean",
166
175
  "null"
167
- ]
176
+ ],
177
+ "x-intellij-html-description": "\u003cp\u003eWhen set to true, \u003ccode\u003eallowUmdGlobalAccess\u003c/code\u003e lets you access UMD exports as globals from inside module files. A module file is a file that has imports and/or exports. Without this flag, using an export from a UMD module requires an import declaration.\u003c/p\u003e\n\u003cp\u003eAn example use case for this flag would be a web project where you know the particular library (like jQuery or Lodash) will always be available at runtime, but you can’t access it with an import.\u003c/p\u003e\n"
168
178
  },
169
179
  "allowUnreachableCode": {
170
- "description": "Disable error reporting for unreachable code.",
171
- "markdownDescription": "Disable error reporting for unreachable code.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowUnreachableCode",
180
+ "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 \u003e 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 \u003e 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.",
181
+ "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 \u003e 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 \u003e 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.",
172
182
  "type": [
173
183
  "boolean",
174
184
  "null"
175
- ]
185
+ ],
186
+ "x-intellij-html-description": "\u003cp\u003eWhen:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003eundefined\u003c/code\u003e (default) provide suggestions as warnings to editors\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003etrue\u003c/code\u003e unreachable code is ignored\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003efalse\u003c/code\u003e raises compiler errors about unreachable code\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThese warnings are only about code which is provably unreachable due to the use of JavaScript syntax, for example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003efunction fn(n: number) {\n if (n \u0026gt; 5) {\n return true;\n } else {\n return false;\n }\n return true;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith \u003ccode\u003e\u0026quot;allowUnreachableCode\u0026quot;: false\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 7027\n// @allowUnreachableCode: false\nfunction fn(n: number) {\n if (n \u0026gt; 5) {\n return true;\n } else {\n return false;\n }\n return true;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis does not affect errors on the basis of code which \u003cem\u003eappears\u003c/em\u003e to be unreachable due to type analysis.\u003c/p\u003e\n"
176
187
  },
177
188
  "allowUnusedLabels": {
178
- "description": "Disable error reporting for unused labels.",
179
- "markdownDescription": "Disable error reporting for unused labels.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowUnusedLabels",
189
+ "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 \u003e 18) {\n verified: true;\n }\n}\n```",
190
+ "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 \u003e 18) {\n verified: true;\n }\n}\n```",
180
191
  "type": [
181
192
  "boolean",
182
193
  "null"
183
- ]
194
+ ],
195
+ "x-intellij-html-description": "\u003cp\u003eWhen:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003eundefined\u003c/code\u003e (default) provide suggestions as warnings to editors\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003etrue\u003c/code\u003e unused labels are ignored\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003efalse\u003c/code\u003e raises compiler errors about unused labels\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eLabels are very rare in JavaScript and typically indicate an attempt to write an object literal:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 7028\n// @allowUnusedLabels: false\nfunction verifyAge(age: number) {\n // Forgot \u0026#39;return\u0026#39; statement\n if (age \u0026gt; 18) {\n verified: true;\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n"
184
196
  },
185
197
  "alwaysStrict": {
186
- "description": "Ensure `use strict` is always emitted.",
187
- "markdownDescription": "Ensure `use strict` is always emitted.\n\nSee more: https://www.typescriptlang.org/tsconfig#alwaysStrict",
198
+ "description": "Ensures that your files are parsed in the ECMAScript strict mode, and emit \"use strict\" for each source file.\n\n[ECMAScript strict](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Strict_mode) mode was introduced in ES5 and provides behavior tweaks to the runtime of the JavaScript engine to improve performance, and makes a set of errors throw instead of silently ignoring them.",
199
+ "markdownDescription": "Ensures that your files are parsed in the ECMAScript strict mode, and emit \"use strict\" for each source file.\n\n[ECMAScript strict](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Strict_mode) mode was introduced in ES5 and provides behavior tweaks to the runtime of the JavaScript engine to improve performance, and makes a set of errors throw instead of silently ignoring them.",
188
200
  "type": [
189
201
  "boolean",
190
202
  "null"
191
- ]
203
+ ],
204
+ "x-intellij-html-description": "\u003cp\u003eEnsures that your files are parsed in the ECMAScript strict mode, and emit \u0026quot;use strict\u0026quot; for each source file.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://developer.mozilla.org/docs/Web/JavaScript/Reference/Strict_mode\"\u003eECMAScript strict\u003c/a\u003e mode was introduced in ES5 and provides behavior tweaks to the runtime of the JavaScript engine to improve performance, and makes a set of errors throw instead of silently ignoring them.\u003c/p\u003e\n"
192
205
  },
193
206
  "assumeChangesOnlyAffectDirectDependencies": {
194
- "description": "Have recompiles in projects that use `incremental` and `watch` mode assume that changes within a file will only affect files directly depending on it.",
195
- "markdownDescription": "Have recompiles in projects that use `incremental` and `watch` mode assume that changes within a file will only affect files directly depending on it.\n\nSee more: https://www.typescriptlang.org/tsconfig#assumeChangesOnlyAffectDirectDependencies",
207
+ "description": "Have recompiles in '--incremental' and '--watch' assume that changes within a file will only affect files directly depending on it. Requires TypeScript version 3.8 or later.",
196
208
  "type": [
197
209
  "boolean",
198
210
  "null"
199
211
  ]
200
212
  },
201
213
  "baseUrl": {
202
- "description": "Specify the base directory to resolve non-relative module names.",
203
- "markdownDescription": "Specify the base directory to resolve non-relative module names.\n\nSee more: https://www.typescriptlang.org/tsconfig#baseUrl",
214
+ "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).",
215
+ "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).",
204
216
  "type": [
205
217
  "string",
206
218
  "null"
207
- ]
219
+ ],
220
+ "x-intellij-html-description": "\u003cp\u003eSets a base directory from which to resolve bare specifier module names. For example, in the directory structure:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eproject\n├── ex.ts\n├── hello\n│ └── world.ts\n└── tsconfig.json\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith \u003ccode\u003e\u0026quot;baseUrl\u0026quot;: \u0026quot;./\u0026quot;\u003c/code\u003e, TypeScript will look for files starting at the same folder as the \u003ccode\u003etsconfig.json\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eimport { helloWorld } from \u0026quot;hello/world\u0026quot;;\n\nconsole.log(helloWorld);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis resolution has higher priority than lookups from \u003ccode\u003enode_modules\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThis 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, \u003ccode\u003ebaseUrl\u003c/code\u003e is no longer required to be set when using \u003ca href=\"https://typescriptlang.org/tsconfig/#paths\"\u003e\u003ccode\u003epaths\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n"
208
221
  },
209
222
  "charset": {
210
- "description": "No longer supported. In early versions, manually set the text encoding for reading files.",
211
- "markdownDescription": "No longer supported. In early versions, manually set the text encoding for reading files.\n\nSee more: https://www.typescriptlang.org/tsconfig#charset",
223
+ "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.",
224
+ "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.",
212
225
  "type": [
213
226
  "string",
214
227
  "null"
215
- ]
228
+ ],
229
+ "x-intellij-html-description": "\u003cp\u003eIn 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.\u003c/p\u003e\n"
216
230
  },
217
231
  "checkJs": {
218
232
  "default": false,
219
- "description": "Enable error reporting in type-checked JavaScript files.",
220
- "markdownDescription": "Enable error reporting in type-checked JavaScript files.\n\nSee more: https://www.typescriptlang.org/tsconfig#checkJs",
233
+ "description": "Works in tandem with [`allowJs`](https://typescriptlang.org/tsconfig/#allowJs). When `checkJs` is enabled then errors are reported in JavaScript files. This is\nthe equivalent of including `// @ts-check` at the top of all JavaScript files which are included in your project.\n\nFor example, this is incorrect JavaScript according to the `parseFloat` type definition which comes with TypeScript:\n\n```js\n// parseFloat only takes a string\nmodule.exports.pi = parseFloat(3.142);\n```\n\nWhen imported into a TypeScript module:\n\n```ts twoslash\n// @allowJs\n// @filename: constants.js\nmodule.exports.pi = parseFloat(3.142);\n\n// @filename: index.ts\nimport { pi } from \"./constants\";\nconsole.log(pi);\n```\n\nYou will not get any errors. However, if you turn on `checkJs` then you will get error messages from the JavaScript file.\n\n```ts twoslash\n// @errors: 2345\n// @allowjs: true\n// @checkjs: true\n// @filename: constants.js\nmodule.exports.pi = parseFloat(3.142);\n\n// @filename: index.ts\nimport { pi } from \"./constants\";\nconsole.log(pi);\n```",
234
+ "markdownDescription": "Works in tandem with [`allowJs`](https://typescriptlang.org/tsconfig/#allowJs). When `checkJs` is enabled then errors are reported in JavaScript files. This is\nthe equivalent of including `// @ts-check` at the top of all JavaScript files which are included in your project.\n\nFor example, this is incorrect JavaScript according to the `parseFloat` type definition which comes with TypeScript:\n\n```js\n// parseFloat only takes a string\nmodule.exports.pi = parseFloat(3.142);\n```\n\nWhen imported into a TypeScript module:\n\n```ts twoslash\n// @allowJs\n// @filename: constants.js\nmodule.exports.pi = parseFloat(3.142);\n\n// @filename: index.ts\nimport { pi } from \"./constants\";\nconsole.log(pi);\n```\n\nYou will not get any errors. However, if you turn on `checkJs` then you will get error messages from the JavaScript file.\n\n```ts twoslash\n// @errors: 2345\n// @allowjs: true\n// @checkjs: true\n// @filename: constants.js\nmodule.exports.pi = parseFloat(3.142);\n\n// @filename: index.ts\nimport { pi } from \"./constants\";\nconsole.log(pi);\n```",
221
235
  "type": [
222
236
  "boolean",
223
237
  "null"
224
- ]
238
+ ],
239
+ "x-intellij-html-description": "\u003cp\u003eWorks in tandem with \u003ca href=\"https://typescriptlang.org/tsconfig/#allowJs\"\u003e\u003ccode\u003eallowJs\u003c/code\u003e\u003c/a\u003e. When \u003ccode\u003echeckJs\u003c/code\u003e is enabled then errors are reported in JavaScript files. This is\nthe equivalent of including \u003ccode\u003e// @ts-check\u003c/code\u003e at the top of all JavaScript files which are included in your project.\u003c/p\u003e\n\u003cp\u003eFor example, this is incorrect JavaScript according to the \u003ccode\u003eparseFloat\u003c/code\u003e type definition which comes with TypeScript:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-js\"\u003e// parseFloat only takes a string\nmodule.exports.pi = parseFloat(3.142);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhen imported into a TypeScript module:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @allowJs\n// @filename: constants.js\nmodule.exports.pi = parseFloat(3.142);\n\n// @filename: index.ts\nimport { pi } from \u0026quot;./constants\u0026quot;;\nconsole.log(pi);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eYou will not get any errors. However, if you turn on \u003ccode\u003echeckJs\u003c/code\u003e then you will get error messages from the JavaScript file.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 2345\n// @allowjs: true\n// @checkjs: true\n// @filename: constants.js\nmodule.exports.pi = parseFloat(3.142);\n\n// @filename: index.ts\nimport { pi } from \u0026quot;./constants\u0026quot;;\nconsole.log(pi);\n\u003c/code\u003e\u003c/pre\u003e\n"
225
240
  },
226
241
  "composite": {
227
242
  "default": true,
228
- "description": "Enable constraints that allow a TypeScript project to be used with project references.",
229
- "markdownDescription": "Enable constraints that allow a TypeScript project to be used with project references.\n\nSee more: https://www.typescriptlang.org/tsconfig#composite",
243
+ "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).",
244
+ "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).",
230
245
  "type": [
231
246
  "boolean",
232
247
  "null"
233
- ]
248
+ ],
249
+ "x-intellij-html-description": "\u003cp\u003eThe \u003ccode\u003ecomposite\u003c/code\u003e option enforces certain constraints which make it possible for build tools (including TypeScript\nitself, under \u003ccode\u003e--build\u003c/code\u003e mode) to quickly determine if a project has been built yet.\u003c/p\u003e\n\u003cp\u003eWhen this setting is on:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003eThe \u003ca href=\"https://typescriptlang.org/tsconfig/#rootDir\"\u003e\u003ccode\u003erootDir\u003c/code\u003e\u003c/a\u003e setting, if not explicitly set, defaults to the directory containing the \u003ccode\u003etsconfig.json\u003c/code\u003e file.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003cp\u003eAll implementation files must be matched by an \u003ca href=\"https://typescriptlang.org/tsconfig/#include\"\u003e\u003ccode\u003einclude\u003c/code\u003e\u003c/a\u003e pattern or listed in the \u003ca href=\"https://typescriptlang.org/tsconfig/#files\"\u003e\u003ccode\u003efiles\u003c/code\u003e\u003c/a\u003e array. If this constraint is violated, \u003ccode\u003etsc\u003c/code\u003e will inform you which files weren\u0026#39;t specified.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003cp\u003e\u003ca href=\"https://typescriptlang.org/tsconfig/#declaration\"\u003e\u003ccode\u003edeclaration\u003c/code\u003e\u003c/a\u003e defaults to \u003ccode\u003etrue\u003c/code\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eYou can find documentation on TypeScript projects in \u003ca href=\"https://www.typescriptlang.org/docs/handbook/project-references.html\"\u003ethe handbook\u003c/a\u003e.\u003c/p\u003e\n"
234
250
  },
235
251
  "customConditions": {
236
- "description": "Conditions to set in addition to the resolver-specific defaults when resolving imports.",
252
+ "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).",
237
253
  "items": {
238
254
  "type": "string"
239
255
  },
240
- "markdownDescription": "Conditions to set in addition to the resolver-specific defaults when resolving imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#customConditions",
256
+ "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).",
241
257
  "type": [
242
258
  "array",
243
259
  "null"
244
260
  ],
245
- "uniqueItems": true
261
+ "uniqueItems": true,
262
+ "x-intellij-html-description": "\u003cp\u003e\u003ccode\u003e--customConditions\u003c/code\u003e takes a list of additional \u003ca href=\"https://nodejs.org/api/packages.html#nested-conditions\"\u003econditions\u003c/a\u003e that should succeed when TypeScript resolves from an \u003ca href=\"https://nodejs.org/api/packages.html#exports\"\u003e\u003ccode\u003eexports\u003c/code\u003e\u003c/a\u003e or \u003ca href=\"https://nodejs.org/api/packages.html#imports\"\u003e\u003ccode\u003eimports\u003c/code\u003e\u003c/a\u003e field of a \u003ccode\u003epackage.json\u003c/code\u003e.\nThese conditions are added to whatever existing conditions a resolver will use by default.\u003c/p\u003e\n\u003cp\u003eFor example, when this field is set in a \u003ccode\u003etsconfig.json\u003c/code\u003e as so:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-jsonc\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;target\u0026quot;: \u0026quot;es2022\u0026quot;,\n \u0026quot;moduleResolution\u0026quot;: \u0026quot;bundler\u0026quot;,\n \u0026quot;customConditions\u0026quot;: [\u0026quot;my-condition\u0026quot;]\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eAny time an \u003ccode\u003eexports\u003c/code\u003e or \u003ccode\u003eimports\u003c/code\u003e field is referenced in \u003ccode\u003epackage.json\u003c/code\u003e, TypeScript will consider conditions called \u003ccode\u003emy-condition\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eSo when importing from a package with the following \u003ccode\u003epackage.json\u003c/code\u003e\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-jsonc\"\u003e{\n // ...\n \u0026quot;exports\u0026quot;: {\n \u0026quot;.\u0026quot;: {\n \u0026quot;my-condition\u0026quot;: \u0026quot;./foo.mjs\u0026quot;,\n \u0026quot;node\u0026quot;: \u0026quot;./bar.mjs\u0026quot;,\n \u0026quot;import\u0026quot;: \u0026quot;./baz.mjs\u0026quot;,\n \u0026quot;require\u0026quot;: \u0026quot;./biz.mjs\u0026quot;\n }\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eTypeScript will try to look for files corresponding to \u003ccode\u003efoo.mjs\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThis field is only valid under the \u003ccode\u003enode16\u003c/code\u003e, \u003ccode\u003enodenext\u003c/code\u003e, and \u003ccode\u003ebundler\u003c/code\u003e options for \u003ca href=\"https://typescriptlang.org/tsconfig/#moduleResolution\"\u003e\u003ccode\u003e--moduleResolution\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n"
246
263
  },
247
264
  "declaration": {
248
265
  "default": false,
249
- "description": "Generate .d.ts files from TypeScript and JavaScript files in your project.",
250
- "markdownDescription": "Generate .d.ts files from TypeScript and JavaScript files in your project.\n\nSee more: https://www.typescriptlang.org/tsconfig#declaration",
266
+ "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.",
267
+ "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.",
251
268
  "type": [
252
269
  "boolean",
253
270
  "null"
254
- ]
271
+ ],
272
+ "x-intellij-html-description": "\u003cp\u003eGenerate \u003ccode\u003e.d.ts\u003c/code\u003e files for every TypeScript or JavaScript file inside your project.\nThese \u003ccode\u003e.d.ts\u003c/code\u003e files are type definition files which describe the external API of your module.\nWith \u003ccode\u003e.d.ts\u003c/code\u003e files, tools like TypeScript can provide intellisense and accurate types for un-typed code.\u003c/p\u003e\n\u003cp\u003eWhen \u003ccode\u003edeclaration\u003c/code\u003e is set to \u003ccode\u003etrue\u003c/code\u003e, running the compiler with this TypeScript code:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eexport let helloWorld = \u0026quot;hi\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWill generate an \u003ccode\u003eindex.js\u003c/code\u003e file like this:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\nexport let helloWorld = \u0026quot;hi\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith a corresponding \u003ccode\u003ehelloWorld.d.ts\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\nexport let helloWorld = \u0026quot;hi\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhen working with \u003ccode\u003e.d.ts\u003c/code\u003e files for JavaScript files you may want to use \u003ca href=\"https://typescriptlang.org/tsconfig/#emitDeclarationOnly\"\u003e\u003ccode\u003eemitDeclarationOnly\u003c/code\u003e\u003c/a\u003e or use \u003ca href=\"https://typescriptlang.org/tsconfig/#outDir\"\u003e\u003ccode\u003eoutDir\u003c/code\u003e\u003c/a\u003e to ensure that the JavaScript files are not overwritten.\u003c/p\u003e\n"
255
273
  },
256
274
  "declarationDir": {
257
- "description": "Specify the output directory for generated declaration files.",
258
- "markdownDescription": "Specify the output directory for generated declaration files.\n\nSee more: https://www.typescriptlang.org/tsconfig#declarationDir",
275
+ "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```",
276
+ "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```",
259
277
  "type": [
260
278
  "string",
261
279
  "null"
262
- ]
280
+ ],
281
+ "x-intellij-html-description": "\u003cp\u003eOffers a way to configure the root directory for where declaration files are emitted.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003ewith this \u003ccode\u003etsconfig.json\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;declaration\u0026quot;: true,\n \u0026quot;declarationDir\u0026quot;: \u0026quot;./types\u0026quot;\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWould place the d.ts for the \u003ccode\u003eindex.ts\u003c/code\u003e in a \u003ccode\u003etypes\u003c/code\u003e folder:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eexample\n├── index.js\n├── index.ts\n├── package.json\n├── tsconfig.json\n└── types\n └── index.d.ts\n\u003c/code\u003e\u003c/pre\u003e\n"
263
282
  },
264
283
  "declarationMap": {
265
284
  "default": false,
266
- "description": "Create sourcemaps for d.ts files.",
267
- "markdownDescription": "Create sourcemaps for d.ts files.\n\nSee more: https://www.typescriptlang.org/tsconfig#declarationMap",
285
+ "description": "Generates a source map for `.d.ts` files which map back to the original `.ts` source file.\nThis will allow editors such as VS Code to go to the original `.ts` file when using features like _Go to Definition_.\n\nYou should strongly consider turning this on if you're using project references.",
286
+ "markdownDescription": "Generates a source map for `.d.ts` files which map back to the original `.ts` source file.\nThis will allow editors such as VS Code to go to the original `.ts` file when using features like _Go to Definition_.\n\nYou should strongly consider turning this on if you're using project references.",
268
287
  "type": [
269
288
  "boolean",
270
289
  "null"
271
- ]
290
+ ],
291
+ "x-intellij-html-description": "\u003cp\u003eGenerates a source map for \u003ccode\u003e.d.ts\u003c/code\u003e files which map back to the original \u003ccode\u003e.ts\u003c/code\u003e source file.\nThis will allow editors such as VS Code to go to the original \u003ccode\u003e.ts\u003c/code\u003e file when using features like \u003cem\u003eGo to Definition\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003eYou should strongly consider turning this on if you\u0026#39;re using project references.\u003c/p\u003e\n"
272
292
  },
273
293
  "diagnostics": {
274
- "description": "Output compiler performance information after building.",
275
- "markdownDescription": "Output compiler performance information after building.\n\nSee more: https://www.typescriptlang.org/tsconfig#diagnostics",
294
+ "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.",
295
+ "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.",
276
296
  "type": [
277
297
  "boolean",
278
298
  "null"
279
- ]
299
+ ],
300
+ "x-intellij-html-description": "\u003cp\u003eUsed to output diagnostic information for debugging. This command is a subset of \u003ca href=\"https://typescriptlang.org/tsconfig/#extendedDiagnostics\"\u003e\u003ccode\u003eextendedDiagnostics\u003c/code\u003e\u003c/a\u003e which are more user-facing results, and easier to interpret.\u003c/p\u003e\n\u003cp\u003eIf 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 \u003ca href=\"https://typescriptlang.org/tsconfig/#extendedDiagnostics\"\u003e\u003ccode\u003eextendedDiagnostics\u003c/code\u003e\u003c/a\u003e instead.\u003c/p\u003e\n"
280
301
  },
281
302
  "disableReferencedProjectLoad": {
282
- "description": "Reduce the number of projects loaded automatically by TypeScript.",
283
- "markdownDescription": "Reduce the number of projects loaded automatically by TypeScript.\n\nSee more: https://www.typescriptlang.org/tsconfig#disableReferencedProjectLoad",
303
+ "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.",
304
+ "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.",
284
305
  "type": [
285
306
  "boolean",
286
307
  "null"
287
- ]
308
+ ],
309
+ "x-intellij-html-description": "\u003cp\u003eIn 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 \u0026#39;Find All References\u0026#39;.\u003c/p\u003e\n\u003cp\u003eIf your project is large, you can use the flag \u003ccode\u003edisableReferencedProjectLoad\u003c/code\u003e to disable the automatic loading of all projects. Instead, projects are loaded dynamically as you open files through your editor.\u003c/p\u003e\n"
288
310
  },
289
311
  "disableSizeLimit": {
290
312
  "default": false,
291
- "description": "Remove the 20mb cap on total source code size for JavaScript files in the TypeScript language server.",
292
- "markdownDescription": "Remove the 20mb cap on total source code size for JavaScript files in the TypeScript language server.\n\nSee more: https://www.typescriptlang.org/tsconfig#disableSizeLimit",
313
+ "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.",
314
+ "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.",
293
315
  "type": [
294
316
  "boolean",
295
317
  "null"
296
- ]
318
+ ],
319
+ "x-intellij-html-description": "\u003cp\u003eTo 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.\u003c/p\u003e\n"
297
320
  },
298
321
  "disableSolutionSearching": {
299
- "description": "Opt a project out of multi-project reference checking when editing.",
300
- "markdownDescription": "Opt a project out of multi-project reference checking when editing.\n\nSee more: https://www.typescriptlang.org/tsconfig#disableSolutionSearching",
322
+ "description": "When working with [composite TypeScript projects](https://typescriptlang.org/docs/handbook/project-references.html), this option provides a way to declare that you do not want a project to be included when using features like _find all references_ or _jump to definition_ in an editor.\n\nThis flag is something you can use to increase responsiveness in large composite projects.",
323
+ "markdownDescription": "When working with [composite TypeScript projects](https://typescriptlang.org/docs/handbook/project-references.html), this option provides a way to declare that you do not want a project to be included when using features like _find all references_ or _jump to definition_ in an editor.\n\nThis flag is something you can use to increase responsiveness in large composite projects.",
301
324
  "type": [
302
325
  "boolean",
303
326
  "null"
304
- ]
327
+ ],
328
+ "x-intellij-html-description": "\u003cp\u003eWhen working with \u003ca href=\"https://typescriptlang.org/docs/handbook/project-references.html\"\u003ecomposite TypeScript projects\u003c/a\u003e, this option provides a way to declare that you do not want a project to be included when using features like \u003cem\u003efind all references\u003c/em\u003e or \u003cem\u003ejump to definition\u003c/em\u003e in an editor.\u003c/p\u003e\n\u003cp\u003eThis flag is something you can use to increase responsiveness in large composite projects.\u003c/p\u003e\n"
305
329
  },
306
330
  "disableSourceOfProjectReferenceRedirect": {
307
- "description": "Disable preferring source files instead of declaration files when referencing composite projects.",
308
- "markdownDescription": "Disable preferring source files instead of declaration files when referencing composite projects.\n\nSee more: https://www.typescriptlang.org/tsconfig#disableSourceOfProjectReferenceRedirect",
331
+ "description": "When working with [composite TypeScript projects](https://typescriptlang.org/docs/handbook/project-references.html), this option provides a way to go [back to the pre-3.7](https://typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#build-free-editing-with-project-references) behavior where d.ts files were used to as the boundaries between modules.\nIn 3.7 the source of truth is now your TypeScript files.",
332
+ "markdownDescription": "When working with [composite TypeScript projects](https://typescriptlang.org/docs/handbook/project-references.html), this option provides a way to go [back to the pre-3.7](https://typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#build-free-editing-with-project-references) behavior where d.ts files were used to as the boundaries between modules.\nIn 3.7 the source of truth is now your TypeScript files.",
309
333
  "type": [
310
334
  "boolean",
311
335
  "null"
312
- ]
336
+ ],
337
+ "x-intellij-html-description": "\u003cp\u003eWhen working with \u003ca href=\"https://typescriptlang.org/docs/handbook/project-references.html\"\u003ecomposite TypeScript projects\u003c/a\u003e, this option provides a way to go \u003ca href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#build-free-editing-with-project-references\"\u003eback to the pre-3.7\u003c/a\u003e behavior where d.ts files were used to as the boundaries between modules.\nIn 3.7 the source of truth is now your TypeScript files.\u003c/p\u003e\n"
313
338
  },
314
339
  "downlevelIteration": {
315
340
  "default": false,
316
- "description": "Emit more compliant, but verbose and less performant JavaScript for iteration.",
317
- "markdownDescription": "Emit more compliant, but verbose and less performant JavaScript for iteration.\n\nSee more: https://www.typescriptlang.org/tsconfig#downlevelIteration",
341
+ "description": "Downleveling is TypeScript's term for transpiling to an older version of JavaScript.\nThis flag is to enable support for a more accurate implementation of how modern JavaScript iterates through new concepts in older JavaScript runtimes.\n\nECMAScript 6 added several new iteration primitives: the `for / of` loop (`for (el of arr)`), Array spread (`[a, ...b]`), argument spread (`fn(...args)`), and `Symbol.iterator`.\n`downlevelIteration` allows for these iteration primitives to be used more accurately in ES5 environments if a `Symbol.iterator` implementation is present.\n\n#### Example: Effects on `for / of`\n\nWith this TypeScript code:\n\n```ts twoslash\nconst str = \"Hello!\";\nfor (const s of str) {\n console.log(s);\n}\n```\n\nWithout `downlevelIteration` enabled, a `for / of` loop on any object is downleveled to a traditional `for` loop:\n\n```ts twoslash\n// @target: ES5\n// @showEmit\nconst str = \"Hello!\";\nfor (const s of str) {\n console.log(s);\n}\n```\n\nThis is often what people expect, but it's not 100% compliant with ECMAScript iteration protocol.\nCertain strings, such as emoji (😜), have a `.length` of 2 (or even more!), but should iterate as 1 unit in a `for-of` loop.\nSee [this blog post by Jonathan New](https://blog.jonnew.com/posts/poo-dot-length-equals-two) for a longer explanation.\n\nWhen `downlevelIteration` is enabled, TypeScript will use a helper function that checks for a `Symbol.iterator` implementation (either native or polyfill).\nIf this implementation is missing, you'll fall back to index-based iteration.\n\n```ts twoslash\n// @target: ES5\n// @downlevelIteration\n// @showEmit\nconst str = \"Hello!\";\nfor (const s of str) {\n console.log(s);\n}\n```\n\nYou can use [tslib](https://www.npmjs.com/package/tslib) via [`importHelpers`](https://typescriptlang.org/tsconfig/#importHelpers) to reduce the amount of inline JavaScript too:\n\n```ts twoslash\n// @target: ES5\n// @downlevelIteration\n// @importHelpers\n// @showEmit\nconst str = \"Hello!\";\nfor (const s of str) {\n console.log(s);\n}\n```\n\n**Note:** enabling `downlevelIteration` does not improve compliance if `Symbol.iterator` is not present in the runtime.\n\n#### Example: Effects on Array Spreads\n\nThis is an array spread:\n\n```js\n// Make a new array whose elements are 1 followed by the elements of arr2\nconst arr = [1, ...arr2];\n```\n\nBased on the description, it sounds easy to downlevel to ES5:\n\n```js\n// The same, right?\nconst arr = [1].concat(arr2);\n```\n\nHowever, this is observably different in certain rare cases.\n\nFor example, if a source array is missing one or more items (contains a hole), the spread syntax will replace each empty item with `undefined`, whereas `.concat` will leave them intact.\n\n```js\n// Make an array where the element at index 1 is missing\nlet arrayWithHole = ['a', , 'c'];\nlet spread = [...arrayWithHole];\nlet concatenated = [].concat(arrayWithHole);\n\nconsole.log(arrayWithHole)\n// [ 'a', \u003c1 empty item\u003e, 'c' ]\nconsole.log(spread)\n// [ 'a', undefined, 'c' ]\nconsole.log(concatenated)\n// [ 'a', \u003c1 empty item\u003e, 'c' ]\n```\n\nJust as with `for / of`, `downlevelIteration` will use `Symbol.iterator` (if present) to more accurately emulate ES 6 behavior.",
342
+ "markdownDescription": "Downleveling is TypeScript's term for transpiling to an older version of JavaScript.\nThis flag is to enable support for a more accurate implementation of how modern JavaScript iterates through new concepts in older JavaScript runtimes.\n\nECMAScript 6 added several new iteration primitives: the `for / of` loop (`for (el of arr)`), Array spread (`[a, ...b]`), argument spread (`fn(...args)`), and `Symbol.iterator`.\n`downlevelIteration` allows for these iteration primitives to be used more accurately in ES5 environments if a `Symbol.iterator` implementation is present.\n\n#### Example: Effects on `for / of`\n\nWith this TypeScript code:\n\n```ts twoslash\nconst str = \"Hello!\";\nfor (const s of str) {\n console.log(s);\n}\n```\n\nWithout `downlevelIteration` enabled, a `for / of` loop on any object is downleveled to a traditional `for` loop:\n\n```ts twoslash\n// @target: ES5\n// @showEmit\nconst str = \"Hello!\";\nfor (const s of str) {\n console.log(s);\n}\n```\n\nThis is often what people expect, but it's not 100% compliant with ECMAScript iteration protocol.\nCertain strings, such as emoji (😜), have a `.length` of 2 (or even more!), but should iterate as 1 unit in a `for-of` loop.\nSee [this blog post by Jonathan New](https://blog.jonnew.com/posts/poo-dot-length-equals-two) for a longer explanation.\n\nWhen `downlevelIteration` is enabled, TypeScript will use a helper function that checks for a `Symbol.iterator` implementation (either native or polyfill).\nIf this implementation is missing, you'll fall back to index-based iteration.\n\n```ts twoslash\n// @target: ES5\n// @downlevelIteration\n// @showEmit\nconst str = \"Hello!\";\nfor (const s of str) {\n console.log(s);\n}\n```\n\nYou can use [tslib](https://www.npmjs.com/package/tslib) via [`importHelpers`](https://typescriptlang.org/tsconfig/#importHelpers) to reduce the amount of inline JavaScript too:\n\n```ts twoslash\n// @target: ES5\n// @downlevelIteration\n// @importHelpers\n// @showEmit\nconst str = \"Hello!\";\nfor (const s of str) {\n console.log(s);\n}\n```\n\n**Note:** enabling `downlevelIteration` does not improve compliance if `Symbol.iterator` is not present in the runtime.\n\n#### Example: Effects on Array Spreads\n\nThis is an array spread:\n\n```js\n// Make a new array whose elements are 1 followed by the elements of arr2\nconst arr = [1, ...arr2];\n```\n\nBased on the description, it sounds easy to downlevel to ES5:\n\n```js\n// The same, right?\nconst arr = [1].concat(arr2);\n```\n\nHowever, this is observably different in certain rare cases.\n\nFor example, if a source array is missing one or more items (contains a hole), the spread syntax will replace each empty item with `undefined`, whereas `.concat` will leave them intact.\n\n```js\n// Make an array where the element at index 1 is missing\nlet arrayWithHole = ['a', , 'c'];\nlet spread = [...arrayWithHole];\nlet concatenated = [].concat(arrayWithHole);\n\nconsole.log(arrayWithHole)\n// [ 'a', \u003c1 empty item\u003e, 'c' ]\nconsole.log(spread)\n// [ 'a', undefined, 'c' ]\nconsole.log(concatenated)\n// [ 'a', \u003c1 empty item\u003e, 'c' ]\n```\n\nJust as with `for / of`, `downlevelIteration` will use `Symbol.iterator` (if present) to more accurately emulate ES 6 behavior.",
318
343
  "type": [
319
344
  "boolean",
320
345
  "null"
321
- ]
346
+ ],
347
+ "x-intellij-html-description": "\u003cp\u003eDownleveling is TypeScript\u0026#39;s term for transpiling to an older version of JavaScript.\nThis flag is to enable support for a more accurate implementation of how modern JavaScript iterates through new concepts in older JavaScript runtimes.\u003c/p\u003e\n\u003cp\u003eECMAScript 6 added several new iteration primitives: the \u003ccode\u003efor / of\u003c/code\u003e loop (\u003ccode\u003efor (el of arr)\u003c/code\u003e), Array spread (\u003ccode\u003e[a, ...b]\u003c/code\u003e), argument spread (\u003ccode\u003efn(...args)\u003c/code\u003e), and \u003ccode\u003eSymbol.iterator\u003c/code\u003e.\n\u003ccode\u003edownlevelIteration\u003c/code\u003e allows for these iteration primitives to be used more accurately in ES5 environments if a \u003ccode\u003eSymbol.iterator\u003c/code\u003e implementation is present.\u003c/p\u003e\n\u003ch4\u003eExample: Effects on \u003ccode\u003efor / of\u003c/code\u003e\u003c/h4\u003e\n\u003cp\u003eWith this TypeScript code:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003econst str = \u0026quot;Hello!\u0026quot;;\nfor (const s of str) {\n console.log(s);\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWithout \u003ccode\u003edownlevelIteration\u003c/code\u003e enabled, a \u003ccode\u003efor / of\u003c/code\u003e loop on any object is downleveled to a traditional \u003ccode\u003efor\u003c/code\u003e loop:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @target: ES5\n// @showEmit\nconst str = \u0026quot;Hello!\u0026quot;;\nfor (const s of str) {\n console.log(s);\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis is often what people expect, but it\u0026#39;s not 100% compliant with ECMAScript iteration protocol.\nCertain strings, such as emoji (😜), have a \u003ccode\u003e.length\u003c/code\u003e of 2 (or even more!), but should iterate as 1 unit in a \u003ccode\u003efor-of\u003c/code\u003e loop.\nSee \u003ca href=\"https://blog.jonnew.com/posts/poo-dot-length-equals-two\"\u003ethis blog post by Jonathan New\u003c/a\u003e for a longer explanation.\u003c/p\u003e\n\u003cp\u003eWhen \u003ccode\u003edownlevelIteration\u003c/code\u003e is enabled, TypeScript will use a helper function that checks for a \u003ccode\u003eSymbol.iterator\u003c/code\u003e implementation (either native or polyfill).\nIf this implementation is missing, you\u0026#39;ll fall back to index-based iteration.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @target: ES5\n// @downlevelIteration\n// @showEmit\nconst str = \u0026quot;Hello!\u0026quot;;\nfor (const s of str) {\n console.log(s);\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eYou can use \u003ca href=\"https://www.npmjs.com/package/tslib\"\u003etslib\u003c/a\u003e via \u003ca href=\"https://typescriptlang.org/tsconfig/#importHelpers\"\u003e\u003ccode\u003eimportHelpers\u003c/code\u003e\u003c/a\u003e to reduce the amount of inline JavaScript too:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @target: ES5\n// @downlevelIteration\n// @importHelpers\n// @showEmit\nconst str = \u0026quot;Hello!\u0026quot;;\nfor (const s of str) {\n console.log(s);\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003cstrong\u003eNote:\u003c/strong\u003e enabling \u003ccode\u003edownlevelIteration\u003c/code\u003e does not improve compliance if \u003ccode\u003eSymbol.iterator\u003c/code\u003e is not present in the runtime.\u003c/p\u003e\n\u003ch4\u003eExample: Effects on Array Spreads\u003c/h4\u003e\n\u003cp\u003eThis is an array spread:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-js\"\u003e// Make a new array whose elements are 1 followed by the elements of arr2\nconst arr = [1, ...arr2];\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eBased on the description, it sounds easy to downlevel to ES5:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-js\"\u003e// The same, right?\nconst arr = [1].concat(arr2);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eHowever, this is observably different in certain rare cases.\u003c/p\u003e\n\u003cp\u003eFor example, if a source array is missing one or more items (contains a hole), the spread syntax will replace each empty item with \u003ccode\u003eundefined\u003c/code\u003e, whereas \u003ccode\u003e.concat\u003c/code\u003e will leave them intact.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-js\"\u003e// Make an array where the element at index 1 is missing\nlet arrayWithHole = [\u0026#39;a\u0026#39;, , \u0026#39;c\u0026#39;];\nlet spread = [...arrayWithHole];\nlet concatenated = [].concat(arrayWithHole);\n\nconsole.log(arrayWithHole)\n// [ \u0026#39;a\u0026#39;, \u0026lt;1 empty item\u0026gt;, \u0026#39;c\u0026#39; ]\nconsole.log(spread)\n// [ \u0026#39;a\u0026#39;, undefined, \u0026#39;c\u0026#39; ]\nconsole.log(concatenated)\n// [ \u0026#39;a\u0026#39;, \u0026lt;1 empty item\u0026gt;, \u0026#39;c\u0026#39; ]\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eJust as with \u003ccode\u003efor / of\u003c/code\u003e, \u003ccode\u003edownlevelIteration\u003c/code\u003e will use \u003ccode\u003eSymbol.iterator\u003c/code\u003e (if present) to more accurately emulate ES 6 behavior.\u003c/p\u003e\n"
322
348
  },
323
349
  "emitBOM": {
324
350
  "default": false,
325
- "description": "Emit a UTF-8 Byte Order Mark (BOM) in the beginning of output files.",
326
- "markdownDescription": "Emit a UTF-8 Byte Order Mark (BOM) in the beginning of output files.\n\nSee more: https://www.typescriptlang.org/tsconfig#emitBOM",
351
+ "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.",
352
+ "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.",
327
353
  "type": [
328
354
  "boolean",
329
355
  "null"
330
- ]
356
+ ],
357
+ "x-intellij-html-description": "\u003cp\u003eControls whether TypeScript will emit a \u003ca href=\"https://wikipedia.org/wiki/Byte_order_mark\"\u003ebyte order mark (BOM)\u003c/a\u003e 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 \u003ccode\u003efalse\u003c/code\u003e is generally best unless you have a reason to change it.\u003c/p\u003e\n"
331
358
  },
332
359
  "emitDeclarationOnly": {
333
360
  "default": false,
334
- "description": "Only output d.ts files and not JavaScript files.",
335
- "markdownDescription": "Only output d.ts files and not JavaScript files.\n\nSee more: https://www.typescriptlang.org/tsconfig#emitDeclarationOnly",
361
+ "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.",
362
+ "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.",
336
363
  "type": [
337
364
  "boolean",
338
365
  "null"
339
- ]
366
+ ],
367
+ "x-intellij-html-description": "\u003cp\u003e\u003cem\u003eOnly\u003c/em\u003e emit \u003ccode\u003e.d.ts\u003c/code\u003e files; do not emit \u003ccode\u003e.js\u003c/code\u003e files.\u003c/p\u003e\n\u003cp\u003eThis setting is useful in two cases:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eYou are using a transpiler other than TypeScript to generate your JavaScript.\u003c/li\u003e\n\u003cli\u003eYou are using TypeScript to only generate \u003ccode\u003ed.ts\u003c/code\u003e files for your consumers.\u003c/li\u003e\n\u003c/ul\u003e\n"
340
368
  },
341
369
  "emitDecoratorMetadata": {
342
- "description": "Emit design-type metadata for decorated declarations in source files.",
343
- "markdownDescription": "Emit design-type metadata for decorated declarations in source files.\n\nSee more: https://www.typescriptlang.org/tsconfig#emitDecoratorMetadata",
370
+ "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```",
371
+ "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```",
344
372
  "type": [
345
373
  "boolean",
346
374
  "null"
347
- ]
375
+ ],
376
+ "x-intellij-html-description": "\u003cp\u003eEnables experimental support for emitting type metadata for decorators which works with the module \u003ca href=\"https://www.npmjs.com/package/reflect-metadata\"\u003e\u003ccode\u003ereflect-metadata\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eFor example, here is the TypeScript\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith \u003ccode\u003eemitDecoratorMetadata\u003c/code\u003e not set to true (default) the emitted JavaScript is:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith \u003ccode\u003eemitDecoratorMetadata\u003c/code\u003e set to true the emitted JavaScript is:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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\u003c/code\u003e\u003c/pre\u003e\n"
348
377
  },
349
378
  "erasableSyntaxOnly": {
350
379
  "default": false,
351
- "description": "Do not allow runtime constructs that are not part of ECMAScript.",
352
- "markdownDescription": "Do not allow runtime constructs that are not part of ECMAScript.\n\nSee more: https://www.typescriptlang.org/tsconfig#erasableSyntaxOnly",
380
+ "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* `\u003cprefix\u003e`-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: \u003cprefix\u003e-style type assertion.\nconst num = \u003cnumber\u003e1;\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.",
381
+ "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* `\u003cprefix\u003e`-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: \u003cprefix\u003e-style type assertion.\nconst num = \u003cnumber\u003e1;\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.",
353
382
  "type": [
354
383
  "boolean",
355
384
  "null"
356
- ]
385
+ ],
386
+ "x-intellij-html-description": "\u003cp\u003eNode.js \u003ca href=\"https://nodejs.org/api/typescript.html#type-stripping\"\u003esupports running TypeScript files directly\u003c/a\u003e 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 \u003cem\u003eerase\u003c/em\u003e any TypeScript-specific syntax from a file, leaving behind a valid JavaScript file.\u003c/p\u003e\n\u003cp\u003eThat means the following constructs are not supported:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003eenum\u003c/code\u003e declarations\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003enamespace\u003c/code\u003es and \u003ccode\u003emodule\u003c/code\u003es with runtime code\u003c/li\u003e\n\u003cli\u003eparameter properties in classes\u003c/li\u003e\n\u003cli\u003eNon-ECMAScript \u003ccode\u003eimport =\u003c/code\u003e and \u003ccode\u003eexport =\u003c/code\u003e assignments\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e\u0026lt;prefix\u0026gt;\u003c/code\u003e-style type assertions\u003c/li\u003e\n\u003c/ul\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// ❌ error: An `import ... = require(...)` alias\nimport foo = require(\u0026quot;foo\u0026quot;);\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: \u0026lt;prefix\u0026gt;-style type assertion.\nconst num = \u0026lt;number\u0026gt;1;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eSimilar tools like \u003ca href=\"https://github.com/bloomberg/ts-blank-space\"\u003ets-blank-space\u003c/a\u003e or \u003ca href=\"https://github.com/nodejs/amaro\"\u003eAmaro\u003c/a\u003e (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\u0026#39;t meet these requirements, but you still won\u0026#39;t find out your code doesn\u0026#39;t work until you actually try to run it.\u003c/p\u003e\n\u003cp\u003eThe \u003ccode\u003e--erasableSyntaxOnly\u003c/code\u003e flag will cause TypeScript to error on most TypeScript-specific constructs that have runtime behavior.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eclass C {\n constructor(public x: number) { }\n // ~~~~~~~~~~~~~~~~\n // error! This syntax is not allowed when \u0026#39;erasableSyntaxOnly\u0026#39; is enabled.\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eTypically, you will want to combine this flag with the \u003ccode\u003e--verbatimModuleSyntax\u003c/code\u003e, which ensures that a module contains the appropriate import syntax, and that import elision does not take place.\u003c/p\u003e\n"
357
387
  },
358
388
  "esModuleInterop": {
359
389
  "default": false,
360
- "description": "Emit additional JavaScript to ease support for importing CommonJS modules. This enables `allowSyntheticDefaultImports` for type compatibility.",
361
- "markdownDescription": "Emit additional JavaScript to ease support for importing CommonJS modules. This enables `allowSyntheticDefaultImports` for type compatibility.\n\nSee more: https://www.typescriptlang.org/tsconfig#esModuleInterop",
390
+ "description": "By default (with `esModuleInterop` false or not set) TypeScript treats CommonJS/AMD/UMD modules similar to ES6 modules. In doing this, there are two parts in particular which turned out to be flawed assumptions:\n\n- a namespace import like `import * as moment from \"moment\"` acts the same as `const moment = require(\"moment\")`\n\n- a default import like `import moment from \"moment\"` acts the same as `const moment = require(\"moment\").default`\n\nThis mis-match causes these two issues:\n\n- the ES6 modules spec states that a namespace import (`import * as x`) can only be an object, by having TypeScript\n treating it the same as `= require(\"x\")` then TypeScript allowed for the import to be treated as a function and be callable. That's not valid according to the spec.\n\n- while accurate to the ES6 modules spec, most libraries with CommonJS/AMD/UMD modules didn't conform as strictly as TypeScript's implementation.\n\nTurning on `esModuleInterop` will fix both of these problems in the code transpiled by TypeScript. The first changes the behavior in the compiler, the second is fixed by two new helper functions which provide a shim to ensure compatibility in the emitted JavaScript:\n\n```ts\nimport * as fs from \"fs\";\nimport _ from \"lodash\";\n\nfs.readFileSync(\"file.txt\", \"utf8\");\n_.chunk([\"a\", \"b\", \"c\", \"d\"], 2);\n```\n\nWith `esModuleInterop` disabled:\n\n```ts twoslash\n// @noErrors\n// @showEmit\n// @esModuleInterop: false\n// @module: commonjs\nimport * as fs from \"fs\";\nimport _ from \"lodash\";\n\nfs.readFileSync(\"file.txt\", \"utf8\");\n_.chunk([\"a\", \"b\", \"c\", \"d\"], 2);\n```\n\nWith `esModuleInterop` set to `true`:\n\n```ts twoslash\n// @noErrors\n// @showEmit\n// @esModuleInterop\n// @module: commonjs\nimport * as fs from \"fs\";\nimport _ from \"lodash\";\n\nfs.readFileSync(\"file.txt\", \"utf8\");\n_.chunk([\"a\", \"b\", \"c\", \"d\"], 2);\n```\n\n_Note_: The namespace import `import * as fs from \"fs\"` only accounts for properties which [are owned](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty) (basically properties set on the object and not via the prototype chain) on the imported object. If the module you're importing defines its API using inherited properties, you need to use the default import form (`import fs from \"fs\"`), or disable `esModuleInterop`.\n\n_Note_: You can make JS emit terser by enabling [`importHelpers`](https://typescriptlang.org/tsconfig/#importHelpers):\n\n```ts twoslash\n// @noErrors\n// @showEmit\n// @esModuleInterop\n// @importHelpers\n// @module: commonjs\nimport * as fs from \"fs\";\nimport _ from \"lodash\";\n\nfs.readFileSync(\"file.txt\", \"utf8\");\n_.chunk([\"a\", \"b\", \"c\", \"d\"], 2);\n```\n\nEnabling `esModuleInterop` will also enable [`allowSyntheticDefaultImports`](https://typescriptlang.org/tsconfig/#allowSyntheticDefaultImports).",
391
+ "markdownDescription": "By default (with `esModuleInterop` false or not set) TypeScript treats CommonJS/AMD/UMD modules similar to ES6 modules. In doing this, there are two parts in particular which turned out to be flawed assumptions:\n\n- a namespace import like `import * as moment from \"moment\"` acts the same as `const moment = require(\"moment\")`\n\n- a default import like `import moment from \"moment\"` acts the same as `const moment = require(\"moment\").default`\n\nThis mis-match causes these two issues:\n\n- the ES6 modules spec states that a namespace import (`import * as x`) can only be an object, by having TypeScript\n treating it the same as `= require(\"x\")` then TypeScript allowed for the import to be treated as a function and be callable. That's not valid according to the spec.\n\n- while accurate to the ES6 modules spec, most libraries with CommonJS/AMD/UMD modules didn't conform as strictly as TypeScript's implementation.\n\nTurning on `esModuleInterop` will fix both of these problems in the code transpiled by TypeScript. The first changes the behavior in the compiler, the second is fixed by two new helper functions which provide a shim to ensure compatibility in the emitted JavaScript:\n\n```ts\nimport * as fs from \"fs\";\nimport _ from \"lodash\";\n\nfs.readFileSync(\"file.txt\", \"utf8\");\n_.chunk([\"a\", \"b\", \"c\", \"d\"], 2);\n```\n\nWith `esModuleInterop` disabled:\n\n```ts twoslash\n// @noErrors\n// @showEmit\n// @esModuleInterop: false\n// @module: commonjs\nimport * as fs from \"fs\";\nimport _ from \"lodash\";\n\nfs.readFileSync(\"file.txt\", \"utf8\");\n_.chunk([\"a\", \"b\", \"c\", \"d\"], 2);\n```\n\nWith `esModuleInterop` set to `true`:\n\n```ts twoslash\n// @noErrors\n// @showEmit\n// @esModuleInterop\n// @module: commonjs\nimport * as fs from \"fs\";\nimport _ from \"lodash\";\n\nfs.readFileSync(\"file.txt\", \"utf8\");\n_.chunk([\"a\", \"b\", \"c\", \"d\"], 2);\n```\n\n_Note_: The namespace import `import * as fs from \"fs\"` only accounts for properties which [are owned](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty) (basically properties set on the object and not via the prototype chain) on the imported object. If the module you're importing defines its API using inherited properties, you need to use the default import form (`import fs from \"fs\"`), or disable `esModuleInterop`.\n\n_Note_: You can make JS emit terser by enabling [`importHelpers`](https://typescriptlang.org/tsconfig/#importHelpers):\n\n```ts twoslash\n// @noErrors\n// @showEmit\n// @esModuleInterop\n// @importHelpers\n// @module: commonjs\nimport * as fs from \"fs\";\nimport _ from \"lodash\";\n\nfs.readFileSync(\"file.txt\", \"utf8\");\n_.chunk([\"a\", \"b\", \"c\", \"d\"], 2);\n```\n\nEnabling `esModuleInterop` will also enable [`allowSyntheticDefaultImports`](https://typescriptlang.org/tsconfig/#allowSyntheticDefaultImports).",
362
392
  "type": [
363
393
  "boolean",
364
394
  "null"
365
- ]
395
+ ],
396
+ "x-intellij-html-description": "\u003cp\u003eBy default (with \u003ccode\u003eesModuleInterop\u003c/code\u003e false or not set) TypeScript treats CommonJS/AMD/UMD modules similar to ES6 modules. In doing this, there are two parts in particular which turned out to be flawed assumptions:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003ea namespace import like \u003ccode\u003eimport * as moment from \u0026quot;moment\u0026quot;\u003c/code\u003e acts the same as \u003ccode\u003econst moment = require(\u0026quot;moment\u0026quot;)\u003c/code\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003cp\u003ea default import like \u003ccode\u003eimport moment from \u0026quot;moment\u0026quot;\u003c/code\u003e acts the same as \u003ccode\u003econst moment = require(\u0026quot;moment\u0026quot;).default\u003c/code\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThis mis-match causes these two issues:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cp\u003ethe ES6 modules spec states that a namespace import (\u003ccode\u003eimport * as x\u003c/code\u003e) can only be an object, by having TypeScript\ntreating it the same as \u003ccode\u003e= require(\u0026quot;x\u0026quot;)\u003c/code\u003e then TypeScript allowed for the import to be treated as a function and be callable. That\u0026#39;s not valid according to the spec.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\u003cp\u003ewhile accurate to the ES6 modules spec, most libraries with CommonJS/AMD/UMD modules didn\u0026#39;t conform as strictly as TypeScript\u0026#39;s implementation.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eTurning on \u003ccode\u003eesModuleInterop\u003c/code\u003e will fix both of these problems in the code transpiled by TypeScript. The first changes the behavior in the compiler, the second is fixed by two new helper functions which provide a shim to ensure compatibility in the emitted JavaScript:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eimport * as fs from \u0026quot;fs\u0026quot;;\nimport _ from \u0026quot;lodash\u0026quot;;\n\nfs.readFileSync(\u0026quot;file.txt\u0026quot;, \u0026quot;utf8\u0026quot;);\n_.chunk([\u0026quot;a\u0026quot;, \u0026quot;b\u0026quot;, \u0026quot;c\u0026quot;, \u0026quot;d\u0026quot;], 2);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith \u003ccode\u003eesModuleInterop\u003c/code\u003e disabled:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @noErrors\n// @showEmit\n// @esModuleInterop: false\n// @module: commonjs\nimport * as fs from \u0026quot;fs\u0026quot;;\nimport _ from \u0026quot;lodash\u0026quot;;\n\nfs.readFileSync(\u0026quot;file.txt\u0026quot;, \u0026quot;utf8\u0026quot;);\n_.chunk([\u0026quot;a\u0026quot;, \u0026quot;b\u0026quot;, \u0026quot;c\u0026quot;, \u0026quot;d\u0026quot;], 2);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith \u003ccode\u003eesModuleInterop\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @noErrors\n// @showEmit\n// @esModuleInterop\n// @module: commonjs\nimport * as fs from \u0026quot;fs\u0026quot;;\nimport _ from \u0026quot;lodash\u0026quot;;\n\nfs.readFileSync(\u0026quot;file.txt\u0026quot;, \u0026quot;utf8\u0026quot;);\n_.chunk([\u0026quot;a\u0026quot;, \u0026quot;b\u0026quot;, \u0026quot;c\u0026quot;, \u0026quot;d\u0026quot;], 2);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003cem\u003eNote\u003c/em\u003e: The namespace import \u003ccode\u003eimport * as fs from \u0026quot;fs\u0026quot;\u003c/code\u003e only accounts for properties which \u003ca href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty\"\u003eare owned\u003c/a\u003e (basically properties set on the object and not via the prototype chain) on the imported object. If the module you\u0026#39;re importing defines its API using inherited properties, you need to use the default import form (\u003ccode\u003eimport fs from \u0026quot;fs\u0026quot;\u003c/code\u003e), or disable \u003ccode\u003eesModuleInterop\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eNote\u003c/em\u003e: You can make JS emit terser by enabling \u003ca href=\"https://typescriptlang.org/tsconfig/#importHelpers\"\u003e\u003ccode\u003eimportHelpers\u003c/code\u003e\u003c/a\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @noErrors\n// @showEmit\n// @esModuleInterop\n// @importHelpers\n// @module: commonjs\nimport * as fs from \u0026quot;fs\u0026quot;;\nimport _ from \u0026quot;lodash\u0026quot;;\n\nfs.readFileSync(\u0026quot;file.txt\u0026quot;, \u0026quot;utf8\u0026quot;);\n_.chunk([\u0026quot;a\u0026quot;, \u0026quot;b\u0026quot;, \u0026quot;c\u0026quot;, \u0026quot;d\u0026quot;], 2);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEnabling \u003ccode\u003eesModuleInterop\u003c/code\u003e will also enable \u003ca href=\"https://typescriptlang.org/tsconfig/#allowSyntheticDefaultImports\"\u003e\u003ccode\u003eallowSyntheticDefaultImports\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n"
366
397
  },
367
398
  "exactOptionalPropertyTypes": {
368
399
  "default": false,
369
- "description": "Interpret optional property types as written, rather than adding `undefined`.",
370
- "markdownDescription": "Interpret optional property types as written, rather than adding `undefined`.\n\nSee more: https://www.typescriptlang.org/tsconfig#exactOptionalPropertyTypes",
400
+ "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```",
401
+ "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```",
371
402
  "type": [
372
403
  "boolean",
373
404
  "null"
374
- ]
405
+ ],
406
+ "x-intellij-html-description": "\u003cp\u003eWith exactOptionalPropertyTypes enabled, TypeScript applies stricter rules around how it handles properties on \u003ccode\u003etype\u003c/code\u003e or \u003ccode\u003einterfaces\u003c/code\u003e which have a \u003ccode\u003e?\u003c/code\u003e prefix.\u003c/p\u003e\n\u003cp\u003eFor example, this interface declares that there is a property which can be one of two strings: \u0026#39;dark\u0026#39; or \u0026#39;light\u0026#39; or it should not be in the object.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003einterface UserDefaults {\n // The absence of a value represents \u0026#39;system\u0026#39;\n colorThemeOverride?: \u0026quot;dark\u0026quot; | \u0026quot;light\u0026quot;;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWithout this flag enabled, there are three values which you can set \u003ccode\u003ecolorThemeOverride\u003c/code\u003e to be: \u0026quot;dark\u0026quot;, \u0026quot;light\u0026quot; and \u003ccode\u003eundefined\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eSetting the value to \u003ccode\u003eundefined\u003c/code\u003e will allow most JavaScript runtime checks for the existence to fail, which is effectively falsy. However, this isn\u0026#39;t quite accurate; \u003ccode\u003ecolorThemeOverride: undefined\u003c/code\u003e is not the same as \u003ccode\u003ecolorThemeOverride\u003c/code\u003e not being defined. For example, \u003ccode\u003e\u0026quot;colorThemeOverride\u0026quot; in settings\u003c/code\u003e would have different behavior with \u003ccode\u003eundefined\u003c/code\u003e as the key compared to not being defined.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003eexactOptionalPropertyTypes\u003c/code\u003e makes TypeScript truly enforce the definition provided as an optional property:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @exactOptionalPropertyTypes\n// @errors: 2322 2412\ninterface UserDefaults {\n colorThemeOverride?: \u0026quot;dark\u0026quot; | \u0026quot;light\u0026quot;;\n}\ndeclare function getUserSettings(): UserDefaults;\n// ---cut---\nconst settings = getUserSettings();\nsettings.colorThemeOverride = \u0026quot;dark\u0026quot;;\nsettings.colorThemeOverride = \u0026quot;light\u0026quot;;\n\n// But not:\nsettings.colorThemeOverride = undefined;\n\u003c/code\u003e\u003c/pre\u003e\n"
375
407
  },
376
408
  "experimentalDecorators": {
377
- "description": "Enable experimental support for legacy experimental decorators.",
378
- "markdownDescription": "Enable experimental support for legacy experimental decorators.\n\nSee more: https://www.typescriptlang.org/tsconfig#experimentalDecorators",
409
+ "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).",
410
+ "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).",
379
411
  "type": [
380
412
  "boolean",
381
413
  "null"
382
- ]
414
+ ],
415
+ "x-intellij-html-description": "\u003cp\u003eEnables \u003ca href=\"https://github.com/tc39/proposal-decorators\"\u003eexperimental support for decorators\u003c/a\u003e, which is a version of decorators that predates the TC39 standardization process.\u003c/p\u003e\n\u003cp\u003eDecorators are a language feature which hasn\u0026#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.\u003c/p\u003e\n\u003cp\u003eYou can find out more about decorator support in TypeScript in \u003ca href=\"https://typescriptlang.org/docs/handbook/decorators.html\"\u003ethe handbook\u003c/a\u003e.\u003c/p\u003e\n"
383
416
  },
384
417
  "extendedDiagnostics": {
385
418
  "default": false,
386
- "description": "Output more detailed compiler performance information after building.",
387
- "markdownDescription": "Output more detailed compiler performance information after building.\n\nSee more: https://www.typescriptlang.org/tsconfig#extendedDiagnostics",
419
+ "description": "You can use this flag to discover where TypeScript is spending its time when compiling.\nThis is a tool used for understanding the performance characteristics of your codebase overall.\n\nYou can learn more about how to measure and understand the output in the performance [section of the wiki](https://github.com/microsoft/TypeScript/wiki/Performance).",
420
+ "markdownDescription": "You can use this flag to discover where TypeScript is spending its time when compiling.\nThis is a tool used for understanding the performance characteristics of your codebase overall.\n\nYou can learn more about how to measure and understand the output in the performance [section of the wiki](https://github.com/microsoft/TypeScript/wiki/Performance).",
388
421
  "type": [
389
422
  "boolean",
390
423
  "null"
391
- ]
424
+ ],
425
+ "x-intellij-html-description": "\u003cp\u003eYou can use this flag to discover where TypeScript is spending its time when compiling.\nThis is a tool used for understanding the performance characteristics of your codebase overall.\u003c/p\u003e\n\u003cp\u003eYou can learn more about how to measure and understand the output in the performance \u003ca href=\"https://github.com/microsoft/TypeScript/wiki/Performance\"\u003esection of the wiki\u003c/a\u003e.\u003c/p\u003e\n"
392
426
  },
393
427
  "fallbackPolling": {
394
428
  "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.",
@@ -404,40 +438,50 @@
404
438
  },
405
439
  "forceConsistentCasingInFileNames": {
406
440
  "default": true,
407
- "description": "Ensure that casing is correct in imports.",
408
- "markdownDescription": "Ensure that casing is correct in imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#forceConsistentCasingInFileNames",
441
+ "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.",
442
+ "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.",
409
443
  "type": [
410
444
  "boolean",
411
445
  "null"
412
- ]
446
+ ],
447
+ "x-intellij-html-description": "\u003cp\u003eTypeScript follows the case sensitivity rules of the file system it\u0026#39;s running on.\nThis can be problematic if some developers are working in a case-sensitive file system and others aren\u0026#39;t.\nIf a file attempts to import \u003ccode\u003efileManager.ts\u003c/code\u003e by specifying \u003ccode\u003e./FileManager.ts\u003c/code\u003e the file will be found in a case-insensitive file system, but not on a case-sensitive file system.\u003c/p\u003e\n\u003cp\u003eWhen 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.\u003c/p\u003e\n"
413
448
  },
414
449
  "generateCpuProfile": {
415
450
  "default": "profile.cpuprofile",
416
- "description": "Emit a v8 CPU profile of the compiler run for debugging.",
417
- "markdownDescription": "Emit a v8 CPU profile of the compiler run for debugging.\n\nSee more: https://www.typescriptlang.org/tsconfig#generateCpuProfile",
451
+ "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).",
452
+ "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).",
418
453
  "type": [
419
454
  "string",
420
455
  "null"
421
- ]
456
+ ],
457
+ "x-intellij-html-description": "\u003cp\u003eThis 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.\u003c/p\u003e\n\u003cp\u003eThis option can only be used from the CLI via: \u003ccode\u003e--generateCpuProfile tsc-output.cpuprofile\u003c/code\u003e.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-sh\"\u003enpm run tsc --generateCpuProfile tsc-output.cpuprofile\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis file can be opened in a chromium based browser like Chrome or Edge Developer in \u003ca href=\"https://developers.google.com/web/tools/chrome-devtools/rendering-tools/js-execution\"\u003ethe CPU profiler\u003c/a\u003e section.\nYou can learn more about understanding the compilers performance in the \u003ca href=\"https://github.com/microsoft/TypeScript/wiki/Performance\"\u003eTypeScript wiki section on performance\u003c/a\u003e.\u003c/p\u003e\n"
458
+ },
459
+ "ignoreDeprecations": {
460
+ "description": "Can be used to silence deprecation warnings about features, that are slated for removal in a future release. For example, if you are using a feature that is deprecated in TypeScript 6.0 but you want to continue using it without seeing warnings until it is removed in TypeScript 7.0, you can set `ignoreDeprecations` to `6.0`.",
461
+ "enum": [
462
+ "5.0",
463
+ "6.0"
464
+ ],
465
+ "type": "string"
422
466
  },
423
467
  "importHelpers": {
424
468
  "default": false,
425
- "description": "Allow importing helper functions from tslib once per project, instead of including them per-file.",
426
- "markdownDescription": "Allow importing helper functions from tslib once per project, instead of including them per-file.\n\nSee more: https://www.typescriptlang.org/tsconfig#importHelpers",
469
+ "description": "For certain downleveling operations, TypeScript uses some helper code for operations like extending class, spreading arrays or objects, and async operations.\nBy default, these helpers are inserted into files which use them.\nThis can result in code duplication if the same helper is used in many different modules.\n\nIf the `importHelpers` flag is on, these helper functions are instead imported from the [tslib](https://www.npmjs.com/package/tslib) module.\nYou will need to ensure that the `tslib` module is able to be imported at runtime.\nThis only affects modules; global script files will not attempt to import modules.\n\nFor example, with this TypeScript:\n\n```ts\nexport function fn(arr: number[]) {\n const arr2 = [1, ...arr];\n}\n```\n\nTurning on [`downlevelIteration`](https://typescriptlang.org/tsconfig/#downlevelIteration) and `importHelpers` is still false:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\n// @downleveliteration\nexport function fn(arr: number[]) {\n const arr2 = [1, ...arr];\n}\n```\n\nThen turning on both [`downlevelIteration`](https://typescriptlang.org/tsconfig/#downlevelIteration) and `importHelpers`:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\n// @downleveliteration\n// @importhelpers\n// @noErrors\nexport function fn(arr: number[]) {\n const arr2 = [1, ...arr];\n}\n```\n\nYou can use [`noEmitHelpers`](https://typescriptlang.org/tsconfig/#noEmitHelpers) when you provide your own implementations of these functions.",
470
+ "markdownDescription": "For certain downleveling operations, TypeScript uses some helper code for operations like extending class, spreading arrays or objects, and async operations.\nBy default, these helpers are inserted into files which use them.\nThis can result in code duplication if the same helper is used in many different modules.\n\nIf the `importHelpers` flag is on, these helper functions are instead imported from the [tslib](https://www.npmjs.com/package/tslib) module.\nYou will need to ensure that the `tslib` module is able to be imported at runtime.\nThis only affects modules; global script files will not attempt to import modules.\n\nFor example, with this TypeScript:\n\n```ts\nexport function fn(arr: number[]) {\n const arr2 = [1, ...arr];\n}\n```\n\nTurning on [`downlevelIteration`](https://typescriptlang.org/tsconfig/#downlevelIteration) and `importHelpers` is still false:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\n// @downleveliteration\nexport function fn(arr: number[]) {\n const arr2 = [1, ...arr];\n}\n```\n\nThen turning on both [`downlevelIteration`](https://typescriptlang.org/tsconfig/#downlevelIteration) and `importHelpers`:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\n// @downleveliteration\n// @importhelpers\n// @noErrors\nexport function fn(arr: number[]) {\n const arr2 = [1, ...arr];\n}\n```\n\nYou can use [`noEmitHelpers`](https://typescriptlang.org/tsconfig/#noEmitHelpers) when you provide your own implementations of these functions.",
427
471
  "type": [
428
472
  "boolean",
429
473
  "null"
430
- ]
474
+ ],
475
+ "x-intellij-html-description": "\u003cp\u003eFor certain downleveling operations, TypeScript uses some helper code for operations like extending class, spreading arrays or objects, and async operations.\nBy default, these helpers are inserted into files which use them.\nThis can result in code duplication if the same helper is used in many different modules.\u003c/p\u003e\n\u003cp\u003eIf the \u003ccode\u003eimportHelpers\u003c/code\u003e flag is on, these helper functions are instead imported from the \u003ca href=\"https://www.npmjs.com/package/tslib\"\u003etslib\u003c/a\u003e module.\nYou will need to ensure that the \u003ccode\u003etslib\u003c/code\u003e module is able to be imported at runtime.\nThis only affects modules; global script files will not attempt to import modules.\u003c/p\u003e\n\u003cp\u003eFor example, with this TypeScript:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eexport function fn(arr: number[]) {\n const arr2 = [1, ...arr];\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eTurning on \u003ca href=\"https://typescriptlang.org/tsconfig/#downlevelIteration\"\u003e\u003ccode\u003edownlevelIteration\u003c/code\u003e\u003c/a\u003e and \u003ccode\u003eimportHelpers\u003c/code\u003e is still false:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @target: ES5\n// @downleveliteration\nexport function fn(arr: number[]) {\n const arr2 = [1, ...arr];\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThen turning on both \u003ca href=\"https://typescriptlang.org/tsconfig/#downlevelIteration\"\u003e\u003ccode\u003edownlevelIteration\u003c/code\u003e\u003c/a\u003e and \u003ccode\u003eimportHelpers\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @target: ES5\n// @downleveliteration\n// @importhelpers\n// @noErrors\nexport function fn(arr: number[]) {\n const arr2 = [1, ...arr];\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eYou can use \u003ca href=\"https://typescriptlang.org/tsconfig/#noEmitHelpers\"\u003e\u003ccode\u003enoEmitHelpers\u003c/code\u003e\u003c/a\u003e when you provide your own implementations of these functions.\u003c/p\u003e\n"
431
476
  },
432
477
  "importsNotUsedAsValues": {
433
478
  "default": "remove",
434
- "description": "Specify emit/checking behavior for imports that are only used for types.",
479
+ "description": "Deprecated in favor of [`verbatimModuleSyntax`](https://typescriptlang.org/tsconfig/#verbatimModuleSyntax).\n\nThis flag controls how `import` works, there are 3 different options:\n\n- `remove`: The default behavior of dropping `import` statements which only reference types.\n\n- `preserve`: Preserves all `import` statements whose values or types are never used. This can cause imports/side-effects to be preserved.\n\n- `error`: This preserves all imports (the same as the preserve option), but will error when a value import is only used as a type. This might be useful if you want to ensure no values are being accidentally imported, but still make side-effect imports explicit.\n\nThis flag works because you can use `import type` to explicitly create an `import` statement which should never be emitted into JavaScript.",
435
480
  "enum": [
436
481
  "remove",
437
482
  "preserve",
438
483
  "error"
439
- ],
440
- "markdownDescription": "Specify emit/checking behavior for imports that are only used for types.\n\nSee more: https://www.typescriptlang.org/tsconfig#importsNotUsedAsValues"
484
+ ]
441
485
  },
442
486
  "incremental": {
443
487
  "description": "Enable incremental compilation. Requires TypeScript version 3.4 or later.",
@@ -448,89 +492,107 @@
448
492
  },
449
493
  "inlineSourceMap": {
450
494
  "default": false,
451
- "description": "Include sourcemap files inside the emitted JavaScript.",
452
- "markdownDescription": "Include sourcemap files inside the emitted JavaScript.\n\nSee more: https://www.typescriptlang.org/tsconfig#inlineSourceMap",
495
+ "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```",
496
+ "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```",
453
497
  "type": [
454
498
  "boolean",
455
499
  "null"
456
- ]
500
+ ],
501
+ "x-intellij-html-description": "\u003cp\u003eWhen set, instead of writing out a \u003ccode\u003e.js.map\u003c/code\u003e file to provide source maps, TypeScript will embed the source map content in the \u003ccode\u003e.js\u003c/code\u003e 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\u0026#39;t allow \u003ccode\u003e.map\u003c/code\u003e files to be served.\u003c/p\u003e\n\u003cp\u003eMutually exclusive with \u003ca href=\"https://typescriptlang.org/tsconfig/#sourceMap\"\u003e\u003ccode\u003esourceMap\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eFor example, with this TypeScript:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003econst helloWorld = \u0026quot;hi\u0026quot;;\nconsole.log(helloWorld);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eConverts to this JavaScript:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\nconst helloWorld = \u0026quot;hi\u0026quot;;\nconsole.log(helloWorld);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThen enable building it with \u003ccode\u003einlineSourceMap\u003c/code\u003e enabled there is a comment at the bottom of the file which includes\na source-map for the file.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @inlineSourceMap\n// @showEmit\nconst helloWorld = \u0026quot;hi\u0026quot;;\nconsole.log(helloWorld);\n\u003c/code\u003e\u003c/pre\u003e\n"
457
502
  },
458
503
  "inlineSources": {
459
504
  "default": false,
460
- "description": "Include source code in the sourcemaps inside the emitted JavaScript.",
461
- "markdownDescription": "Include source code in the sourcemaps inside the emitted JavaScript.\n\nSee more: https://www.typescriptlang.org/tsconfig#inlineSources",
505
+ "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```",
506
+ "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```",
462
507
  "type": [
463
508
  "boolean",
464
509
  "null"
465
- ]
510
+ ],
511
+ "x-intellij-html-description": "\u003cp\u003eWhen set, TypeScript will include the original content of the \u003ccode\u003e.ts\u003c/code\u003e file as an embedded string in the source map (using the source map\u0026#39;s \u003ccode\u003esourcesContent\u003c/code\u003e property).\nThis is often useful in the same cases as \u003ca href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"\u003e\u003ccode\u003einlineSourceMap\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eRequires either \u003ca href=\"https://typescriptlang.org/tsconfig/#sourceMap\"\u003e\u003ccode\u003esourceMap\u003c/code\u003e\u003c/a\u003e or \u003ca href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"\u003e\u003ccode\u003einlineSourceMap\u003c/code\u003e\u003c/a\u003e to be set.\u003c/p\u003e\n\u003cp\u003eFor example, with this TypeScript:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003econst helloWorld = \u0026quot;hi\u0026quot;;\nconsole.log(helloWorld);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eBy default converts to this JavaScript:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\nconst helloWorld = \u0026quot;hi\u0026quot;;\nconsole.log(helloWorld);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThen enable building it with \u003ccode\u003einlineSources\u003c/code\u003e and \u003ca href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"\u003e\u003ccode\u003einlineSourceMap\u003c/code\u003e\u003c/a\u003e 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 \u003ca href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"\u003e\u003ccode\u003einlineSourceMap\u003c/code\u003e\u003c/a\u003e because the source-map now contains the original source code also.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @inlineSources\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = \u0026quot;hi\u0026quot;;\nconsole.log(helloWorld);\n\u003c/code\u003e\u003c/pre\u003e\n"
466
512
  },
467
513
  "isolatedDeclarations": {
468
514
  "default": false,
469
- "description": "Require sufficient annotation on exports so other tools can trivially generate declaration files.",
470
- "markdownDescription": "Require sufficient annotation on exports so other tools can trivially generate declaration files.\n\nSee more: https://www.typescriptlang.org/tsconfig#isolatedDeclarations",
515
+ "description": "Require sufficient annotation on exports so other tools can trivially generate declaration files.\n \nFor more information, see the [5.5 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-5-5.html#isolated-declarations)",
516
+ "markdownDescription": "Require sufficient annotation on exports so other tools can trivially generate declaration files.\n \nFor more information, see the [5.5 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-5-5.html#isolated-declarations)",
471
517
  "type": [
472
518
  "boolean",
473
519
  "null"
474
- ]
520
+ ],
521
+ "x-intellij-html-description": "\u003cp\u003eRequire sufficient annotation on exports so other tools can trivially generate declaration files.\u003c/p\u003e\n\u003cp\u003eFor more information, see the \u003ca href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-5-5.html#isolated-declarations\"\u003e5.5 release notes\u003c/a\u003e\u003c/p\u003e\n"
475
522
  },
476
523
  "isolatedModules": {
477
524
  "default": false,
478
- "description": "Ensure that each file can be safely transpiled without relying on other imports.",
479
- "markdownDescription": "Ensure that each file can be safely transpiled without relying on other imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#isolatedModules",
525
+ "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.",
526
+ "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.",
480
527
  "type": [
481
528
  "boolean",
482
529
  "null"
483
- ]
530
+ ],
531
+ "x-intellij-html-description": "\u003cp\u003eWhile you can use TypeScript to produce JavaScript code from TypeScript code, it\u0026#39;s also common to use other transpilers such as \u003ca href=\"https://babeljs.io/\"\u003eBabel\u003c/a\u003e to do this.\nHowever, other transpilers only operate on a single file at a time, which means they can\u0026#39;t apply code transforms that depend on understanding the full type system.\nThis restriction also applies to TypeScript\u0026#39;s \u003ccode\u003ets.transpileModule\u003c/code\u003e API which is used by some build tools.\u003c/p\u003e\n\u003cp\u003eThese limitations can cause runtime problems with some TypeScript features like \u003ccode\u003econst enum\u003c/code\u003es and \u003ccode\u003enamespace\u003c/code\u003es.\nSetting the \u003ccode\u003eisolatedModules\u003c/code\u003e flag tells TypeScript to warn you if you write certain code that can\u0026#39;t be correctly interpreted by a single-file transpilation process.\u003c/p\u003e\n\u003cp\u003eIt does not change the behavior of your code, or otherwise change the behavior of TypeScript\u0026#39;s checking and emitting process.\u003c/p\u003e\n\u003cp\u003eSome examples of code which does not work when \u003ccode\u003eisolatedModules\u003c/code\u003e is enabled.\u003c/p\u003e\n\u003ch4\u003eExports of Non-Value Identifiers\u003c/h4\u003e\n\u003cp\u003eIn TypeScript, you can import a \u003cem\u003etype\u003c/em\u003e and then subsequently export it:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @noErrors\nimport { someType, someFunction } from \u0026quot;someModule\u0026quot;;\n\nsomeFunction();\n\nexport { someType, someFunction };\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eBecause there\u0026#39;s no value for \u003ccode\u003esomeType\u003c/code\u003e, the emitted \u003ccode\u003eexport\u003c/code\u003e will not try to export it (this would be a runtime error in JavaScript):\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-js\"\u003eexport { someFunction };\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eSingle-file transpilers don\u0026#39;t know whether \u003ccode\u003esomeType\u003c/code\u003e produces a value or not, so it\u0026#39;s an error to export a name that only refers to a type.\u003c/p\u003e\n\u003ch4\u003eNon-Module Files\u003c/h4\u003e\n\u003cp\u003eIf \u003ccode\u003eisolatedModules\u003c/code\u003e is set, namespaces are only allowed in \u003cem\u003emodules\u003c/em\u003e (which means it has some form of \u003ccode\u003eimport\u003c/code\u003e/\u003ccode\u003eexport\u003c/code\u003e). An error occurs if a namespace is found in a non-module file:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 1277\n// @isolatedModules\nnamespace Instantiated {\n export const x = 1;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis restriction doesn\u0026#39;t apply to \u003ccode\u003e.d.ts\u003c/code\u003e files.\u003c/p\u003e\n\u003ch4\u003eReferences to \u003ccode\u003econst enum\u003c/code\u003e members\u003c/h4\u003e\n\u003cp\u003eIn TypeScript, when you reference a \u003ccode\u003econst enum\u003c/code\u003e member, the reference is replaced by its actual value in the emitted JavaScript. Changing this TypeScript:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003edeclare const enum Numbers {\n Zero = 0,\n One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eTo this JavaScript:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @removeComments\ndeclare const enum Numbers {\n Zero = 0,\n One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWithout knowledge of the values of these members, other transpilers can\u0026#39;t replace the references to \u003ccode\u003eNumbers\u003c/code\u003e, which would be a runtime error if left alone (since there are no \u003ccode\u003eNumbers\u003c/code\u003e object at runtime).\nBecause of this, when \u003ccode\u003eisolatedModules\u003c/code\u003e is set, it is an error to reference an ambient \u003ccode\u003econst enum\u003c/code\u003e member.\u003c/p\u003e\n"
484
532
  },
485
533
  "jsx": {
486
- "description": "Specify what JSX code is generated.",
534
+ "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 = () =\u003e \u003ch1\u003eHello world\u003c/h1\u003e;\n```\n\nReact: `\"react-jsx\"`\u003csup\u003e[[1]](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html)\u003c/sup\u003e\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 = () =\u003e \u003ch1\u003eHello world\u003c/h1\u003e;\n```\n\nReact dev transform: `\"react-jsxdev\"`\u003csup\u003e[[1]](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html)\u003c/sup\u003e\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 = () =\u003e \u003ch1\u003eHello world\u003c/h1\u003e;\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 = () =\u003e \u003ch1\u003eHello world\u003c/h1\u003e;\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 = () =\u003e \u003ch1\u003eHello world\u003c/h1\u003e;\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 = () =\u003e \u003ch1\u003eHello world\u003c/h1\u003e;\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 = () =\u003e \u003ch1\u003eHello world\u003c/h1\u003e;\n```\n\nAlways use the automatic runtime (`\"react-jsx\"`) for this file:\n\n```tsx\n/* @jsxRuntime automatic */\nexport const HelloWorld = () =\u003e \u003ch1\u003eHello world\u003c/h1\u003e;\n```",
487
535
  "enum": [
488
536
  "preserve",
489
537
  "react",
490
538
  "react-jsx",
491
539
  "react-jsxdev",
492
540
  "react-native"
493
- ],
494
- "markdownDescription": "Specify what JSX code is generated.\n\nSee more: https://www.typescriptlang.org/tsconfig#jsx"
541
+ ]
495
542
  },
496
543
  "jsxFactory": {
497
544
  "default": "React.createElement",
498
- "description": "Specify the JSX factory function used when targeting React JSX emit, e.g. `React.createElement` or `h`.",
499
- "markdownDescription": "Specify the JSX factory function used when targeting React JSX emit, e.g. `React.createElement` or `h`.\n\nSee more: https://www.typescriptlang.org/tsconfig#jsxFactory",
545
+ "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 = () =\u003e \u003cdiv\u003eHello\u003c/div\u003e;\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 = () =\u003e \u003cdiv\u003eHello\u003c/div\u003e;\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 = () =\u003e \u003cdiv\u003eHello\u003c/div\u003e;\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`.",
546
+ "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 = () =\u003e \u003cdiv\u003eHello\u003c/div\u003e;\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 = () =\u003e \u003cdiv\u003eHello\u003c/div\u003e;\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 = () =\u003e \u003cdiv\u003eHello\u003c/div\u003e;\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`.",
500
547
  "type": [
501
548
  "string",
502
549
  "null"
503
- ]
550
+ ],
551
+ "x-intellij-html-description": "\u003cp\u003eChanges the function called in \u003ccode\u003e.js\u003c/code\u003e files when compiling JSX Elements using the classic JSX runtime.\nThe most common change is to use \u003ccode\u003e\u0026quot;h\u0026quot;\u003c/code\u003e or \u003ccode\u003e\u0026quot;preact.h\u0026quot;\u003c/code\u003e instead of the default \u003ccode\u003e\u0026quot;React.createElement\u0026quot;\u003c/code\u003e if using \u003ccode\u003epreact\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eFor example, this TSX file:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-tsx\"\u003eimport { h } from \u0026quot;preact\u0026quot;;\n\nconst HelloWorld = () =\u0026gt; \u0026lt;div\u0026gt;Hello\u0026lt;/div\u0026gt;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith \u003ccode\u003ejsxFactory: \u0026quot;h\u0026quot;\u003c/code\u003e looks like:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-tsx\"\u003e// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from \u0026quot;preact\u0026quot;;\n\nconst HelloWorld = () =\u0026gt; \u0026lt;div\u0026gt;Hello\u0026lt;/div\u0026gt;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis option can be used on a per-file basis too similar to \u003ca href=\"https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#custom\"\u003eBabel\u0026#39;s \u003ccode\u003e/** @jsx h */\u003c/code\u003e directive\u003c/a\u003e.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-tsx\"\u003e/** @jsx h */\nimport { h } from \u0026quot;preact\u0026quot;;\n\nconst HelloWorld = () =\u0026gt; \u0026lt;div\u0026gt;Hello\u0026lt;/div\u0026gt;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe factory chosen will also affect where the \u003ccode\u003eJSX\u003c/code\u003e namespace is looked up (for type checking information) before falling back to the global one.\u003c/p\u003e\n\u003cp\u003eIf the factory is defined as \u003ccode\u003eReact.createElement\u003c/code\u003e (the default), the compiler will check for \u003ccode\u003eReact.JSX\u003c/code\u003e before checking for a global \u003ccode\u003eJSX\u003c/code\u003e. If the factory is defined as \u003ccode\u003eh\u003c/code\u003e, it will check for \u003ccode\u003eh.JSX\u003c/code\u003e before a global \u003ccode\u003eJSX\u003c/code\u003e.\u003c/p\u003e\n"
504
552
  },
505
553
  "jsxFragmentFactory": {
506
554
  "default": "React.Fragment",
507
- "description": "Specify the JSX Fragment reference used for fragments when targeting React JSX emit e.g. `React.Fragment` or `Fragment`.",
508
- "markdownDescription": "Specify the JSX Fragment reference used for fragments when targeting React JSX emit e.g. `React.Fragment` or `Fragment`.\n\nSee more: https://www.typescriptlang.org/tsconfig#jsxFragmentFactory",
555
+ "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 = () =\u003e (\n \u003c\u003e\n \u003cdiv\u003eHello\u003c/div\u003e\n \u003c/\u003e\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 = () =\u003e (\n \u003c\u003e\n \u003cdiv\u003eHello\u003c/div\u003e\n \u003c/\u003e\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 = () =\u003e (\n \u003c\u003e\n \u003cdiv\u003eHello\u003c/div\u003e\n \u003c/\u003e\n);\n```",
556
+ "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 = () =\u003e (\n \u003c\u003e\n \u003cdiv\u003eHello\u003c/div\u003e\n \u003c/\u003e\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 = () =\u003e (\n \u003c\u003e\n \u003cdiv\u003eHello\u003c/div\u003e\n \u003c/\u003e\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 = () =\u003e (\n \u003c\u003e\n \u003cdiv\u003eHello\u003c/div\u003e\n \u003c/\u003e\n);\n```",
509
557
  "type": [
510
558
  "string",
511
559
  "null"
512
- ]
560
+ ],
561
+ "x-intellij-html-description": "\u003cp\u003eSpecify the JSX fragment factory function to use when targeting react JSX emit with \u003ca href=\"https://typescriptlang.org/tsconfig/#jsxFactory\"\u003e\u003ccode\u003ejsxFactory\u003c/code\u003e\u003c/a\u003e compiler option is specified, e.g. \u003ccode\u003eFragment\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eFor example with this TSConfig:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;target\u0026quot;: \u0026quot;esnext\u0026quot;,\n \u0026quot;module\u0026quot;: \u0026quot;commonjs\u0026quot;,\n \u0026quot;jsx\u0026quot;: \u0026quot;react\u0026quot;,\n \u0026quot;jsxFactory\u0026quot;: \u0026quot;h\u0026quot;,\n \u0026quot;jsxFragmentFactory\u0026quot;: \u0026quot;Fragment\u0026quot;\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis TSX file:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-tsx\"\u003eimport { h, Fragment } from \u0026quot;preact\u0026quot;;\n\nconst HelloWorld = () =\u0026gt; (\n \u0026lt;\u0026gt;\n \u0026lt;div\u0026gt;Hello\u0026lt;/div\u0026gt;\n \u0026lt;/\u0026gt;\n);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWould look like:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-tsx\"\u003e// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @jsxFragmentFactory: Fragment\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from \u0026quot;preact\u0026quot;;\n\nconst HelloWorld = () =\u0026gt; (\n \u0026lt;\u0026gt;\n \u0026lt;div\u0026gt;Hello\u0026lt;/div\u0026gt;\n \u0026lt;/\u0026gt;\n);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis option can be used on a per-file basis too similar to \u003ca href=\"https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#fragments\"\u003eBabel\u0026#39;s \u003ccode\u003e/* @jsxFrag h */\u003c/code\u003e directive\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eFor example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-tsx\"\u003e/** @jsx h */\n/** @jsxFrag Fragment */\n\nimport { h, Fragment } from \u0026quot;preact\u0026quot;;\n\nconst HelloWorld = () =\u0026gt; (\n \u0026lt;\u0026gt;\n \u0026lt;div\u0026gt;Hello\u0026lt;/div\u0026gt;\n \u0026lt;/\u0026gt;\n);\n\u003c/code\u003e\u003c/pre\u003e\n"
513
562
  },
514
563
  "jsxImportSource": {
564
+ "anyOf": [
565
+ {
566
+ "enum": [
567
+ "react",
568
+ "preact",
569
+ "vue"
570
+ ]
571
+ },
572
+ {
573
+ "type": "string"
574
+ },
575
+ {
576
+ "type": "null"
577
+ }
578
+ ],
515
579
  "default": "react",
516
- "description": "Specify module specifier used to import the JSX factory functions when using `jsx: react-jsx*`.",
517
- "markdownDescription": "Specify module specifier used to import the JSX factory functions when using `jsx: react-jsx*`.\n\nSee more: https://www.typescriptlang.org/tsconfig#jsxImportSource",
518
- "type": [
519
- "string",
520
- "null"
521
- ]
580
+ "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\nWhen using [@vitejs/plugin-vue-jsx](https://www.npmjs.com/package/@vitejs/plugin-vue-jsx), you can set this to `\"vue\"` for Vue JSX support.\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 \u003ch1\u003eHello World\u003c/h1\u003e;\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 \u003ch1\u003eHello World\u003c/h1\u003e;\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 \u003ch1\u003eHello World\u003c/h1\u003e;\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 \u003ch1\u003eHello World\u003c/h1\u003e;\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.",
581
+ "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\nWhen using [@vitejs/plugin-vue-jsx](https://www.npmjs.com/package/@vitejs/plugin-vue-jsx), you can set this to `\"vue\"` for Vue JSX support.\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 \u003ch1\u003eHello World\u003c/h1\u003e;\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 \u003ch1\u003eHello World\u003c/h1\u003e;\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 \u003ch1\u003eHello World\u003c/h1\u003e;\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 \u003ch1\u003eHello World\u003c/h1\u003e;\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.",
582
+ "x-intellij-html-description": "\u003cp\u003eDeclares the module specifier to be used for importing the \u003ccode\u003ejsx\u003c/code\u003e and \u003ccode\u003ejsxs\u003c/code\u003e factory functions when using \u003ca href=\"https://typescriptlang.org/tsconfig/#jsx\"\u003e\u003ccode\u003ejsx\u003c/code\u003e\u003c/a\u003e as \u003ccode\u003e\u0026quot;react-jsx\u0026quot;\u003c/code\u003e or \u003ccode\u003e\u0026quot;react-jsxdev\u0026quot;\u003c/code\u003e which were introduced in TypeScript 4.1.\u003c/p\u003e\n\u003cp\u003eWhen using \u003ca href=\"https://www.npmjs.com/package/@vitejs/plugin-vue-jsx\"\u003e@vitejs/plugin-vue-jsx\u003c/a\u003e, you can set this to \u003ccode\u003e\u0026quot;vue\u0026quot;\u003c/code\u003e for Vue JSX support.\u003c/p\u003e\n\u003cp\u003eWith \u003ca href=\"https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html\"\u003eReact 17\u003c/a\u003e the library supports a new form of JSX transformation via a separate import.\u003c/p\u003e\n\u003cp\u003eFor example with this code:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-tsx\"\u003eimport React from \u0026quot;react\u0026quot;;\n\nfunction App() {\n return \u0026lt;h1\u0026gt;Hello World\u0026lt;/h1\u0026gt;;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eUsing this TSConfig:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;target\u0026quot;: \u0026quot;esnext\u0026quot;,\n \u0026quot;module\u0026quot;: \u0026quot;commonjs\u0026quot;,\n \u0026quot;jsx\u0026quot;: \u0026quot;react-jsx\u0026quot;\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe emitted JavaScript from TypeScript is:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-tsx\"\u003e// @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 \u0026quot;react\u0026quot;;\n\nfunction App() {\n return \u0026lt;h1\u0026gt;Hello World\u0026lt;/h1\u0026gt;;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eFor example if you wanted to use \u003ccode\u003e\u0026quot;jsxImportSource\u0026quot;: \u0026quot;preact\u0026quot;\u003c/code\u003e, you need a tsconfig like:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;target\u0026quot;: \u0026quot;esnext\u0026quot;,\n \u0026quot;module\u0026quot;: \u0026quot;commonjs\u0026quot;,\n \u0026quot;jsx\u0026quot;: \u0026quot;react-jsx\u0026quot;,\n \u0026quot;jsxImportSource\u0026quot;: \u0026quot;preact\u0026quot;,\n \u0026quot;types\u0026quot;: [\u0026quot;preact\u0026quot;]\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhich generates code like:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-tsx\"\u003e// @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 \u0026lt;h1\u0026gt;Hello World\u0026lt;/h1\u0026gt;;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eAlternatively, you can use a per-file pragma to set this option, for example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-tsx\"\u003e/** @jsxImportSource preact */\n\nexport function App() {\n return \u0026lt;h1\u0026gt;Hello World\u0026lt;/h1\u0026gt;;\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWould add \u003ccode\u003epreact/jsx-runtime\u003c/code\u003e as an import for the \u003ccode\u003e_jsx\u003c/code\u003e factory.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eNote:\u003c/em\u003e In order for this to work like you would expect, your \u003ccode\u003etsx\u003c/code\u003e file must include an \u003ccode\u003eexport\u003c/code\u003e or \u003ccode\u003eimport\u003c/code\u003e so that it is considered a module.\u003c/p\u003e\n"
522
583
  },
523
584
  "keyofStringsOnly": {
524
585
  "default": false,
525
- "description": "Make keyof only return strings instead of string, numbers or symbols. Legacy option.",
526
- "markdownDescription": "Make keyof only return strings instead of string, numbers or symbols. Legacy option.\n\nSee more: https://www.typescriptlang.org/tsconfig#keyofStringsOnly",
586
+ "description": "This flag changes the `keyof` type operator to return `string` instead of `string | number` when applied to a type with a string index signature.\n\nThis flag is used to help people keep this behavior from [before TypeScript 2.9's release](https://typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html#support-number-and-symbol-named-properties-with-keyof-and-mapped-types).",
587
+ "markdownDescription": "This flag changes the `keyof` type operator to return `string` instead of `string | number` when applied to a type with a string index signature.\n\nThis flag is used to help people keep this behavior from [before TypeScript 2.9's release](https://typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html#support-number-and-symbol-named-properties-with-keyof-and-mapped-types).",
527
588
  "type": [
528
589
  "boolean",
529
590
  "null"
530
- ]
591
+ ],
592
+ "x-intellij-html-description": "\u003cp\u003eThis flag changes the \u003ccode\u003ekeyof\u003c/code\u003e type operator to return \u003ccode\u003estring\u003c/code\u003e instead of \u003ccode\u003estring | number\u003c/code\u003e when applied to a type with a string index signature.\u003c/p\u003e\n\u003cp\u003eThis flag is used to help people keep this behavior from \u003ca href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html#support-number-and-symbol-named-properties-with-keyof-and-mapped-types\"\u003ebefore TypeScript 2.9\u0026#39;s release\u003c/a\u003e.\u003c/p\u003e\n"
531
593
  },
532
594
  "lib": {
533
- "description": "Specify a set of bundled library declaration files that describe the target runtime environment.",
595
+ "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).",
534
596
  "items": {
535
597
  "anyOf": [
536
598
  {
@@ -549,6 +611,7 @@
549
611
  "ES2015.Symbol",
550
612
  "ES2016",
551
613
  "ES2016.Array.Include",
614
+ "ES2016.Intl",
552
615
  "ES2017",
553
616
  "ES2017.Intl",
554
617
  "ES2017.Object",
@@ -609,9 +672,9 @@
609
672
  "ES2022.Error",
610
673
  "ES2022.Intl",
611
674
  "ES2022.Object",
675
+ "ES2022.Regexp",
612
676
  "ES2022.String",
613
677
  "ES2022.SharedMemory",
614
- "ES2022.RegExp",
615
678
  "ES2023",
616
679
  "ES2023.Array",
617
680
  "ES2024",
@@ -622,24 +685,36 @@
622
685
  "ES2024.Regexp",
623
686
  "ES2024.SharedMemory",
624
687
  "ES2024.String",
688
+ "ES2025",
689
+ "ES2025.Collection",
690
+ "ES2025.Float16",
691
+ "ES2025.Intl",
692
+ "ES2025.Iterator",
693
+ "ES2025.Promise",
694
+ "ES2025.Regexp",
625
695
  "Decorators",
626
696
  "Decorators.Legacy",
627
697
  "ES2017.Date",
628
698
  "ES2023.Collection",
699
+ "ES2023.Intl",
629
700
  "ESNext.Decorators",
630
701
  "ESNext.Disposable",
631
702
  "ESNext.Error",
632
- "ESNext.Sharedmemory"
703
+ "ESNext.Float16",
704
+ "ESNext.SharedMemory",
705
+ "ESNext.Date",
706
+ "ESNext.Temporal",
707
+ "ESNext.TypedArrays"
633
708
  ]
634
709
  },
635
710
  {
636
- "pattern": "^[Ee][Ss]5|[Ee][Ss]6|[Ee][Ss]7$"
711
+ "pattern": "^[Ee][Ss][567]$"
637
712
  },
638
713
  {
639
714
  "pattern": "^[Ee][Ss]2015(\\.([Cc][Oo][Ll][Ll][Ee][Cc][Tt][Ii][Oo][Nn]|[Cc][Oo][Rr][Ee]|[Gg][Ee][Nn][Ee][Rr][Aa][Tt][Oo][Rr]|[Ii][Tt][Ee][Rr][Aa][Bb][Ll][Ee]|[Pp][Rr][Oo][Mm][Ii][Ss][Ee]|[Pp][Rr][Oo][Xx][Yy]|[Rr][Ee][Ff][Ll][Ee][Cc][Tt]|[Ss][Yy][Mm][Bb][Oo][Ll]\\.[Ww][Ee][Ll][Ll][Kk][Nn][Oo][Ww][Nn]|[Ss][Yy][Mm][Bb][Oo][Ll]))?$"
640
715
  },
641
716
  {
642
- "pattern": "^[Ee][Ss]2016(\\.[Aa][Rr][Rr][Aa][Yy]\\.[Ii][Nn][Cc][Ll][Uu][Dd][Ee])?$"
717
+ "pattern": "^[Ee][Ss]2016(\\.([Ii][Nn][Tt][Ll]|[Aa][Rr][Rr][Aa][Yy]\\.[Ii][Nn][Cc][Ll][Uu][Dd][Ee]))?$"
643
718
  },
644
719
  {
645
720
  "pattern": "^[Ee][Ss]2017(\\.([Ii][Nn][Tt][Ll]|[Oo][Bb][Jj][Ee][Cc][Tt]|[Ss][Hh][Aa][Rr][Ee][Dd][Mm][Ee][Mm][Oo][Rr][Yy]|[Ss][Tt][Rr][Ii][Nn][Gg]|[Tt][Yy][Pp][Ee][Dd][Aa][Rr][Rr][Aa][Yy][Ss]|[Dd][Aa][Tt][Ee]|[Aa][Rr][Rr][Aa][Yy][Bb][Uu][Ff][Ff][Ee][Rr]))?$"
@@ -660,13 +735,16 @@
660
735
  "pattern": "^[Ee][Ss]2022(\\.([Aa][Rr][Rr][Aa][Yy]|[Ee][Rr][Rr][Oo][Rr]|[Ii][Nn][Tt][Ll]|[Oo][Bb][Jj][Ee][Cc][Tt]|[Ss][Tt][Rr][Ii][Nn][Gg]|[Ss][Hh][Aa][Rr][Ee][Dd][Mm][Ee][Mm][Oo][Rr][Yy]|[Rr][Ee][Gg][Ee][Xx][Pp]))?$"
661
736
  },
662
737
  {
663
- "pattern": "^[Ee][Ss]2023(\\.([Aa][Rr][Rr][Aa][Yy]|[Cc][Oo][Ll][Ll][Ee][Cc][Tt][Ii][Oo][Nn]))?$"
738
+ "pattern": "^[Ee][Ss]2023(\\.([Ii][Nn][Tt][Ll]|[Aa][Rr][Rr][Aa][Yy]|[Cc][Oo][Ll][Ll][Ee][Cc][Tt][Ii][Oo][Nn]))?$"
664
739
  },
665
740
  {
666
741
  "pattern": "^[Ee][Ss]2024(\\.([Aa][Rr][Rr][Aa][Yy][Bb][Uu][Ff][Ff][Ee][Rr]|[Cc][Oo][Ll][Ll][Ee][Cc][Tt][Ii][Oo][Nn]|[Oo][Bb][Jj][Ee][Cc][Tt]|[Pp][Rr][Oo][Mm][Ii][Ss][Ee]|[Rr][Ee][Gg][Ee][Xx][Pp]|[Ss][Hh][Aa][Rr][Ee][Dd][Mm][Ee][Mm][Oo][Rr][Yy]|[Ss][Tt][Rr][Ii][Nn][Gg]))?$"
667
742
  },
668
743
  {
669
- "pattern": "^[Ee][Ss][Nn][Ee][Xx][Tt](\\.([Aa][Rr][Rr][Aa][Yy]|[Aa][Ss][Yy][Nn][Cc][Ii][Tt][Ee][Rr][Aa][Bb][Ll][Ee]|[Bb][Ii][Gg][Ii][Nn][Tt]|[Ii][Nn][Tt][Ll]|[Pp][Rr][Oo][Mm][Ii][Ss][Ee]|[Ss][Tt][Rr][Ii][Nn][Gg]|[Ss][Yy][Mm][Bb][Oo][Ll]|[Ww][Ee][Aa][Kk][Rr][Ee][Ff]|[Dd][Ee][Cc][Oo][Rr][Aa][Tt][Oo][Rr][Ss]|[Dd][Ii][Ss][Pp][Oo][Ss][Aa][Bb][Ll][Ee]))?$"
744
+ "pattern": "^[Ee][Ss]2025(\\.([Cc][Oo][Ll][Ll][Ee][Cc][Tt][Ii][Oo][Nn]|[Ff][Ll][Oo][Aa][Tt]16|[Ii][Nn][Tt][Ll]|[Ii][Tt][Ee][Rr][Aa][Tt][Oo][Rr]|[Pp][Rr][Oo][Mm][Ii][Ss][Ee]|[Rr][Ee][Gg][Ee][Xx][Pp]))?$"
745
+ },
746
+ {
747
+ "pattern": "^[Ee][Ss][Nn][Ee][Xx][Tt](\\.([Aa][Rr][Rr][Aa][Yy]|[Aa][Ss][Yy][Nn][Cc][Ii][Tt][Ee][Rr][Aa][Bb][Ll][Ee]|[Bb][Ii][Gg][Ii][Nn][Tt]|[Cc][Oo][Ll][Ll][Ee][Cc][Tt][Ii][Oo][Nn]|[Dd][Aa][Tt][Ee]|[Dd][Ee][Cc][Oo][Rr][Aa][Tt][Oo][Rr][Ss]|[Dd][Ii][Ss][Pp][Oo][Ss][Aa][Bb][Ll][Ee]|[Ee][Rr][Rr][Oo][Rr]|[Ff][Ll][Oo][Aa][Tt]16|[Ii][Nn][Tt][Ll]|[Ii][Tt][Ee][Rr][Aa][Tt][Oo][Rr]|[Oo][Bb][Jj][Ee][Cc][Tt]|[Pp][Rr][Oo][Mm][Ii][Ss][Ee]|[Rr][Ee][Gg][Ee][Xx][Pp]|[Ss][Hh][Aa][Rr][Ee][Dd][Mm][Ee][Mm][Oo][Rr][Yy]|[Ss][Tt][Rr][Ii][Nn][Gg]|[Ss][Yy][Mm][Bb][Oo][Ll]|[Tt][Ee][Mm][Pp][Oo][Rr][Aa][Ll]|[Tt][Yy][Pp][Ee][Dd][Aa][Rr][Rr][Aa][Yy][Ss]|[Ww][Ee][Aa][Kk][Rr][Ee][Ff]))?$"
670
748
  },
671
749
  {
672
750
  "pattern": "^[Dd][Oo][Mm](\\.([Aa][Ss][Yy][Nn][Cc])?[Ii][Tt][Ee][Rr][Aa][Bb][Ll][Ee])?$"
@@ -683,39 +761,43 @@
683
761
  ],
684
762
  "type": "string"
685
763
  },
686
- "markdownDescription": "Specify a set of bundled library declaration files that describe the target runtime environment.\n\nSee more: https://www.typescriptlang.org/tsconfig#lib",
764
+ "markdownDescription": "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).",
687
765
  "type": [
688
766
  "array",
689
767
  "null"
690
768
  ],
691
- "uniqueItems": true
769
+ "uniqueItems": true,
770
+ "x-intellij-html-description": "\u003cp\u003eTypeScript includes a default set of type definitions for built-in JS APIs (like \u003ccode\u003eMath\u003c/code\u003e), as well as type definitions for things found in browser environments (like \u003ccode\u003edocument\u003c/code\u003e).\nTypeScript also includes APIs for newer JS features matching the \u003ca href=\"https://typescriptlang.org/tsconfig/#target\"\u003e\u003ccode\u003etarget\u003c/code\u003e\u003c/a\u003e you specify; for example the definition for \u003ccode\u003eMap\u003c/code\u003e is available if \u003ca href=\"https://typescriptlang.org/tsconfig/#target\"\u003e\u003ccode\u003etarget\u003c/code\u003e\u003c/a\u003e is \u003ccode\u003eES6\u003c/code\u003e or newer.\u003c/p\u003e\n\u003cp\u003eYou may want to change these for a few reasons:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eYour program doesn\u0026#39;t run in a browser, so you don\u0026#39;t want the \u003ccode\u003e\u0026quot;dom\u0026quot;\u003c/code\u003e type definitions\u003c/li\u003e\n\u003cli\u003eYour runtime platform provides certain JavaScript API objects (maybe through polyfills), but doesn\u0026#39;t yet support the full syntax of a given ECMAScript version\u003c/li\u003e\n\u003cli\u003eYou have polyfills or native implementations for some, but not all, of a higher level ECMAScript version\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIn TypeScript 4.5, lib files can be overridden by npm modules, find out more \u003ca href=\"https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#supporting-lib-from-node_modules\"\u003ein the blog\u003c/a\u003e.\u003c/p\u003e\n\u003ch3\u003eHigh Level libraries\u003c/h3\u003e\n\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eName\u003c/th\u003e\n\u003cth\u003eContents\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES5\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eCore definitions for all ES5 functionality\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2015\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAdditional APIs available in ES2015 (also known as ES6) - \u003ccode\u003earray.find\u003c/code\u003e, \u003ccode\u003ePromise\u003c/code\u003e, \u003ccode\u003eProxy\u003c/code\u003e, \u003ccode\u003eSymbol\u003c/code\u003e, \u003ccode\u003eMap\u003c/code\u003e, \u003ccode\u003eSet\u003c/code\u003e, \u003ccode\u003eReflect\u003c/code\u003e, etc.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES6\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAlias for \u0026quot;ES2015\u0026quot;\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2016\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAdditional APIs available in ES2016 - \u003ccode\u003earray.include\u003c/code\u003e, etc.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES7\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAlias for \u0026quot;ES2016\u0026quot;\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2017\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAdditional APIs available in ES2017 - \u003ccode\u003eObject.entries\u003c/code\u003e, \u003ccode\u003eObject.values\u003c/code\u003e, \u003ccode\u003eAtomics\u003c/code\u003e, \u003ccode\u003eSharedArrayBuffer\u003c/code\u003e, \u003ccode\u003edate.formatToParts\u003c/code\u003e, typed arrays, etc.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2018\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAdditional APIs available in ES2018 - \u003ccode\u003easync\u003c/code\u003e iterables, \u003ccode\u003epromise.finally\u003c/code\u003e, \u003ccode\u003eIntl.PluralRules\u003c/code\u003e, \u003ccode\u003eregexp.groups\u003c/code\u003e, etc.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2019\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAdditional APIs available in ES2019 - \u003ccode\u003earray.flat\u003c/code\u003e, \u003ccode\u003earray.flatMap\u003c/code\u003e, \u003ccode\u003eObject.fromEntries\u003c/code\u003e, \u003ccode\u003estring.trimStart\u003c/code\u003e, \u003ccode\u003estring.trimEnd\u003c/code\u003e, etc.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2020\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAdditional APIs available in ES2020 - \u003ccode\u003estring.matchAll\u003c/code\u003e, etc.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2021\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAdditional APIs available in ES2021 - \u003ccode\u003epromise.any\u003c/code\u003e, \u003ccode\u003estring.replaceAll\u003c/code\u003e etc.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2022\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAdditional APIs available in ES2022 - \u003ccode\u003earray.at\u003c/code\u003e, \u003ccode\u003eRegExp.hasIndices\u003c/code\u003e, etc.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2023\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAdditional APIs available in ES2023 - \u003ccode\u003earray.with\u003c/code\u003e, \u003ccode\u003earray.findLast\u003c/code\u003e, \u003ccode\u003earray.findLastIndex\u003c/code\u003e, \u003ccode\u003earray.toSorted\u003c/code\u003e, \u003ccode\u003earray.toReversed\u003c/code\u003e, etc.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eESNext\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAdditional APIs available in ESNext - This changes as the JavaScript specification evolves\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eDOM\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003e\u003ca href=\"https://developer.mozilla.org/docs/Glossary/DOM\"\u003eDOM\u003c/a\u003e definitions - \u003ccode\u003ewindow\u003c/code\u003e, \u003ccode\u003edocument\u003c/code\u003e, etc.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eWebWorker\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAPIs available in \u003ca href=\"https://developer.mozilla.org/docs/Web/API/Web_Workers_API/Using_web_workers\"\u003eWebWorker\u003c/a\u003e contexts\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eScriptHost\u003c/code\u003e\u003c/td\u003e\n\u003ctd\u003eAPIs for the \u003ca href=\"https://wikipedia.org/wiki/Windows_Script_Host\"\u003eWindows Script Hosting System\u003c/a\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\u003c/table\u003e\n\u003ch3\u003eIndividual library components\u003c/h3\u003e\n\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eName\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eDOM.Iterable\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2015.Core\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2015.Collection\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2015.Generator\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2015.Iterable\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2015.Promise\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2015.Proxy\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2015.Reflect\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2015.Symbol\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2015.Symbol.WellKnown\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2016.Array.Include\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2017.object\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2017.Intl\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2017.SharedMemory\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2017.String\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2017.TypedArrays\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2018.Intl\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2018.Promise\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2018.RegExp\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2019.Array\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2019.Object\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2019.String\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2019.Symbol\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2020.String\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2020.Symbol.wellknown\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2021.Promise\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2021.String\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eES2021.WeakRef\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eESNext.AsyncIterable\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eESNext.Array\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eESNext.Intl\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003ccode\u003eESNext.Symbol\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\u003c/table\u003e\n\u003cp\u003eThis list may be out of date, you can see the full list in the \u003ca href=\"https://github.com/microsoft/TypeScript/tree/main/src/lib\"\u003eTypeScript source code\u003c/a\u003e.\u003c/p\u003e\n"
692
771
  },
693
772
  "libReplacement": {
694
- "default": true,
695
- "description": "Enable lib replacement.",
696
- "markdownDescription": "Enable lib replacement.\n\nSee more: https://www.typescriptlang.org/tsconfig#libReplacement",
773
+ "default": false,
774
+ "description": "TypeScript 4.5 introduced the possibility of substituting the default `lib` files with custom ones.\nAll built-in library files would first try to be resolved from packages named `@typescript/lib-*`.\nFor example, you could lock your `dom` libraries onto a specific version of [the `@types/web` package](https://www.npmjs.com/package/@types/web?activeTab=readme) with the following `package.json`:\n\n```json\n{\n \"devDependencies\": {\n \"@typescript/lib-dom\": \"npm:@types/web@0.0.199\"\n }\n}\n```\n\nWhen installed, a package called `@typescript/lib-dom` should exist, and TypeScript would always look there when searching for `lib.dom.d.ts`.\n\nThe `--libReplacement` flag allows you to disable this behavior.\nIf you're not using any `@typescript/lib-*` packages, you can now disable those package lookups with `--libReplacement false`.\nAs of TypeScript 6.0, `--libReplacement false` is the default. If you rely on `@typescript/lib-*` substitution, explicitly enable it with `--libReplacement true`.",
775
+ "markdownDescription": "TypeScript 4.5 introduced the possibility of substituting the default `lib` files with custom ones.\nAll built-in library files would first try to be resolved from packages named `@typescript/lib-*`.\nFor example, you could lock your `dom` libraries onto a specific version of [the `@types/web` package](https://www.npmjs.com/package/@types/web?activeTab=readme) with the following `package.json`:\n\n```json\n{\n \"devDependencies\": {\n \"@typescript/lib-dom\": \"npm:@types/web@0.0.199\"\n }\n}\n```\n\nWhen installed, a package called `@typescript/lib-dom` should exist, and TypeScript would always look there when searching for `lib.dom.d.ts`.\n\nThe `--libReplacement` flag allows you to disable this behavior.\nIf you're not using any `@typescript/lib-*` packages, you can now disable those package lookups with `--libReplacement false`.\nAs of TypeScript 6.0, `--libReplacement false` is the default. If you rely on `@typescript/lib-*` substitution, explicitly enable it with `--libReplacement true`.",
697
776
  "type": [
698
777
  "boolean",
699
778
  "null"
700
- ]
779
+ ],
780
+ "x-intellij-html-description": "\u003cp\u003eTypeScript 4.5 introduced the possibility of substituting the default \u003ccode\u003elib\u003c/code\u003e files with custom ones.\nAll built-in library files would first try to be resolved from packages named \u003ccode\u003e@typescript/lib-*\u003c/code\u003e.\nFor example, you could lock your \u003ccode\u003edom\u003c/code\u003e libraries onto a specific version of \u003ca href=\"https://www.npmjs.com/package/@types/web?activeTab=readme\"\u003ethe \u003ccode\u003e@types/web\u003c/code\u003e package\u003c/a\u003e with the following \u003ccode\u003epackage.json\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;devDependencies\u0026quot;: {\n \u0026quot;@typescript/lib-dom\u0026quot;: \u0026quot;npm:@types/web@0.0.199\u0026quot;\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhen installed, a package called \u003ccode\u003e@typescript/lib-dom\u003c/code\u003e should exist, and TypeScript would always look there when searching for \u003ccode\u003elib.dom.d.ts\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThe \u003ccode\u003e--libReplacement\u003c/code\u003e flag allows you to disable this behavior.\nIf you\u0026#39;re not using any \u003ccode\u003e@typescript/lib-*\u003c/code\u003e packages, you can now disable those package lookups with \u003ccode\u003e--libReplacement false\u003c/code\u003e.\nAs of TypeScript 6.0, \u003ccode\u003e--libReplacement false\u003c/code\u003e is the default. If you rely on \u003ccode\u003e@typescript/lib-*\u003c/code\u003e substitution, explicitly enable it with \u003ccode\u003e--libReplacement true\u003c/code\u003e.\u003c/p\u003e\n"
701
781
  },
702
782
  "listEmittedFiles": {
703
783
  "default": false,
704
- "description": "Print the names of emitted files after a compilation.",
705
- "markdownDescription": "Print the names of emitted files after a compilation.\n\nSee more: https://www.typescriptlang.org/tsconfig#listEmittedFiles",
784
+ "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.",
785
+ "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.",
706
786
  "type": [
707
787
  "boolean",
708
788
  "null"
709
- ]
789
+ ],
790
+ "x-intellij-html-description": "\u003cp\u003ePrint names of generated files part of the compilation to the terminal.\u003c/p\u003e\n\u003cp\u003eThis flag is useful in two cases:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eYou want to transpile TypeScript as a part of a build chain in the terminal where the filenames are processed in the next command.\u003c/li\u003e\n\u003cli\u003eYou are not sure that TypeScript has included a file you expected, as a part of debugging the \u003ca href=\"https://typescriptlang.org/tsconfig/#Project_Files_0\"\u003efile inclusion settings\u003c/a\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eFor example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;declaration\u0026quot;: true,\n \u0026quot;listEmittedFiles\u0026quot;: true\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWould echo paths like:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e$ npm run tsc\n\npath/to/example/index.js\npath/to/example/index.d.ts\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eNormally, TypeScript would return silently on success.\u003c/p\u003e\n"
710
791
  },
711
792
  "listFiles": {
712
793
  "default": false,
713
- "description": "Print all of the files read during the compilation.",
714
- "markdownDescription": "Print all of the files read during the compilation.\n\nSee more: https://www.typescriptlang.org/tsconfig#listFiles",
794
+ "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.",
795
+ "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.",
715
796
  "type": [
716
797
  "boolean",
717
798
  "null"
718
- ]
799
+ ],
800
+ "x-intellij-html-description": "\u003cp\u003ePrint names of files part of the compilation. This is useful when you are not sure that TypeScript has\nincluded a file you expected.\u003c/p\u003e\n\u003cp\u003eFor example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;listFiles\u0026quot;: true\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWould echo paths like:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e$ 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\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eNote if using TypeScript 4.2, prefer \u003ca href=\"https://typescriptlang.org/tsconfig/#explainFiles\"\u003e\u003ccode\u003eexplainFiles\u003c/code\u003e\u003c/a\u003e which offers an explanation of why a file was added too.\u003c/p\u003e\n"
719
801
  },
720
802
  "listFilesOnly": {
721
803
  "description": "Print names of files that are part of the compilation and then stop processing.",
@@ -725,21 +807,23 @@
725
807
  ]
726
808
  },
727
809
  "mapRoot": {
728
- "description": "Specify the location where debugger should locate map files instead of generated locations.",
729
- "markdownDescription": "Specify the location where debugger should locate map files instead of generated locations.\n\nSee more: https://www.typescriptlang.org/tsconfig#mapRoot",
810
+ "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`.",
811
+ "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`.",
730
812
  "type": [
731
813
  "string",
732
814
  "null"
733
- ]
815
+ ],
816
+ "x-intellij-html-description": "\u003cp\u003eSpecify the location where debugger should locate map files instead of generated locations.\nThis string is treated verbatim inside the source-map, for example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;sourceMap\u0026quot;: true,\n \u0026quot;mapRoot\u0026quot;: \u0026quot;https://my-website.com/debug/sourcemaps/\u0026quot;\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWould declare that \u003ccode\u003eindex.js\u003c/code\u003e will have sourcemaps at \u003ccode\u003ehttps://my-website.com/debug/sourcemaps/index.js.map\u003c/code\u003e.\u003c/p\u003e\n"
734
817
  },
735
818
  "maxNodeModuleJsDepth": {
736
819
  "default": 0,
737
- "description": "Specify the maximum folder depth used for checking JavaScript files from `node_modules`. Only applicable with `allowJs`.",
738
- "markdownDescription": "Specify the maximum folder depth used for checking JavaScript files from `node_modules`. Only applicable with `allowJs`.\n\nSee more: https://www.typescriptlang.org/tsconfig#maxNodeModuleJsDepth",
820
+ "description": "The maximum dependency depth to search under `node_modules` and load JavaScript files.\n\nThis flag can only be used when [`allowJs`](https://typescriptlang.org/tsconfig/#allowJs) is enabled, and is used if you want to have TypeScript infer types for all of the JavaScript inside your `node_modules`.\n\nIdeally this should stay at 0 (the default), and `d.ts` files should be used to explicitly define the shape of modules.\nHowever, there are cases where you may want to turn this on at the expense of speed and potential accuracy.",
821
+ "markdownDescription": "The maximum dependency depth to search under `node_modules` and load JavaScript files.\n\nThis flag can only be used when [`allowJs`](https://typescriptlang.org/tsconfig/#allowJs) is enabled, and is used if you want to have TypeScript infer types for all of the JavaScript inside your `node_modules`.\n\nIdeally this should stay at 0 (the default), and `d.ts` files should be used to explicitly define the shape of modules.\nHowever, there are cases where you may want to turn this on at the expense of speed and potential accuracy.",
739
822
  "type": [
740
823
  "number",
741
824
  "null"
742
- ]
825
+ ],
826
+ "x-intellij-html-description": "\u003cp\u003eThe maximum dependency depth to search under \u003ccode\u003enode_modules\u003c/code\u003e and load JavaScript files.\u003c/p\u003e\n\u003cp\u003eThis flag can only be used when \u003ca href=\"https://typescriptlang.org/tsconfig/#allowJs\"\u003e\u003ccode\u003eallowJs\u003c/code\u003e\u003c/a\u003e is enabled, and is used if you want to have TypeScript infer types for all of the JavaScript inside your \u003ccode\u003enode_modules\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eIdeally this should stay at 0 (the default), and \u003ccode\u003ed.ts\u003c/code\u003e files should be used to explicitly define the shape of modules.\nHowever, there are cases where you may want to turn this on at the expense of speed and potential accuracy.\u003c/p\u003e\n"
743
827
  },
744
828
  "module": {
745
829
  "anyOf": [
@@ -766,21 +850,22 @@
766
850
  "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])$"
767
851
  }
768
852
  ],
769
- "description": "Specify what module code is generated.",
770
- "markdownDescription": "Specify what module code is generated.\n\nSee more: https://www.typescriptlang.org/tsconfig#module",
853
+ "default": "esnext",
854
+ "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\u003e 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```\n\nAs of TypeScript 6.0, the default is `esnext`.",
855
+ "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\u003e 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```\n\nAs of TypeScript 6.0, the default is `esnext`.",
771
856
  "type": [
772
857
  "string",
773
858
  "null"
774
- ]
859
+ ],
860
+ "x-intellij-html-description": "\u003cp\u003eSets the module system for the program. See the \u003ca href=\"https://typescriptlang.org/docs/handbook/modules/theory.html#the-module-output-format\"\u003etheory behind TypeScript’s \u003ccode\u003emodule\u003c/code\u003e option\u003c/a\u003e and \u003ca href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#the-module-compiler-option\"\u003eits reference page\u003c/a\u003e for more information. You very likely want \u003ccode\u003e\u0026quot;nodenext\u0026quot;\u003c/code\u003e for modern Node.js projects and \u003ccode\u003epreserve\u003c/code\u003e or \u003ccode\u003eesnext\u003c/code\u003e for code that will be bundled.\u003c/p\u003e\n\u003cp\u003eChanging \u003ccode\u003emodule\u003c/code\u003e affects \u003ca href=\"https://typescriptlang.org/tsconfig/#moduleResolution\"\u003e\u003ccode\u003emoduleResolution\u003c/code\u003e\u003c/a\u003e which \u003ca href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option\"\u003ealso has a reference page\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eHere\u0026#39;s some example output for this file:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @filename: constants.ts\nexport const valueOfPi = 3.142;\n// ---cut---\n// @filename: index.ts\nimport { valueOfPi } from \u0026quot;./constants\u0026quot;;\n\nexport const twoPi = valueOfPi * 2;\n\u003c/code\u003e\u003c/pre\u003e\n\u003ch4\u003e\u003ccode\u003eCommonJS\u003c/code\u003e\u003c/h4\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @module: commonjs\n// @noErrors\nimport { valueOfPi } from \u0026quot;./constants\u0026quot;;\n\nexport const twoPi = valueOfPi * 2;\n\u003c/code\u003e\u003c/pre\u003e\n\u003ch4\u003e\u003ccode\u003eUMD\u003c/code\u003e\u003c/h4\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @module: umd\n// @noErrors\nimport { valueOfPi } from \u0026quot;./constants\u0026quot;;\n\nexport const twoPi = valueOfPi * 2;\n\u003c/code\u003e\u003c/pre\u003e\n\u003ch4\u003e\u003ccode\u003eAMD\u003c/code\u003e\u003c/h4\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @module: amd\n// @noErrors\nimport { valueOfPi } from \u0026quot;./constants\u0026quot;;\n\nexport const twoPi = valueOfPi * 2;\n\u003c/code\u003e\u003c/pre\u003e\n\u003ch4\u003e\u003ccode\u003eSystem\u003c/code\u003e\u003c/h4\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @module: system\n// @noErrors\nimport { valueOfPi } from \u0026quot;./constants\u0026quot;;\n\nexport const twoPi = valueOfPi * 2;\n\u003c/code\u003e\u003c/pre\u003e\n\u003ch4\u003e\u003ccode\u003eESNext\u003c/code\u003e\u003c/h4\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @module: esnext\n// @noErrors\nimport { valueOfPi } from \u0026quot;./constants\u0026quot;;\n\nexport const twoPi = valueOfPi * 2;\n\u003c/code\u003e\u003c/pre\u003e\n\u003ch4\u003e\u003ccode\u003eES2015\u003c/code\u003e/\u003ccode\u003eES6\u003c/code\u003e/\u003ccode\u003eES2020\u003c/code\u003e/\u003ccode\u003eES2022\u003c/code\u003e\u003c/h4\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @module: es2015\n// @noErrors\nimport { valueOfPi } from \u0026quot;./constants\u0026quot;;\n\nexport const twoPi = valueOfPi * 2;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eIn addition to the base functionality of \u003ccode\u003eES2015\u003c/code\u003e/\u003ccode\u003eES6\u003c/code\u003e, \u003ccode\u003eES2020\u003c/code\u003e adds support for \u003ca href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import\"\u003edynamic \u003ccode\u003eimport\u003c/code\u003es\u003c/a\u003e, and \u003ca href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta\"\u003e\u003ccode\u003eimport.meta\u003c/code\u003e\u003c/a\u003e while \u003ccode\u003eES2022\u003c/code\u003e further adds support for \u003ca href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await#top_level_await\"\u003etop level \u003ccode\u003eawait\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n\u003ch4\u003e\u003ccode\u003enode16\u003c/code\u003e/\u003ccode\u003enode18\u003c/code\u003e/\u003ccode\u003enode20\u003c/code\u003e/\u003ccode\u003enodenext\u003c/code\u003e\u003c/h4\u003e\n\u003cp\u003eThe \u003ccode\u003enode16\u003c/code\u003e, \u003ccode\u003enode18\u003c/code\u003e, \u003ccode\u003enode20\u003c/code\u003e, and \u003ccode\u003enodenext\u003c/code\u003e modes integrate with Node\u0026#39;s \u003ca href=\"https://nodejs.org/api/esm.html\"\u003enative ECMAScript Module support\u003c/a\u003e. The emitted JavaScript uses either \u003ccode\u003eCommonJS\u003c/code\u003e or \u003ccode\u003eES2020\u003c/code\u003e output depending on the file extension and the value of the \u003ccode\u003etype\u003c/code\u003e setting in the nearest \u003ccode\u003epackage.json\u003c/code\u003e. Module resolution also works differently. You can learn more in the \u003ca href=\"https://typescriptlang.org/docs/handbook/esm-node.html\"\u003ehandbook\u003c/a\u003e and \u003ca href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#node16-node18-node20-nodenext\"\u003eModules Reference\u003c/a\u003e.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003enode16\u003c/code\u003e is available from TypeScript 4.7\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003enode18\u003c/code\u003e is available from TypeScript 5.8 as a replacement for \u003ccode\u003enode16\u003c/code\u003e, with added support for import attributes.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003enode20\u003c/code\u003e adds support for require(ESM).\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003enodenext\u003c/code\u003e is available from TypeScript 4.7, but its behavior changes with the latest stable versions of Node.js. \u003ccode\u003e--module nodenext\u003c/code\u003e implies the floating \u003ccode\u003e--target esnext\u003c/code\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch4\u003e\u003ccode\u003epreserve\u003c/code\u003e\u003c/h4\u003e\n\u003cp\u003eIn \u003ccode\u003e--module preserve\u003c/code\u003e (\u003ca href=\"https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-4.html#support-for-require-calls-in---moduleresolution-bundler-and---module-preserve\"\u003eadded\u003c/a\u003e in TypeScript 5.4), ECMAScript imports and exports written in input files are preserved in the output, and CommonJS-style \u003ccode\u003eimport x = require(\u0026quot;...\u0026quot;)\u003c/code\u003e and \u003ccode\u003eexport = ...\u003c/code\u003e statements are emitted as CommonJS \u003ccode\u003erequire\u003c/code\u003e and \u003ccode\u003emodule.exports\u003c/code\u003e. 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).\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @module: preserve\n// @noErrors\nimport { valueOfPi } from \u0026quot;./constants\u0026quot;;\nimport constants = require(\u0026quot;./constants\u0026quot;);\n\nexport const piSquared = valueOfPi * constants.valueOfPi;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhile it’s rare to need to mix imports and require calls in the same file, this \u003ccode\u003emodule\u003c/code\u003e mode best reflects the capabilities of most modern bundlers, as well as the Bun runtime.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eWhy care about TypeScript’s \u003ccode\u003emodule\u003c/code\u003e emit with a bundler or with Bun, where you’re likely also setting \u003ccode\u003enoEmit\u003c/code\u003e? TypeScript’s type checking and module resolution behavior are affected by the module format that it \u003cem\u003ewould\u003c/em\u003e emit. Setting \u003ccode\u003emodule\u003c/code\u003e 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.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch4\u003e\u003ccode\u003eNone\u003c/code\u003e\u003c/h4\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @module: none\n// @noErrors\nimport { valueOfPi } from \u0026quot;./constants\u0026quot;;\n\nexport const twoPi = valueOfPi * 2;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eAs of TypeScript 6.0, the default is \u003ccode\u003eesnext\u003c/code\u003e.\u003c/p\u003e\n"
775
861
  },
776
862
  "moduleDetection": {
777
- "description": "Control what method is used to detect module-format JS files.",
863
+ "description": "This setting controls how TypeScript determines whether a file is a\n[script or a module](https://typescriptlang.org/docs/handbook/modules/theory.html#scripts-and-modules-in-javascript).\n\nThere are three choices:\n\n- `\"auto\"` (default) - TypeScript will not only look for import and export statements, but it will also check whether the `\"type\"` field in a `package.json` is set to `\"module\"` when running with [`module`](https://typescriptlang.org/tsconfig/#module): `nodenext` or `node16`, and check whether the current file is a JSX file when running under [`jsx`](https://typescriptlang.org/tsconfig/#jsx): `react-jsx`.\n\n- `\"legacy\"` - The same behavior as 4.6 and prior, usings import and export statements to determine whether a file is a module.\n\n- `\"force\"` - Ensures that every non-declaration file is treated as a module.",
778
864
  "enum": [
779
865
  "auto",
780
866
  "legacy",
781
867
  "force"
782
- ],
783
- "markdownDescription": "Control what method is used to detect module-format JS files.\n\nSee more: https://www.typescriptlang.org/tsconfig#moduleDetection"
868
+ ]
784
869
  },
785
870
  "moduleResolution": {
786
871
  "anyOf": [
@@ -806,24 +891,26 @@
806
891
  "pattern": "^(([Nn]ode)|([Nn]ode1[06])|([Nn]ode[Nn]ext)|([Cc]lassic)|([Bb]undler))$"
807
892
  }
808
893
  ],
809
- "description": "Specify how TypeScript looks up a file from a given module specifier.",
810
- "markdownDescription": "Specify how TypeScript looks up a file from a given module specifier.\n\nSee more: https://www.typescriptlang.org/tsconfig#moduleResolution",
894
+ "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).",
895
+ "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).",
811
896
  "type": [
812
897
  "string",
813
898
  "null"
814
- ]
899
+ ],
900
+ "x-intellij-html-description": "\u003cp\u003eSpecify the module resolution strategy:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003e\u0026#39;node16\u0026#39;\u003c/code\u003e or \u003ccode\u003e\u0026#39;nodenext\u0026#39;\u003c/code\u003e for modern versions of Node.js. Node.js v12 and later supports both ECMAScript imports and CommonJS \u003ccode\u003erequire\u003c/code\u003e, which resolve using different algorithms. These \u003ccode\u003emoduleResolution\u003c/code\u003e values, when combined with the corresponding \u003ca href=\"https://typescriptlang.org/tsconfig/#module\"\u003e\u003ccode\u003emodule\u003c/code\u003e\u003c/a\u003e values, picks the right algorithm for each resolution based on whether Node.js will see an \u003ccode\u003eimport\u003c/code\u003e or \u003ccode\u003erequire\u003c/code\u003e in the output JavaScript code.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e\u0026#39;node10\u0026#39;\u003c/code\u003e (previously called \u003ccode\u003e\u0026#39;node\u0026#39;\u003c/code\u003e) for Node.js versions older than v10, which only support CommonJS \u003ccode\u003erequire\u003c/code\u003e. You probably won\u0026#39;t need to use \u003ccode\u003enode10\u003c/code\u003e in modern code.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e\u0026#39;bundler\u0026#39;\u003c/code\u003e for use with bundlers. Like \u003ccode\u003enode16\u003c/code\u003e and \u003ccode\u003enodenext\u003c/code\u003e, this mode supports package.json \u003ccode\u003e\u0026quot;imports\u0026quot;\u003c/code\u003e and \u003ccode\u003e\u0026quot;exports\u0026quot;\u003c/code\u003e, but unlike the Node.js resolution modes, \u003ccode\u003ebundler\u003c/code\u003e never requires file extensions on relative paths in imports.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e\u0026#39;classic\u0026#39;\u003c/code\u003e was used in TypeScript before the release of 1.6. \u003ccode\u003eclassic\u003c/code\u003e should not be used.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThere are reference pages explaining the \u003ca href=\"https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution\"\u003etheory behind TypeScript’s module resolution\u003c/a\u003e and the \u003ca href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option\"\u003edetails of each option\u003c/a\u003e.\u003c/p\u003e\n"
815
901
  },
816
902
  "moduleSuffixes": {
817
- "description": "List of file name suffixes to search when resolving a module.",
903
+ "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`.",
818
904
  "items": {
819
905
  "type": "string"
820
906
  },
821
- "markdownDescription": "List of file name suffixes to search when resolving a module.\n\nSee more: https://www.typescriptlang.org/tsconfig#moduleSuffixes",
907
+ "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`.",
822
908
  "type": [
823
909
  "array",
824
910
  "null"
825
911
  ],
826
- "uniqueItems": true
912
+ "uniqueItems": true,
913
+ "x-intellij-html-description": "\u003cp\u003eProvides a way to override the default list of file name suffixes to search when resolving a module.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;moduleSuffixes\u0026quot;: [\u0026quot;.ios\u0026quot;, \u0026quot;.native\u0026quot;, \u0026quot;\u0026quot;]\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eGiven the above configuration, an import like the following:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eimport * as foo from \u0026quot;./foo\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eTypeScript will look for the relative files \u003ccode\u003e./foo.ios.ts\u003c/code\u003e, \u003ccode\u003e./foo.native.ts\u003c/code\u003e, and finally \u003ccode\u003e./foo.ts\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eNote the empty string \u003ccode\u003e\u0026quot;\u0026quot;\u003c/code\u003e in \u003ca href=\"https://typescriptlang.org/tsconfig/#moduleSuffixes\"\u003e\u003ccode\u003emoduleSuffixes\u003c/code\u003e\u003c/a\u003e which is necessary for TypeScript to also look-up \u003ccode\u003e./foo.ts\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThis feature can be useful for React Native projects where each target platform can use a separate tsconfig.json with differing \u003ccode\u003emoduleSuffixes\u003c/code\u003e.\u003c/p\u003e\n"
827
914
  },
828
915
  "newLine": {
829
916
  "anyOf": [
@@ -838,179 +925,199 @@
838
925
  }
839
926
  ],
840
927
  "default": "lf",
841
- "description": "Set the newline character for emitting files.",
842
- "markdownDescription": "Set the newline character for emitting files.\n\nSee more: https://www.typescriptlang.org/tsconfig#newLine",
928
+ "description": "Specify the end of line sequence to be used when emitting files: 'CRLF' (dos) or 'LF' (unix).",
929
+ "markdownDescription": "Specify the end of line sequence to be used when emitting files: 'CRLF' (dos) or 'LF' (unix).",
843
930
  "type": [
844
931
  "string",
845
932
  "null"
846
- ]
933
+ ],
934
+ "x-intellij-html-description": "\u003cp\u003eSpecify the end of line sequence to be used when emitting files: \u0026#39;CRLF\u0026#39; (dos) or \u0026#39;LF\u0026#39; (unix).\u003c/p\u003e\n"
847
935
  },
848
936
  "noCheck": {
849
937
  "default": false,
850
938
  "description": "Disable full type checking (only critical parse and emit errors will be reported).",
851
- "markdownDescription": "Disable full type checking (only critical parse and emit errors will be reported).\n\nSee more: https://www.typescriptlang.org/tsconfig#noCheck",
939
+ "markdownDescription": "Disable full type checking (only critical parse and emit errors will be reported).",
852
940
  "type": [
853
941
  "boolean",
854
942
  "null"
855
- ]
943
+ ],
944
+ "x-intellij-html-description": "\u003cp\u003eDisable full type checking (only critical parse and emit errors will be reported).\u003c/p\u003e\n"
856
945
  },
857
946
  "noEmit": {
858
947
  "default": false,
859
- "description": "Disable emitting files from a compilation.",
860
- "markdownDescription": "Disable emitting files from a compilation.\n\nSee more: https://www.typescriptlang.org/tsconfig#noEmit",
948
+ "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.",
949
+ "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.",
861
950
  "type": [
862
951
  "boolean",
863
952
  "null"
864
- ]
953
+ ],
954
+ "x-intellij-html-description": "\u003cp\u003eDo not emit compiler output files like JavaScript source code, source-maps or declarations.\u003c/p\u003e\n\u003cp\u003eThis makes room for another tool like \u003ca href=\"https://babeljs.io/\"\u003eBabel\u003c/a\u003e, or \u003ca href=\"https://github.com/swc-project/swc\"\u003eswc\u003c/a\u003e to handle converting the TypeScript file to a file which can run inside a JavaScript environment.\u003c/p\u003e\n\u003cp\u003eYou can then use TypeScript as a tool for providing editor integration, and as a source code type-checker.\u003c/p\u003e\n"
865
955
  },
866
956
  "noEmitHelpers": {
867
957
  "default": false,
868
- "description": "Disable generating custom helper functions like `__extends` in compiled output.",
869
- "markdownDescription": "Disable generating custom helper functions like `__extends` in compiled output.\n\nSee more: https://www.typescriptlang.org/tsconfig#noEmitHelpers",
958
+ "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) =\u003e {\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) =\u003e {\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) =\u003e {\n // Get API\n return {};\n};\n```",
959
+ "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) =\u003e {\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) =\u003e {\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) =\u003e {\n // Get API\n return {};\n};\n```",
870
960
  "type": [
871
961
  "boolean",
872
962
  "null"
873
- ]
963
+ ],
964
+ "x-intellij-html-description": "\u003cp\u003eInstead of importing helpers with \u003ca href=\"https://typescriptlang.org/tsconfig/#importHelpers\"\u003e\u003ccode\u003eimportHelpers\u003c/code\u003e\u003c/a\u003e, you can provide implementations in the global scope for the helpers you use and completely turn off emitting of helper functions.\u003c/p\u003e\n\u003cp\u003eFor example, using this \u003ccode\u003easync\u003c/code\u003e function in ES5 requires a \u003ccode\u003eawait\u003c/code\u003e-like function and \u003ccode\u003egenerator\u003c/code\u003e-like function to run:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003econst getAPI = async (url: string) =\u0026gt; {\n // Get API\n return {};\n};\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhich creates quite a lot of JavaScript:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @target: ES5\nconst getAPI = async (url: string) =\u0026gt; {\n // Get API\n return {};\n};\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhich can be switched out with your own globals via this flag:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @target: ES5\n// @noEmitHelpers\nconst getAPI = async (url: string) =\u0026gt; {\n // Get API\n return {};\n};\n\u003c/code\u003e\u003c/pre\u003e\n"
874
965
  },
875
966
  "noEmitOnError": {
876
967
  "default": false,
877
- "description": "Disable emitting files if any type checking errors are reported.",
878
- "markdownDescription": "Disable emitting files if any type checking errors are reported.\n\nSee more: https://www.typescriptlang.org/tsconfig#noEmitOnError",
968
+ "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.",
969
+ "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.",
879
970
  "type": [
880
971
  "boolean",
881
972
  "null"
882
- ]
973
+ ],
974
+ "x-intellij-html-description": "\u003cp\u003eDo not emit compiler output files like JavaScript source code, source-maps or declarations if any errors were reported.\u003c/p\u003e\n\u003cp\u003eThis defaults to \u003ccode\u003efalse\u003c/code\u003e, 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.\u003c/p\u003e\n"
883
975
  },
884
976
  "noErrorTruncation": {
885
977
  "default": false,
886
- "description": "Disable truncating types in error messages.",
887
- "markdownDescription": "Disable truncating types in error messages.\n\nSee more: https://www.typescriptlang.org/tsconfig#noErrorTruncation",
978
+ "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```",
979
+ "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```",
888
980
  "type": [
889
981
  "boolean",
890
982
  "null"
891
- ]
983
+ ],
984
+ "x-intellij-html-description": "\u003cp\u003eDo not truncate error messages.\u003c/p\u003e\n\u003cp\u003eWith \u003ccode\u003efalse\u003c/code\u003e, the default.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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 \u0026#39;x\u0026#39; should be truncated in error message\nvar s: string = x;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith \u003ccode\u003etrue\u003c/code\u003e\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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 \u0026#39;x\u0026#39; should be truncated in error message\nvar s: string = x;\n\u003c/code\u003e\u003c/pre\u003e\n"
892
985
  },
893
986
  "noFallthroughCasesInSwitch": {
894
987
  "default": false,
895
- "description": "Enable error reporting for fallthrough cases in switch statements.",
896
- "markdownDescription": "Enable error reporting for fallthrough cases in switch statements.\n\nSee more: https://www.typescriptlang.org/tsconfig#noFallthroughCasesInSwitch",
988
+ "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```",
989
+ "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```",
897
990
  "type": [
898
991
  "boolean",
899
992
  "null"
900
- ]
993
+ ],
994
+ "x-intellij-html-description": "\u003cp\u003eReport errors for fallthrough cases in switch statements.\nEnsures that any non-empty case inside a switch statement includes either \u003ccode\u003ebreak\u003c/code\u003e, \u003ccode\u003ereturn\u003c/code\u003e, or \u003ccode\u003ethrow\u003c/code\u003e.\nThis means you won\u0026#39;t accidentally ship a case fallthrough bug.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @noFallthroughCasesInSwitch\n// @errors: 7029\nconst a: number = 6;\n\nswitch (a) {\n case 0:\n console.log(\u0026quot;even\u0026quot;);\n case 1:\n console.log(\u0026quot;odd\u0026quot;);\n break;\n}\n\u003c/code\u003e\u003c/pre\u003e\n"
901
995
  },
902
996
  "noImplicitAny": {
903
- "description": "Enable error reporting for expressions and declarations with an implied `any` type.",
904
- "markdownDescription": "Enable error reporting for expressions and declarations with an implied `any` type.\n\nSee more: https://www.typescriptlang.org/tsconfig#noImplicitAny",
997
+ "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```",
998
+ "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```",
905
999
  "type": [
906
1000
  "boolean",
907
1001
  "null"
908
- ]
1002
+ ],
1003
+ "x-intellij-html-description": "\u003cp\u003eIn some cases where no type annotations are present, TypeScript will fall back to a type of \u003ccode\u003eany\u003c/code\u003e for a variable when it cannot infer the type.\u003c/p\u003e\n\u003cp\u003eThis can cause some errors to be missed, for example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @noImplicitAny: false\nfunction fn(s) {\n // No error?\n console.log(s.subtr(3));\n}\nfn(42);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eTurning on \u003ccode\u003enoImplicitAny\u003c/code\u003e however TypeScript will issue an error whenever it would have inferred \u003ccode\u003eany\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 7006\nfunction fn(s) {\n console.log(s.subtr(3));\n}\n\u003c/code\u003e\u003c/pre\u003e\n"
909
1004
  },
910
1005
  "noImplicitOverride": {
911
1006
  "default": false,
912
- "description": "Ensure overriding members in derived classes are marked with an override modifier.",
913
- "markdownDescription": "Ensure overriding members in derived classes are marked with an override modifier.\n\nSee more: https://www.typescriptlang.org/tsconfig#noImplicitOverride",
1007
+ "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```",
1008
+ "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```",
914
1009
  "type": [
915
1010
  "boolean",
916
1011
  "null"
917
- ]
1012
+ ],
1013
+ "x-intellij-html-description": "\u003cp\u003eWhen working with classes which use inheritance, it\u0026#39;s possible for a sub-class to get \u0026quot;out of sync\u0026quot; with the functions it overloads when they are renamed in the base class.\u003c/p\u003e\n\u003cp\u003eFor example, imagine you are modeling a music album syncing system:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eclass 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\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThen when you add support for machine-learning generated playlists, you refactor the \u003ccode\u003eAlbum\u003c/code\u003e class to have a \u0026#39;setup\u0026#39; function instead:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eclass 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\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eIn this case, TypeScript has provided no warning that \u003ccode\u003edownload\u003c/code\u003e on \u003ccode\u003eSharedAlbum\u003c/code\u003e \u003cem\u003eexpected\u003c/em\u003e to override a function in the base class.\u003c/p\u003e\n\u003cp\u003eUsing \u003ccode\u003enoImplicitOverride\u003c/code\u003e you can ensure that the sub-classes never go out of sync, by ensuring that functions which override include the keyword \u003ccode\u003eoverride\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThe following example has \u003ccode\u003enoImplicitOverride\u003c/code\u003e enabled, and you can see the error received when \u003ccode\u003eoverride\u003c/code\u003e is missing:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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\u003c/code\u003e\u003c/pre\u003e\n"
918
1014
  },
919
1015
  "noImplicitReturns": {
920
1016
  "default": false,
921
- "description": "Enable error reporting for codepaths that do not explicitly return in a function.",
922
- "markdownDescription": "Enable error reporting for codepaths that do not explicitly return in a function.\n\nSee more: https://www.typescriptlang.org/tsconfig#noImplicitReturns",
1017
+ "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```",
1018
+ "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```",
923
1019
  "type": [
924
1020
  "boolean",
925
1021
  "null"
926
- ]
1022
+ ],
1023
+ "x-intellij-html-description": "\u003cp\u003eWhen enabled, TypeScript will check all code paths in a function to ensure they return a value.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 2366 2322\nfunction lookupHeadphonesManufacturer(color: \u0026quot;blue\u0026quot; | \u0026quot;black\u0026quot;): string {\n if (color === \u0026quot;blue\u0026quot;) {\n return \u0026quot;beats\u0026quot;;\n } else {\n \u0026quot;bose\u0026quot;;\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n"
927
1024
  },
928
1025
  "noImplicitThis": {
929
- "description": "Enable error reporting when `this` is given the type `any`.",
930
- "markdownDescription": "Enable error reporting when `this` is given the type `any`.\n\nSee more: https://www.typescriptlang.org/tsconfig#noImplicitThis",
1026
+ "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```",
1027
+ "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```",
931
1028
  "type": [
932
1029
  "boolean",
933
1030
  "null"
934
- ]
1031
+ ],
1032
+ "x-intellij-html-description": "\u003cp\u003eRaise error on \u0026#39;this\u0026#39; expressions with an implied \u0026#39;any\u0026#39; type.\u003c/p\u003e\n\u003cp\u003eFor example, the class below returns a function which tries to access \u003ccode\u003ethis.width\u003c/code\u003e and \u003ccode\u003ethis.height\u003c/code\u003e – but the context\nfor \u003ccode\u003ethis\u003c/code\u003e inside the function inside \u003ccode\u003egetAreaFunction\u003c/code\u003e is not the instance of the Rectangle.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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\u003c/code\u003e\u003c/pre\u003e\n"
935
1033
  },
936
1034
  "noImplicitUseStrict": {
937
1035
  "default": false,
938
- "description": "Disable adding `use strict` directives in emitted JavaScript files.",
939
- "markdownDescription": "Disable adding `use strict` directives in emitted JavaScript files.\n\nSee more: https://www.typescriptlang.org/tsconfig#noImplicitUseStrict",
1036
+ "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.",
1037
+ "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.",
940
1038
  "type": [
941
1039
  "boolean",
942
1040
  "null"
943
- ]
1041
+ ],
1042
+ "x-intellij-html-description": "\u003cp\u003eYou shouldn\u0026#39;t need this. By default, when emitting a module file to a non-ES6 target, TypeScript emits a \u003ccode\u003e\u0026quot;use strict\u0026quot;;\u003c/code\u003e prologue at the top of the file.\nThis setting disables the prologue.\u003c/p\u003e\n"
944
1043
  },
945
1044
  "noLib": {
946
1045
  "default": false,
947
- "description": "Disable including any library files, including the default lib.d.ts.",
948
- "markdownDescription": "Disable including any library files, including the default lib.d.ts.\n\nSee more: https://www.typescriptlang.org/tsconfig#noLib",
1046
+ "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.",
1047
+ "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.",
949
1048
  "type": [
950
1049
  "boolean",
951
1050
  "null"
952
- ]
1051
+ ],
1052
+ "x-intellij-html-description": "\u003cp\u003eDisables the automatic inclusion of any library files.\nIf this option is set, \u003ccode\u003elib\u003c/code\u003e is ignored.\u003c/p\u003e\n\u003cp\u003eTypeScript \u003cem\u003ecannot\u003c/em\u003e compile anything without a set of interfaces for key primitives like: \u003ccode\u003eArray\u003c/code\u003e, \u003ccode\u003eBoolean\u003c/code\u003e, \u003ccode\u003eFunction\u003c/code\u003e, \u003ccode\u003eIArguments\u003c/code\u003e, \u003ccode\u003eNumber\u003c/code\u003e, \u003ccode\u003eObject\u003c/code\u003e, \u003ccode\u003eRegExp\u003c/code\u003e, and \u003ccode\u003eString\u003c/code\u003e. It is expected that if you use \u003ccode\u003enoLib\u003c/code\u003e you will be including your own type definitions for these.\u003c/p\u003e\n"
953
1053
  },
954
1054
  "noPropertyAccessFromIndexSignature": {
955
- "description": "Enforces using indexed accessors for keys declared using an indexed type.",
956
- "markdownDescription": "Enforces using indexed accessors for keys declared using an indexed type.\n\nSee more: https://www.typescriptlang.org/tsconfig#noPropertyAccessFromIndexSignature",
1055
+ "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// ^ (property) GameSettings.speed: \"fast\" | \"medium\" | \"slow\"\nsettings.quality;\n// ^ (property) GameSettings.quality: \"high\" | \"low\"\n\n// Unknown key accessors are allowed on\n// this object, and are `string`\nsettings.username;\n// ^ (index) GameSettings[string]: string\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// ^ (index) GameSettings[string]: string\n```\n\nThe goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.",
1056
+ "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// ^ (property) GameSettings.speed: \"fast\" | \"medium\" | \"slow\"\nsettings.quality;\n// ^ (property) GameSettings.quality: \"high\" | \"low\"\n\n// Unknown key accessors are allowed on\n// this object, and are `string`\nsettings.username;\n// ^ (index) GameSettings[string]: string\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// ^ (index) GameSettings[string]: string\n```\n\nThe goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.",
957
1057
  "type": [
958
1058
  "boolean",
959
1059
  "null"
960
- ]
1060
+ ],
1061
+ "x-intellij-html-description": "\u003cp\u003eThis setting ensures consistency between accessing a field via the \u0026quot;dot\u0026quot; (\u003ccode\u003eobj.key\u003c/code\u003e) syntax, and \u0026quot;indexed\u0026quot; (\u003ccode\u003eobj[\u0026quot;key\u0026quot;]\u003c/code\u003e) and the way which the property is declared in the type.\u003c/p\u003e\n\u003cp\u003eWithout this flag, TypeScript will allow you to use the dot syntax to access fields which are not defined:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 4111\ndeclare function getSettings(): GameSettings;\n// ---cut---\ninterface GameSettings {\n // Known up-front properties\n speed: \u0026quot;fast\u0026quot; | \u0026quot;medium\u0026quot; | \u0026quot;slow\u0026quot;;\n quality: \u0026quot;high\u0026quot; | \u0026quot;low\u0026quot;;\n\n // Assume anything unknown to the interface\n // is a string.\n [key: string]: string;\n}\n\nconst settings = getSettings();\nsettings.speed;\n// ^ (property) GameSettings.speed: \u0026quot;fast\u0026quot; | \u0026quot;medium\u0026quot; | \u0026quot;slow\u0026quot;\nsettings.quality;\n// ^ (property) GameSettings.quality: \u0026quot;high\u0026quot; | \u0026quot;low\u0026quot;\n\n// Unknown key accessors are allowed on\n// this object, and are `string`\nsettings.username;\n// ^ (index) GameSettings[string]: string\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eTurning the flag on will raise an error because the unknown field uses dot syntax instead of indexed syntax.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 4111\n// @noPropertyAccessFromIndexSignature\ndeclare function getSettings(): GameSettings;\ninterface GameSettings {\n speed: \u0026quot;fast\u0026quot; | \u0026quot;medium\u0026quot; | \u0026quot;slow\u0026quot;;\n quality: \u0026quot;high\u0026quot; | \u0026quot;low\u0026quot;;\n [key: string]: string;\n}\n// ---cut---\nconst settings = getSettings();\nsettings.speed;\nsettings.quality;\n\n// This would need to be settings[\u0026quot;username\u0026quot;];\nsettings.username;\n// ^ (index) GameSettings[string]: string\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.\u003c/p\u003e\n"
961
1062
  },
962
1063
  "noResolve": {
963
1064
  "default": false,
964
- "description": "Disallow `import`s, `require`s or `\u003creference\u003e`s from expanding the number of files TypeScript should add to a project.",
965
- "markdownDescription": "Disallow `import`s, `require`s or `\u003creference\u003e`s from expanding the number of files TypeScript should add to a project.\n\nSee more: https://www.typescriptlang.org/tsconfig#noResolve",
1065
+ "description": "By default, TypeScript will examine the initial set of files for `import` and `\u003creference` 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.",
1066
+ "markdownDescription": "By default, TypeScript will examine the initial set of files for `import` and `\u003creference` 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.",
966
1067
  "type": [
967
1068
  "boolean",
968
1069
  "null"
969
- ]
1070
+ ],
1071
+ "x-intellij-html-description": "\u003cp\u003eBy default, TypeScript will examine the initial set of files for \u003ccode\u003eimport\u003c/code\u003e and \u003ccode\u003e\u0026lt;reference\u003c/code\u003e directives and add these resolved files to your program.\u003c/p\u003e\n\u003cp\u003eIf \u003ccode\u003enoResolve\u003c/code\u003e is set, this process doesn\u0026#39;t happen.\nHowever, \u003ccode\u003eimport\u003c/code\u003e statements are still checked to see if they resolve to a valid module, so you\u0026#39;ll need to make sure this is satisfied by some other means.\u003c/p\u003e\n"
970
1072
  },
971
1073
  "noStrictGenericChecks": {
972
1074
  "default": false,
973
- "description": "Disable strict checking of generic signatures in function types.",
974
- "markdownDescription": "Disable strict checking of generic signatures in function types.\n\nSee more: https://www.typescriptlang.org/tsconfig#noStrictGenericChecks",
1075
+ "description": "TypeScript will unify type parameters when comparing two generic functions.\n\n```ts twoslash\n// @errors: 2322\n\ntype A = \u003cT, U\u003e(x: T, y: U) =\u003e [T, U];\ntype B = \u003cS\u003e(x: S, y: S) =\u003e [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.",
1076
+ "markdownDescription": "TypeScript will unify type parameters when comparing two generic functions.\n\n```ts twoslash\n// @errors: 2322\n\ntype A = \u003cT, U\u003e(x: T, y: U) =\u003e [T, U];\ntype B = \u003cS\u003e(x: S, y: S) =\u003e [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.",
975
1077
  "type": [
976
1078
  "boolean",
977
1079
  "null"
978
- ]
1080
+ ],
1081
+ "x-intellij-html-description": "\u003cp\u003eTypeScript will unify type parameters when comparing two generic functions.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 2322\n\ntype A = \u0026lt;T, U\u0026gt;(x: T, y: U) =\u0026gt; [T, U];\ntype B = \u0026lt;S\u0026gt;(x: S, y: S) =\u0026gt; [S, S];\n\nfunction f(a: A, b: B) {\n b = a; // Ok\n a = b; // Error\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis flag can be used to remove that check.\u003c/p\u003e\n"
979
1082
  },
980
1083
  "noUncheckedIndexedAccess": {
981
- "description": "Add `undefined` to a type when accessed using an index.",
982
- "markdownDescription": "Add `undefined` to a type when accessed using an index.\n\nSee more: https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess",
1084
+ "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// ^ const os: string\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^ const nodeEnv: string\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// ^ const os: string\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^ const nodeEnv: string | undefined\n```",
1085
+ "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// ^ const os: string\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^ const nodeEnv: string\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// ^ const os: string\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^ const nodeEnv: string | undefined\n```",
983
1086
  "type": [
984
1087
  "boolean",
985
1088
  "null"
986
- ]
1089
+ ],
1090
+ "x-intellij-html-description": "\u003cp\u003eTypeScript has a way to describe objects which have unknown keys but known values on an object, via index signatures.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003einterface 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// ^ const os: string\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^ const nodeEnv: string\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eTurning on \u003ccode\u003enoUncheckedIndexedAccess\u003c/code\u003e will add \u003ccode\u003eundefined\u003c/code\u003e to any un-declared field in the type.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003einterface 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// ^ const os: string\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n// ^ const nodeEnv: string | undefined\n\u003c/code\u003e\u003c/pre\u003e\n"
987
1091
  },
988
1092
  "noUncheckedSideEffectImports": {
989
- "default": false,
990
- "description": "Check side effect imports.",
991
- "markdownDescription": "Check side effect imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#noUncheckedSideEffectImports",
1093
+ "default": true,
1094
+ "description": "In JavaScript it's possible to `import` a module without actually importing any values from it.\n\n```ts\nimport \"some-module\";\n```\n\nThese imports are often called *side effect imports* because the only useful behavior they can provide is by executing some side effect (like registering a global variable, or adding a polyfill to a prototype).\n\nBy default, TypeScript will not check these imports for validity. If the import resolves to a valid source file, TypeScript will load and check the file.\nIf no source file is found, TypeScript will silently ignore the import.\n\nThis is surprising behavior, but it partially stems from modeling patterns in the JavaScript ecosystem.\nFor example, this syntax has also been used with special loaders in bundlers to load CSS or other assets.\nYour bundler might be configured in such a way where you can include specific `.css` files by writing something like the following:\n\n```tsx\nimport \"./button-component.css\";\n\nexport function Button() {\n // ...\n}\n```\n\nStill, this masks potential typos on side effect imports.\n\nWhen `--noUncheckedSideEffectImports` is enabled, TypeScript will error if it can't find a source file for a side effect import.\n\n```ts\nimport \"oops-this-module-does-not-exist\";\n// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n// error: Cannot find module 'oops-this-module-does-not-exist' or its corresponding\n// type declarations.\n```\n\nWhen enabling this option, some working code may now receive an error, like in the CSS example above.\nTo work around this, users who want to just write side effect `import`s for assets might be better served by writing what's called an *ambient module declaration* with a wildcard specifier.\nIt would go in a global file and look something like the following:\n\n```ts\n// ./src/globals.d.ts\n\n// Recognize all CSS files as module imports.\ndeclare module \"*.css\" {}\n```\n\nIn fact, you might already have a file like this in your project!\nFor example, running something like `vite init` might create a similar `vite-env.d.ts`.\n\nAs of TypeScript 6.0, this option defaults to `true`.",
1095
+ "markdownDescription": "In JavaScript it's possible to `import` a module without actually importing any values from it.\n\n```ts\nimport \"some-module\";\n```\n\nThese imports are often called *side effect imports* because the only useful behavior they can provide is by executing some side effect (like registering a global variable, or adding a polyfill to a prototype).\n\nBy default, TypeScript will not check these imports for validity. If the import resolves to a valid source file, TypeScript will load and check the file.\nIf no source file is found, TypeScript will silently ignore the import.\n\nThis is surprising behavior, but it partially stems from modeling patterns in the JavaScript ecosystem.\nFor example, this syntax has also been used with special loaders in bundlers to load CSS or other assets.\nYour bundler might be configured in such a way where you can include specific `.css` files by writing something like the following:\n\n```tsx\nimport \"./button-component.css\";\n\nexport function Button() {\n // ...\n}\n```\n\nStill, this masks potential typos on side effect imports.\n\nWhen `--noUncheckedSideEffectImports` is enabled, TypeScript will error if it can't find a source file for a side effect import.\n\n```ts\nimport \"oops-this-module-does-not-exist\";\n// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n// error: Cannot find module 'oops-this-module-does-not-exist' or its corresponding\n// type declarations.\n```\n\nWhen enabling this option, some working code may now receive an error, like in the CSS example above.\nTo work around this, users who want to just write side effect `import`s for assets might be better served by writing what's called an *ambient module declaration* with a wildcard specifier.\nIt would go in a global file and look something like the following:\n\n```ts\n// ./src/globals.d.ts\n\n// Recognize all CSS files as module imports.\ndeclare module \"*.css\" {}\n```\n\nIn fact, you might already have a file like this in your project!\nFor example, running something like `vite init` might create a similar `vite-env.d.ts`.\n\nAs of TypeScript 6.0, this option defaults to `true`.",
992
1096
  "type": [
993
1097
  "boolean",
994
1098
  "null"
995
- ]
1099
+ ],
1100
+ "x-intellij-html-description": "\u003cp\u003eIn JavaScript it\u0026#39;s possible to \u003ccode\u003eimport\u003c/code\u003e a module without actually importing any values from it.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eimport \u0026quot;some-module\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThese imports are often called \u003cem\u003eside effect imports\u003c/em\u003e because the only useful behavior they can provide is by executing some side effect (like registering a global variable, or adding a polyfill to a prototype).\u003c/p\u003e\n\u003cp\u003eBy default, TypeScript will not check these imports for validity. If the import resolves to a valid source file, TypeScript will load and check the file.\nIf no source file is found, TypeScript will silently ignore the import.\u003c/p\u003e\n\u003cp\u003eThis is surprising behavior, but it partially stems from modeling patterns in the JavaScript ecosystem.\nFor example, this syntax has also been used with special loaders in bundlers to load CSS or other assets.\nYour bundler might be configured in such a way where you can include specific \u003ccode\u003e.css\u003c/code\u003e files by writing something like the following:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-tsx\"\u003eimport \u0026quot;./button-component.css\u0026quot;;\n\nexport function Button() {\n // ...\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eStill, this masks potential typos on side effect imports.\u003c/p\u003e\n\u003cp\u003eWhen \u003ccode\u003e--noUncheckedSideEffectImports\u003c/code\u003e is enabled, TypeScript will error if it can\u0026#39;t find a source file for a side effect import.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eimport \u0026quot;oops-this-module-does-not-exist\u0026quot;;\n// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n// error: Cannot find module \u0026#39;oops-this-module-does-not-exist\u0026#39; or its corresponding\n// type declarations.\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhen enabling this option, some working code may now receive an error, like in the CSS example above.\nTo work around this, users who want to just write side effect \u003ccode\u003eimport\u003c/code\u003es for assets might be better served by writing what\u0026#39;s called an \u003cem\u003eambient module declaration\u003c/em\u003e with a wildcard specifier.\nIt would go in a global file and look something like the following:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// ./src/globals.d.ts\n\n// Recognize all CSS files as module imports.\ndeclare module \u0026quot;*.css\u0026quot; {}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eIn fact, you might already have a file like this in your project!\nFor example, running something like \u003ccode\u003evite init\u003c/code\u003e might create a similar \u003ccode\u003evite-env.d.ts\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eAs of TypeScript 6.0, this option defaults to \u003ccode\u003etrue\u003c/code\u003e.\u003c/p\u003e\n"
996
1101
  },
997
1102
  "noUnusedLocals": {
998
1103
  "default": false,
999
- "description": "Enable error reporting when local variables aren't read.",
1000
- "markdownDescription": "Enable error reporting when local variables aren't read.\n\nSee more: https://www.typescriptlang.org/tsconfig#noUnusedLocals",
1104
+ "description": "Report errors on unused local variables.\n\n```ts twoslash\n// @noUnusedLocals\n// @errors: 6133\nconst createKeyboard = (modelID: number) =\u003e {\n const defaultModelID = 23;\n return { type: \"keyboard\", modelID };\n};\n```",
1105
+ "markdownDescription": "Report errors on unused local variables.\n\n```ts twoslash\n// @noUnusedLocals\n// @errors: 6133\nconst createKeyboard = (modelID: number) =\u003e {\n const defaultModelID = 23;\n return { type: \"keyboard\", modelID };\n};\n```",
1001
1106
  "type": [
1002
1107
  "boolean",
1003
1108
  "null"
1004
- ]
1109
+ ],
1110
+ "x-intellij-html-description": "\u003cp\u003eReport errors on unused local variables.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @noUnusedLocals\n// @errors: 6133\nconst createKeyboard = (modelID: number) =\u0026gt; {\n const defaultModelID = 23;\n return { type: \u0026quot;keyboard\u0026quot;, modelID };\n};\n\u003c/code\u003e\u003c/pre\u003e\n"
1005
1111
  },
1006
1112
  "noUnusedParameters": {
1007
1113
  "default": false,
1008
- "description": "Raise an error when a function parameter isn't read.",
1009
- "markdownDescription": "Raise an error when a function parameter isn't read.\n\nSee more: https://www.typescriptlang.org/tsconfig#noUnusedParameters",
1114
+ "description": "Report errors on unused parameters in functions.\n\n```ts twoslash\n// @noUnusedParameters\n// @errors: 6133\nconst createDefaultKeyboard = (modelID: number) =\u003e {\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) =\u003e {\n return { type: \"keyboard\" };\n};\n```",
1115
+ "markdownDescription": "Report errors on unused parameters in functions.\n\n```ts twoslash\n// @noUnusedParameters\n// @errors: 6133\nconst createDefaultKeyboard = (modelID: number) =\u003e {\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) =\u003e {\n return { type: \"keyboard\" };\n};\n```",
1010
1116
  "type": [
1011
1117
  "boolean",
1012
1118
  "null"
1013
- ]
1119
+ ],
1120
+ "x-intellij-html-description": "\u003cp\u003eReport errors on unused parameters in functions.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @noUnusedParameters\n// @errors: 6133\nconst createDefaultKeyboard = (modelID: number) =\u0026gt; {\n const defaultModelID = 23;\n return { type: \u0026quot;keyboard\u0026quot;, modelID: defaultModelID };\n};\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eParameters declaration with names starting with an underscore (\u003ccode\u003e_\u003c/code\u003e) are exempt from the unused parameter checking. e.g.:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @noUnusedParameters\nconst createDefaultKeyboard = (_modelID: number) =\u0026gt; {\n return { type: \u0026quot;keyboard\u0026quot; };\n};\n\u003c/code\u003e\u003c/pre\u003e\n"
1014
1121
  },
1015
1122
  "out": {
1016
1123
  "description": "Deprecated setting. Use `outFile` instead.",
@@ -1021,25 +1128,27 @@
1021
1128
  ]
1022
1129
  },
1023
1130
  "outDir": {
1024
- "description": "Specify an output folder for all emitted files.",
1025
- "markdownDescription": "Specify an output folder for all emitted files.\n\nSee more: https://www.typescriptlang.org/tsconfig#outDir",
1131
+ "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```",
1132
+ "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```",
1026
1133
  "type": [
1027
1134
  "string",
1028
1135
  "null"
1029
- ]
1136
+ ],
1137
+ "x-intellij-html-description": "\u003cp\u003eIf specified, \u003ccode\u003e.js\u003c/code\u003e (as well as \u003ccode\u003e.d.ts\u003c/code\u003e, \u003ccode\u003e.js.map\u003c/code\u003e, etc.) files will be emitted into this directory.\nThe directory structure of the original source files is preserved; see \u003ca href=\"https://typescriptlang.org/tsconfig/#rootDir\"\u003e\u003ccode\u003erootDir\u003c/code\u003e\u003c/a\u003e if the computed root is not what you intended.\u003c/p\u003e\n\u003cp\u003eIf not specified, \u003ccode\u003e.js\u003c/code\u003e files will be emitted in the same directory as the \u003ccode\u003e.ts\u003c/code\u003e files they were generated from:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-sh\"\u003e$ tsc\n\nexample\n├── index.js\n└── index.ts\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith a \u003ccode\u003etsconfig.json\u003c/code\u003e like this:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;outDir\u0026quot;: \u0026quot;dist\u0026quot;\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eRunning \u003ccode\u003etsc\u003c/code\u003e with these settings moves the files into the specified \u003ccode\u003edist\u003c/code\u003e folder:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-sh\"\u003e$ tsc\n\nexample\n├── dist\n│ └── index.js\n├── index.ts\n└── tsconfig.json\n\u003c/code\u003e\u003c/pre\u003e\n"
1030
1138
  },
1031
1139
  "outFile": {
1032
- "description": "Specify a file that bundles all outputs into one JavaScript file. If `declaration` is true, also designates a file that bundles all .d.ts output.",
1033
- "markdownDescription": "Specify a file that bundles all outputs into one JavaScript file. If `declaration` is true, also designates a file that bundles all .d.ts output.\n\nSee more: https://www.typescriptlang.org/tsconfig#outFile",
1140
+ "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.",
1141
+ "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.",
1034
1142
  "type": [
1035
1143
  "string",
1036
1144
  "null"
1037
- ]
1145
+ ],
1146
+ "x-intellij-html-description": "\u003cp\u003eIf specified, all \u003cem\u003eglobal\u003c/em\u003e (non-module) files will be concatenated into the single output file specified.\u003c/p\u003e\n\u003cp\u003eIf \u003ccode\u003emodule\u003c/code\u003e is \u003ccode\u003esystem\u003c/code\u003e or \u003ccode\u003eamd\u003c/code\u003e, all module files will also be concatenated into this file after all global content.\u003c/p\u003e\n\u003cp\u003eNote: \u003ccode\u003eoutFile\u003c/code\u003e cannot be used unless \u003ccode\u003emodule\u003c/code\u003e is \u003ccode\u003eNone\u003c/code\u003e, \u003ccode\u003eSystem\u003c/code\u003e, or \u003ccode\u003eAMD\u003c/code\u003e.\nThis option \u003cem\u003ecannot\u003c/em\u003e be used to bundle CommonJS or ES6 modules.\u003c/p\u003e\n"
1038
1147
  },
1039
1148
  "paths": {
1040
1149
  "additionalProperties": {
1041
1150
  "items": {
1042
- "description": "Path mapping to be computed relative to baseUrl option.",
1151
+ "description": "An array of paths to use as alternatives when resolving this module import.",
1043
1152
  "type": "string"
1044
1153
  },
1045
1154
  "type": [
@@ -1048,15 +1157,16 @@
1048
1157
  ],
1049
1158
  "uniqueItems": true
1050
1159
  },
1051
- "description": "Specify a set of entries that re-map imports to additional lookup locations.",
1052
- "markdownDescription": "Specify a set of entries that re-map imports to additional lookup locations.\n\nSee more: https://www.typescriptlang.org/tsconfig#paths",
1160
+ "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.",
1161
+ "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.",
1053
1162
  "type": [
1054
1163
  "object",
1055
1164
  "null"
1056
- ]
1165
+ ],
1166
+ "x-intellij-html-description": "\u003cp\u003eA series of entries which re-map imports to lookup locations relative to the \u003ca href=\"https://typescriptlang.org/tsconfig/#baseUrl\"\u003e\u003ccode\u003ebaseUrl\u003c/code\u003e\u003c/a\u003e if set, or to the tsconfig file itself otherwise. There is a larger coverage of \u003ccode\u003epaths\u003c/code\u003e in \u003ca href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#paths\"\u003ethe \u003ccode\u003emoduleResolution\u003c/code\u003e reference page\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003epaths\u003c/code\u003e lets you declare how TypeScript should resolve an import in your \u003ccode\u003erequire\u003c/code\u003e/\u003ccode\u003eimport\u003c/code\u003es.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;paths\u0026quot;: {\n \u0026quot;jquery\u0026quot;: [\u0026quot;./vendor/jquery/dist/jquery\u0026quot;]\n }\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis would allow you to be able to write \u003ccode\u003eimport \u0026quot;jquery\u0026quot;\u003c/code\u003e, and get all of the correct typing locally.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;paths\u0026quot;: {\n \u0026quot;app/*\u0026quot;: [\u0026quot;./src/app/*\u0026quot;],\n \u0026quot;config/*\u0026quot;: [\u0026quot;./src/app/_config/*\u0026quot;],\n \u0026quot;environment/*\u0026quot;: [\u0026quot;./src/environments/*\u0026quot;],\n \u0026quot;shared/*\u0026quot;: [\u0026quot;./src/app/_shared/*\u0026quot;],\n \u0026quot;helpers/*\u0026quot;: [\u0026quot;./src/helpers/*\u0026quot;],\n \u0026quot;tests/*\u0026quot;: [\u0026quot;./src/tests/*\u0026quot;]\n }\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eIn this case, you can tell the TypeScript file resolver to support a number of custom prefixes to find code.\u003c/p\u003e\n\u003cp\u003eNote that this feature does not change how import paths are emitted by \u003ccode\u003etsc\u003c/code\u003e, so \u003ccode\u003epaths\u003c/code\u003e should only be used to inform TypeScript that another tool has this mapping and will use it at runtime or when bundling.\u003c/p\u003e\n"
1057
1167
  },
1058
1168
  "plugins": {
1059
- "description": "Specify a list of language service plugins to include.",
1169
+ "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) \u0026mdash; Adds SQL linting with a template strings SQL builder.\n- [typescript-styled-plugin](https://github.com/Microsoft/typescript-styled-plugin) \u0026mdash; Provides CSS linting inside template strings .\n- [typescript-eslint-language-service](https://github.com/Quramy/typescript-eslint-language-service) \u0026mdash; Provides eslint error messaging and fix-its inside the compiler's output.\n- [ts-graphql-plugin](https://github.com/Quramy/ts-graphql-plugin) \u0026mdash; 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`.",
1060
1170
  "items": {
1061
1171
  "anyOf": [
1062
1172
  {
@@ -1275,244 +1385,272 @@
1275
1385
  }
1276
1386
  ]
1277
1387
  },
1278
- "markdownDescription": "Specify a list of language service plugins to include.\n\nSee more: https://www.typescriptlang.org/tsconfig#plugins",
1388
+ "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) \u0026mdash; Adds SQL linting with a template strings SQL builder.\n- [typescript-styled-plugin](https://github.com/Microsoft/typescript-styled-plugin) \u0026mdash; Provides CSS linting inside template strings .\n- [typescript-eslint-language-service](https://github.com/Quramy/typescript-eslint-language-service) \u0026mdash; Provides eslint error messaging and fix-its inside the compiler's output.\n- [ts-graphql-plugin](https://github.com/Quramy/ts-graphql-plugin) \u0026mdash; 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`.",
1279
1389
  "type": [
1280
1390
  "array",
1281
1391
  "null"
1282
- ]
1392
+ ],
1393
+ "x-intellij-html-description": "\u003cp\u003eList of language service plugins to run inside the editor.\u003c/p\u003e\n\u003cp\u003eLanguage 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.\u003c/p\u003e\n\u003cp\u003eFor example:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/xialvjun/ts-sql-plugin#readme\"\u003ets-sql-plugin\u003c/a\u003e \u0026mdash; Adds SQL linting with a template strings SQL builder.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/Microsoft/typescript-styled-plugin\"\u003etypescript-styled-plugin\u003c/a\u003e \u0026mdash; Provides CSS linting inside template strings .\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/Quramy/typescript-eslint-language-service\"\u003etypescript-eslint-language-service\u003c/a\u003e \u0026mdash; Provides eslint error messaging and fix-its inside the compiler\u0026#39;s output.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/Quramy/ts-graphql-plugin\"\u003ets-graphql-plugin\u003c/a\u003e \u0026mdash; Provides validation and auto-completion inside GraphQL query template strings.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eVS Code has the ability for a extension to \u003ca href=\"https://code.visualstudio.com/api/references/contribution-points#contributes.typescriptServerPlugins\"\u003eautomatically include language service plugins\u003c/a\u003e, and so you may have some running in your editor without needing to define them in your \u003ccode\u003etsconfig.json\u003c/code\u003e.\u003c/p\u003e\n"
1283
1394
  },
1284
1395
  "preserveConstEnums": {
1285
1396
  "default": false,
1286
- "description": "Disable erasing `const enum` declarations in generated code.",
1287
- "markdownDescription": "Disable erasing `const enum` declarations in generated code.\n\nSee more: https://www.typescriptlang.org/tsconfig#preserveConstEnums",
1397
+ "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.",
1398
+ "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.",
1288
1399
  "type": [
1289
1400
  "boolean",
1290
1401
  "null"
1291
- ]
1402
+ ],
1403
+ "x-intellij-html-description": "\u003cp\u003eDo not erase \u003ccode\u003econst enum\u003c/code\u003e declarations in generated code. \u003ccode\u003econst enum\u003c/code\u003es provide a way to reduce the overall memory footprint\nof your application at runtime by emitting the enum value instead of a reference.\u003c/p\u003e\n\u003cp\u003eFor example with this TypeScript:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003econst enum Album {\n JimmyEatWorldFutures = 1,\n TubRingZooHypothesis = 2,\n DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n console.log(\u0026quot;That is a great choice.\u0026quot;);\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe default \u003ccode\u003econst enum\u003c/code\u003e behavior is to convert any \u003ccode\u003eAlbum.Something\u003c/code\u003e to the corresponding number literal, and to remove a reference\nto the enum from the JavaScript completely.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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(\u0026quot;That is a great choice.\u0026quot;);\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith \u003ccode\u003epreserveConstEnums\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e, the \u003ccode\u003eenum\u003c/code\u003e exists at runtime and the numbers are still emitted.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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(\u0026quot;That is a great choice.\u0026quot;);\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis essentially makes such \u003ccode\u003econst enums\u003c/code\u003e a source-code feature only, with no runtime traces.\u003c/p\u003e\n"
1292
1404
  },
1293
1405
  "preserveSymlinks": {
1294
1406
  "default": false,
1295
- "description": "Disable resolving symlinks to their realpath. This correlates to the same flag in node.",
1296
- "markdownDescription": "Disable resolving symlinks to their realpath. This correlates to the same flag in node.\n\nSee more: https://www.typescriptlang.org/tsconfig#preserveSymlinks",
1407
+ "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 `/// \u003creference type=\"...\" /\u003e` 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.",
1408
+ "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 `/// \u003creference type=\"...\" /\u003e` 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.",
1297
1409
  "type": [
1298
1410
  "boolean",
1299
1411
  "null"
1300
- ]
1412
+ ],
1413
+ "x-intellij-html-description": "\u003cp\u003eThis is to reflect the same flag in Node.js; which does not resolve the real path of symlinks.\u003c/p\u003e\n\u003cp\u003eThis flag also exhibits the opposite behavior to Webpack’s \u003ccode\u003eresolve.symlinks\u003c/code\u003e option (i.e. setting TypeScript’s \u003ccode\u003epreserveSymlinks\u003c/code\u003e to true parallels setting Webpack’s \u003ccode\u003eresolve.symlinks\u003c/code\u003e to false, and vice-versa).\u003c/p\u003e\n\u003cp\u003eWith this enabled, references to modules and packages (e.g. \u003ccode\u003eimport\u003c/code\u003es and \u003ccode\u003e/// \u0026lt;reference type=\u0026quot;...\u0026quot; /\u0026gt;\u003c/code\u003e 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.\u003c/p\u003e\n"
1301
1414
  },
1302
1415
  "preserveValueImports": {
1303
1416
  "default": false,
1304
- "description": "Preserve unused imported values in the JavaScript output that would otherwise be removed.",
1305
- "markdownDescription": "Preserve unused imported values in the JavaScript output that would otherwise be removed.\n\nSee more: https://www.typescriptlang.org/tsconfig#preserveValueImports",
1417
+ "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.",
1418
+ "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.",
1306
1419
  "type": [
1307
1420
  "boolean",
1308
1421
  "null"
1309
- ]
1422
+ ],
1423
+ "x-intellij-html-description": "\u003cp\u003eDeprecated in favor of \u003ca href=\"https://typescriptlang.org/tsconfig/#verbatimModuleSyntax\"\u003e\u003ccode\u003everbatimModuleSyntax\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eThere are some cases where TypeScript can\u0026#39;t detect that you\u0026#39;re using an import. For example, take the following code:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eimport { Animal } from \u0026quot;./animal.js\u0026quot;;\n\neval(\u0026quot;console.log(new Animal().isDangerous())\u0026quot;);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eor code using \u0026#39;Compiles to HTML\u0026#39; languages like Svelte or Vue. \u003ccode\u003epreserveValueImports\u003c/code\u003e will prevent TypeScript from removing the import, even if it appears unused.\u003c/p\u003e\n\u003cp\u003eWhen combined with \u003ca href=\"https://typescriptlang.org/tsconfig/#isolatedModules\"\u003e\u003ccode\u003eisolatedModules\u003c/code\u003e\u003c/a\u003e: imported types \u003cem\u003emust\u003c/em\u003e 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.\u003c/p\u003e\n"
1310
1424
  },
1311
1425
  "preserveWatchOutput": {
1312
- "description": "Disable wiping the console in watch mode.",
1313
- "markdownDescription": "Disable wiping the console in watch mode.\n\nSee more: https://www.typescriptlang.org/tsconfig#preserveWatchOutput",
1426
+ "description": "Whether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.",
1427
+ "markdownDescription": "Whether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.",
1314
1428
  "type": [
1315
1429
  "boolean",
1316
1430
  "null"
1317
- ]
1431
+ ],
1432
+ "x-intellij-html-description": "\u003cp\u003eWhether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.\u003c/p\u003e\n"
1318
1433
  },
1319
1434
  "pretty": {
1320
1435
  "default": true,
1321
- "description": "Enable color and formatting in TypeScript's output to make compiler errors easier to read.",
1322
- "markdownDescription": "Enable color and formatting in TypeScript's output to make compiler errors easier to read.\n\nSee more: https://www.typescriptlang.org/tsconfig#pretty",
1436
+ "description": "Stylize errors and messages using color and context, this is on by default \u0026mdash; offers you a chance to have less terse,\nsingle colored messages from the compiler.",
1437
+ "markdownDescription": "Stylize errors and messages using color and context, this is on by default \u0026mdash; offers you a chance to have less terse,\nsingle colored messages from the compiler.",
1323
1438
  "type": [
1324
1439
  "boolean",
1325
1440
  "null"
1326
- ]
1441
+ ],
1442
+ "x-intellij-html-description": "\u003cp\u003eStylize errors and messages using color and context, this is on by default \u0026mdash; offers you a chance to have less terse,\nsingle colored messages from the compiler.\u003c/p\u003e\n"
1327
1443
  },
1328
1444
  "reactNamespace": {
1329
1445
  "default": "React",
1330
- "description": "Specify the object invoked for `createElement`. This only applies when targeting `react` JSX emit.",
1331
- "markdownDescription": "Specify the object invoked for `createElement`. This only applies when targeting `react` JSX emit.\n\nSee more: https://www.typescriptlang.org/tsconfig#reactNamespace",
1446
+ "description": "Use [`jsxFactory`](https://typescriptlang.org/tsconfig/#jsxFactory) instead. Specify the object invoked for `createElement` when targeting `react` for TSX files.",
1447
+ "markdownDescription": "Use [`jsxFactory`](https://typescriptlang.org/tsconfig/#jsxFactory) instead. Specify the object invoked for `createElement` when targeting `react` for TSX files.",
1332
1448
  "type": [
1333
1449
  "string",
1334
1450
  "null"
1335
- ]
1451
+ ],
1452
+ "x-intellij-html-description": "\u003cp\u003eUse \u003ca href=\"https://typescriptlang.org/tsconfig/#jsxFactory\"\u003e\u003ccode\u003ejsxFactory\u003c/code\u003e\u003c/a\u003e instead. Specify the object invoked for \u003ccode\u003ecreateElement\u003c/code\u003e when targeting \u003ccode\u003ereact\u003c/code\u003e for TSX files.\u003c/p\u003e\n"
1336
1453
  },
1337
1454
  "removeComments": {
1338
1455
  "default": false,
1339
- "description": "Disable emitting comments.",
1340
- "markdownDescription": "Disable emitting comments.\n\nSee more: https://www.typescriptlang.org/tsconfig#removeComments",
1456
+ "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.",
1457
+ "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.",
1341
1458
  "type": [
1342
1459
  "boolean",
1343
1460
  "null"
1344
- ]
1461
+ ],
1462
+ "x-intellij-html-description": "\u003cp\u003eStrips all comments from TypeScript files when converting into JavaScript. Defaults to \u003ccode\u003efalse\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eFor example, this is a TypeScript file which has a JSDoc comment:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e/** The translation of \u0026#39;Hello world\u0026#39; into Portuguese */\nexport const helloWorldPTBR = \u0026quot;Olá Mundo\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhen \u003ccode\u003eremoveComments\u003c/code\u003e is set to \u003ccode\u003etrue\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @removeComments: true\n/** The translation of \u0026#39;Hello world\u0026#39; into Portuguese */\nexport const helloWorldPTBR = \u0026quot;Olá Mundo\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWithout setting \u003ccode\u003eremoveComments\u003c/code\u003e or having it as \u003ccode\u003efalse\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @showEmit\n// @removeComments: false\n/** The translation of \u0026#39;Hello world\u0026#39; into Portuguese */\nexport const helloWorldPTBR = \u0026quot;Olá Mundo\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis means that your comments will show up in the JavaScript code.\u003c/p\u003e\n"
1345
1463
  },
1346
1464
  "resolveJsonModule": {
1347
1465
  "default": false,
1348
- "description": "Enable importing .json files.",
1349
- "markdownDescription": "Enable importing .json files.\n\nSee more: https://www.typescriptlang.org/tsconfig#resolveJsonModule",
1466
+ "description": "Allows importing modules with a `.json` extension, which is a common practice in node projects. This includes\ngenerating a type for the `import` based on the static JSON shape.\n\nTypeScript does not support resolving JSON files by default:\n\n```ts twoslash\n// @errors: 2732\n// @filename: settings.json\n{\n \"repo\": \"TypeScript\",\n \"dry\": false,\n \"debug\": false\n}\n// @filename: index.ts\nimport settings from \"./settings.json\";\n\nsettings.debug === true;\nsettings.dry === 2;\n```\n\nEnabling the option allows importing JSON, and validating the types in that JSON file.\n\n```ts twoslash\n// @errors: 2367\n// @resolveJsonModule\n// @module: commonjs\n// @moduleResolution: node\n// @filename: settings.json\n{\n \"repo\": \"TypeScript\",\n \"dry\": false,\n \"debug\": false\n}\n// @filename: index.ts\nimport settings from \"./settings.json\";\n\nsettings.debug === true;\nsettings.dry === 2;\n```",
1467
+ "markdownDescription": "Allows importing modules with a `.json` extension, which is a common practice in node projects. This includes\ngenerating a type for the `import` based on the static JSON shape.\n\nTypeScript does not support resolving JSON files by default:\n\n```ts twoslash\n// @errors: 2732\n// @filename: settings.json\n{\n \"repo\": \"TypeScript\",\n \"dry\": false,\n \"debug\": false\n}\n// @filename: index.ts\nimport settings from \"./settings.json\";\n\nsettings.debug === true;\nsettings.dry === 2;\n```\n\nEnabling the option allows importing JSON, and validating the types in that JSON file.\n\n```ts twoslash\n// @errors: 2367\n// @resolveJsonModule\n// @module: commonjs\n// @moduleResolution: node\n// @filename: settings.json\n{\n \"repo\": \"TypeScript\",\n \"dry\": false,\n \"debug\": false\n}\n// @filename: index.ts\nimport settings from \"./settings.json\";\n\nsettings.debug === true;\nsettings.dry === 2;\n```",
1350
1468
  "type": [
1351
1469
  "boolean",
1352
1470
  "null"
1353
- ]
1471
+ ],
1472
+ "x-intellij-html-description": "\u003cp\u003eAllows importing modules with a \u003ccode\u003e.json\u003c/code\u003e extension, which is a common practice in node projects. This includes\ngenerating a type for the \u003ccode\u003eimport\u003c/code\u003e based on the static JSON shape.\u003c/p\u003e\n\u003cp\u003eTypeScript does not support resolving JSON files by default:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 2732\n// @filename: settings.json\n{\n \u0026quot;repo\u0026quot;: \u0026quot;TypeScript\u0026quot;,\n \u0026quot;dry\u0026quot;: false,\n \u0026quot;debug\u0026quot;: false\n}\n// @filename: index.ts\nimport settings from \u0026quot;./settings.json\u0026quot;;\n\nsettings.debug === true;\nsettings.dry === 2;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEnabling the option allows importing JSON, and validating the types in that JSON file.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 2367\n// @resolveJsonModule\n// @module: commonjs\n// @moduleResolution: node\n// @filename: settings.json\n{\n \u0026quot;repo\u0026quot;: \u0026quot;TypeScript\u0026quot;,\n \u0026quot;dry\u0026quot;: false,\n \u0026quot;debug\u0026quot;: false\n}\n// @filename: index.ts\nimport settings from \u0026quot;./settings.json\u0026quot;;\n\nsettings.debug === true;\nsettings.dry === 2;\n\u003c/code\u003e\u003c/pre\u003e\n"
1354
1473
  },
1355
1474
  "resolvePackageJsonExports": {
1356
1475
  "default": false,
1357
- "description": "Use the package.json 'exports' field when resolving package imports.",
1358
- "markdownDescription": "Use the package.json 'exports' field when resolving package imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#resolvePackageJsonExports",
1476
+ "description": "`--resolvePackageJsonExports` forces TypeScript to consult [the `exports` field of `package.json` files](https://nodejs.org/api/packages.html#exports) if it ever reads from a package in `node_modules`.\n\nThis option defaults to `true` under the `node16`, `nodenext`, and `bundler` options for [`--moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution).",
1477
+ "markdownDescription": "`--resolvePackageJsonExports` forces TypeScript to consult [the `exports` field of `package.json` files](https://nodejs.org/api/packages.html#exports) if it ever reads from a package in `node_modules`.\n\nThis option defaults to `true` under the `node16`, `nodenext`, and `bundler` options for [`--moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution).",
1359
1478
  "type": [
1360
1479
  "boolean",
1361
1480
  "null"
1362
- ]
1481
+ ],
1482
+ "x-intellij-html-description": "\u003cp\u003e\u003ccode\u003e--resolvePackageJsonExports\u003c/code\u003e forces TypeScript to consult \u003ca href=\"https://nodejs.org/api/packages.html#exports\"\u003ethe \u003ccode\u003eexports\u003c/code\u003e field of \u003ccode\u003epackage.json\u003c/code\u003e files\u003c/a\u003e if it ever reads from a package in \u003ccode\u003enode_modules\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThis option defaults to \u003ccode\u003etrue\u003c/code\u003e under the \u003ccode\u003enode16\u003c/code\u003e, \u003ccode\u003enodenext\u003c/code\u003e, and \u003ccode\u003ebundler\u003c/code\u003e options for \u003ca href=\"https://typescriptlang.org/tsconfig/#moduleResolution\"\u003e\u003ccode\u003e--moduleResolution\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n"
1363
1483
  },
1364
1484
  "resolvePackageJsonImports": {
1365
1485
  "default": false,
1366
- "description": "Use the package.json 'imports' field when resolving imports.",
1367
- "markdownDescription": "Use the package.json 'imports' field when resolving imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#resolvePackageJsonImports",
1486
+ "description": "`--resolvePackageJsonImports` forces TypeScript to consult [the `imports` field of `package.json` files](https://nodejs.org/api/packages.html#imports) when performing a lookup that starts with `#` from a file whose ancestor directory contains a `package.json`.\n\nThis option defaults to `true` under the `node16`, `nodenext`, and `bundler` options for [`--moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution).",
1487
+ "markdownDescription": "`--resolvePackageJsonImports` forces TypeScript to consult [the `imports` field of `package.json` files](https://nodejs.org/api/packages.html#imports) when performing a lookup that starts with `#` from a file whose ancestor directory contains a `package.json`.\n\nThis option defaults to `true` under the `node16`, `nodenext`, and `bundler` options for [`--moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution).",
1368
1488
  "type": [
1369
1489
  "boolean",
1370
1490
  "null"
1371
- ]
1491
+ ],
1492
+ "x-intellij-html-description": "\u003cp\u003e\u003ccode\u003e--resolvePackageJsonImports\u003c/code\u003e forces TypeScript to consult \u003ca href=\"https://nodejs.org/api/packages.html#imports\"\u003ethe \u003ccode\u003eimports\u003c/code\u003e field of \u003ccode\u003epackage.json\u003c/code\u003e files\u003c/a\u003e when performing a lookup that starts with \u003ccode\u003e#\u003c/code\u003e from a file whose ancestor directory contains a \u003ccode\u003epackage.json\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eThis option defaults to \u003ccode\u003etrue\u003c/code\u003e under the \u003ccode\u003enode16\u003c/code\u003e, \u003ccode\u003enodenext\u003c/code\u003e, and \u003ccode\u003ebundler\u003c/code\u003e options for \u003ca href=\"https://typescriptlang.org/tsconfig/#moduleResolution\"\u003e\u003ccode\u003e--moduleResolution\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n"
1372
1493
  },
1373
1494
  "rewriteRelativeImportExtensions": {
1374
1495
  "default": false,
1375
- "description": "Rewrite `.ts`, `.tsx`, `.mts`, and `.cts` file extensions in relative import paths to their JavaScript equivalent in output files.",
1376
- "markdownDescription": "Rewrite `.ts`, `.tsx`, `.mts`, and `.cts` file extensions in relative import paths to their JavaScript equivalent in output files.\n\nSee more: https://www.typescriptlang.org/tsconfig#rewriteRelativeImportExtensions",
1496
+ "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).",
1497
+ "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).",
1377
1498
  "type": [
1378
1499
  "boolean",
1379
1500
  "null"
1380
- ]
1501
+ ],
1502
+ "x-intellij-html-description": "\u003cp\u003eRewrite \u003ccode\u003e.ts\u003c/code\u003e, \u003ccode\u003e.tsx\u003c/code\u003e, \u003ccode\u003e.mts\u003c/code\u003e, and \u003ccode\u003e.cts\u003c/code\u003e file extensions in relative import paths to their JavaScript equivalent in output files.\u003c/p\u003e\n\u003cp\u003eFor more information, see the \u003ca href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-5-7.html#path-rewriting-for-relative-paths\"\u003eTypeScript 5.7 release notes\u003c/a\u003e.\u003c/p\u003e\n"
1381
1503
  },
1382
1504
  "rootDir": {
1383
- "description": "Specify the root folder within your source files.",
1384
- "markdownDescription": "Specify the root folder within your source files.\n\nSee more: https://www.typescriptlang.org/tsconfig#rootDir",
1505
+ "default": ".",
1506
+ "description": "**Default**: 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`).",
1507
+ "markdownDescription": "**Default**: 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`).",
1385
1508
  "type": [
1386
1509
  "string",
1387
1510
  "null"
1388
- ]
1511
+ ],
1512
+ "x-intellij-html-description": "\u003cp\u003e\u003cstrong\u003eDefault\u003c/strong\u003e: The directory containing the \u003ccode\u003etsconfig.json\u003c/code\u003e file.\u003c/p\u003e\n\u003cp\u003eWhen TypeScript compiles files, it keeps the same directory structure in the output directory as exists in the input directory.\u003c/p\u003e\n\u003cp\u003eFor example, let\u0026#39;s say you have some input files:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eMyProj\n├── tsconfig.json\n├── core\n│ ├── a.ts\n│ ├── b.ts\n│ ├── sub\n│ │ ├── c.ts\n├── types.d.ts\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe inferred value for \u003ccode\u003erootDir\u003c/code\u003e is the longest common path of all non-declaration input files, which in this case is \u003ccode\u003ecore/\u003c/code\u003e.\u003c/p\u003e\n\u003cp\u003eIf your \u003ca href=\"https://typescriptlang.org/tsconfig/#outDir\"\u003e\u003ccode\u003eoutDir\u003c/code\u003e\u003c/a\u003e was \u003ccode\u003edist\u003c/code\u003e, TypeScript would write this tree:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eMyProj\n├── dist\n│ ├── a.js\n│ ├── b.js\n│ ├── sub\n│ │ ├── c.js\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eHowever, you may have intended for \u003ccode\u003ecore\u003c/code\u003e to be part of the output directory structure.\nBy setting \u003ccode\u003erootDir: \u0026quot;.\u0026quot;\u003c/code\u003e in \u003ccode\u003etsconfig.json\u003c/code\u003e, TypeScript would write this tree:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eMyProj\n├── dist\n│ ├── core\n│ │ ├── a.js\n│ │ ├── b.js\n│ │ ├── sub\n│ │ │ ├── c.js\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eImportantly, \u003ccode\u003erootDir\u003c/code\u003e \u003cstrong\u003edoes not affect which files become part of the compilation\u003c/strong\u003e.\nIt has no interaction with the \u003ca href=\"https://typescriptlang.org/tsconfig/#include\"\u003e\u003ccode\u003einclude\u003c/code\u003e\u003c/a\u003e, \u003ca href=\"https://typescriptlang.org/tsconfig/#exclude\"\u003e\u003ccode\u003eexclude\u003c/code\u003e\u003c/a\u003e, or \u003ca href=\"https://typescriptlang.org/tsconfig/#files\"\u003e\u003ccode\u003efiles\u003c/code\u003e\u003c/a\u003e \u003ccode\u003etsconfig.json\u003c/code\u003e settings.\u003c/p\u003e\n\u003cp\u003eNote that TypeScript will never write an output file to a directory outside of \u003ca href=\"https://typescriptlang.org/tsconfig/#outDir\"\u003e\u003ccode\u003eoutDir\u003c/code\u003e\u003c/a\u003e, and will never skip emitting a file.\nFor this reason, \u003ccode\u003erootDir\u003c/code\u003e also enforces that all files which need to be emitted are underneath the \u003ccode\u003erootDir\u003c/code\u003e path.\u003c/p\u003e\n\u003cp\u003eFor example, let\u0026#39;s say you had this tree:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003eMyProj\n├── tsconfig.json\n├── core\n│ ├── a.ts\n│ ├── b.ts\n├── helpers.ts\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eIt would be an error to specify \u003ccode\u003erootDir\u003c/code\u003e as \u003ccode\u003ecore\u003c/code\u003e \u003cem\u003eand\u003c/em\u003e \u003ca href=\"https://typescriptlang.org/tsconfig/#include\"\u003e\u003ccode\u003einclude\u003c/code\u003e\u003c/a\u003e as \u003ccode\u003e*\u003c/code\u003e because it creates a file (\u003ccode\u003ehelpers.ts\u003c/code\u003e) that would need to be emitted \u003cem\u003eoutside\u003c/em\u003e the \u003ca href=\"https://typescriptlang.org/tsconfig/#outDir\"\u003e\u003ccode\u003eoutDir\u003c/code\u003e\u003c/a\u003e (i.e. \u003ccode\u003e../helpers.js\u003c/code\u003e).\u003c/p\u003e\n"
1389
1513
  },
1390
1514
  "rootDirs": {
1391
- "description": "Allow multiple folders to be treated as one when resolving modules.",
1515
+ "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```",
1392
1516
  "items": {
1393
1517
  "type": "string"
1394
1518
  },
1395
- "markdownDescription": "Allow multiple folders to be treated as one when resolving modules.\n\nSee more: https://www.typescriptlang.org/tsconfig#rootDirs",
1519
+ "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```",
1396
1520
  "type": [
1397
1521
  "array",
1398
1522
  "null"
1399
1523
  ],
1400
- "uniqueItems": true
1524
+ "uniqueItems": true,
1525
+ "x-intellij-html-description": "\u003cp\u003eUsing \u003ccode\u003erootDirs\u003c/code\u003e, you can inform the compiler that there are many \u0026quot;virtual\u0026quot; directories acting as a single root.\nThis allows the compiler to resolve relative module imports within these \u0026quot;virtual\u0026quot; directories, as if they were merged in to one directory.\u003c/p\u003e\n\u003cp\u003eFor example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e src\n └── views\n └── view1.ts (can import \u0026quot;./template1\u0026quot;, \u0026quot;./view2`)\n └── view2.ts (can import \u0026quot;./template1\u0026quot;, \u0026quot;./view1`)\n\n generated\n └── templates\n └── views\n └── template1.ts (can import \u0026quot;./view1\u0026quot;, \u0026quot;./view2\u0026quot;)\n\u003c/code\u003e\u003c/pre\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;rootDirs\u0026quot;: [\u0026quot;src/views\u0026quot;, \u0026quot;generated/templates/views\u0026quot;]\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis 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.\u003c/p\u003e\n\u003cp\u003e\u003ccode\u003erootDirs\u003c/code\u003e can be used to provide a separate \u0026quot;type layer\u0026quot; to files that are not TypeScript or JavaScript by providing a home for generated \u003ccode\u003e.d.ts\u003c/code\u003e files in another folder. This technique is useful for bundled applications where you use \u003ccode\u003eimport\u003c/code\u003e of files that aren\u0026#39;t necessarily code:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-sh\"\u003e 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\u003c/code\u003e\u003c/pre\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;rootDirs\u0026quot;: [\u0026quot;src\u0026quot;, \u0026quot;generated\u0026quot;]\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis technique lets you generate types ahead of time for the non-code source files. Imports then work naturally based off the source file\u0026#39;s location.\nFor example \u003ccode\u003e./src/index.ts\u003c/code\u003e can import the file \u003ccode\u003e./src/css/main.css\u003c/code\u003e and TypeScript will be aware of the bundler\u0026#39;s behavior for that filetype via the corresponding generated declaration file.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @filename: main.css.d.ts\nexport const appClass = \u0026quot;mainClassF3EC2\u0026quot;;\n// ---cut---\n// @filename: index.ts\nimport { appClass } from \u0026quot;./main.css\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n"
1401
1526
  },
1402
1527
  "skipDefaultLibCheck": {
1403
1528
  "default": false,
1404
- "description": "Skip type checking .d.ts files that are included with TypeScript.",
1405
- "markdownDescription": "Skip type checking .d.ts files that are included with TypeScript.\n\nSee more: https://www.typescriptlang.org/tsconfig#skipDefaultLibCheck",
1529
+ "description": "Use [`skipLibCheck`](https://typescriptlang.org/tsconfig/#skipLibCheck) instead. Skip type checking of default library declaration files.",
1530
+ "markdownDescription": "Use [`skipLibCheck`](https://typescriptlang.org/tsconfig/#skipLibCheck) instead. Skip type checking of default library declaration files.",
1406
1531
  "type": [
1407
1532
  "boolean",
1408
1533
  "null"
1409
- ]
1534
+ ],
1535
+ "x-intellij-html-description": "\u003cp\u003eUse \u003ca href=\"https://typescriptlang.org/tsconfig/#skipLibCheck\"\u003e\u003ccode\u003eskipLibCheck\u003c/code\u003e\u003c/a\u003e instead. Skip type checking of default library declaration files.\u003c/p\u003e\n"
1410
1536
  },
1411
1537
  "skipLibCheck": {
1412
1538
  "default": false,
1413
- "description": "Skip type checking all .d.ts files.",
1414
- "markdownDescription": "Skip type checking all .d.ts files.\n\nSee more: https://www.typescriptlang.org/tsconfig#skipLibCheck",
1539
+ "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.",
1540
+ "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.",
1415
1541
  "type": [
1416
1542
  "boolean",
1417
1543
  "null"
1418
- ]
1544
+ ],
1545
+ "x-intellij-html-description": "\u003cp\u003eSkip type checking of declaration files.\u003c/p\u003e\n\u003cp\u003eThis can save time during compilation at the expense of type-system accuracy. For example, two libraries could\ndefine two copies of the same \u003ccode\u003etype\u003c/code\u003e in an inconsistent way. Rather than doing a full check of all \u003ccode\u003ed.ts\u003c/code\u003e files, TypeScript\nwill type check the code you specifically refer to in your app\u0026#39;s source code.\u003c/p\u003e\n\u003cp\u003eA common case where you might think to use \u003ccode\u003eskipLibCheck\u003c/code\u003e is when there are two copies of a library\u0026#39;s types in\nyour \u003ccode\u003enode_modules\u003c/code\u003e. In these cases, you should consider using a feature like \u003ca href=\"https://yarnpkg.com/lang/en/docs/selective-version-resolutions/\"\u003eyarn\u0026#39;s resolutions\u003c/a\u003e\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.\u003c/p\u003e\n\u003cp\u003eAnother 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. \u003c/p\u003e\n\u003cp\u003eNote, that if these issues come from the TypeScript standard library you can replace the library using \u003ca href=\"https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#supporting-lib-from-node_modules\"\u003eTypeScript 4.5\u0026#39;s lib replacement\u003c/a\u003e technique.\u003c/p\u003e\n"
1419
1546
  },
1420
1547
  "sourceMap": {
1421
1548
  "default": false,
1422
- "description": "Create source map files for emitted JavaScript files.",
1423
- "markdownDescription": "Create source map files for emitted JavaScript files.\n\nSee more: https://www.typescriptlang.org/tsconfig#sourceMap",
1549
+ "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```",
1550
+ "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```",
1424
1551
  "type": [
1425
1552
  "boolean",
1426
1553
  "null"
1427
- ]
1554
+ ],
1555
+ "x-intellij-html-description": "\u003cp\u003eEnables the generation of \u003ca href=\"https://developer.mozilla.org/docs/Tools/Debugger/How_to/Use_a_source_map\"\u003esourcemap files\u003c/a\u003e.\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 \u003ccode\u003e.js.map\u003c/code\u003e (or \u003ccode\u003e.jsx.map\u003c/code\u003e) files next to the corresponding \u003ccode\u003e.js\u003c/code\u003e output file.\u003c/p\u003e\n\u003cp\u003eThe \u003ccode\u003e.js\u003c/code\u003e files will in turn contain a sourcemap comment to indicate where the files are to external tools, for example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// helloWorld.ts\nexport declare const helloWorld = \u0026quot;hi\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eCompiling with \u003ccode\u003esourceMap\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e creates the following JavaScript file:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-js\"\u003e// helloWorld.js\n\u0026quot;use strict\u0026quot;;\nObject.defineProperty(exports, \u0026quot;__esModule\u0026quot;, { value: true });\nexports.helloWorld = \u0026quot;hi\u0026quot;;\n//# sourceMappingURL=// helloWorld.js.map\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eAnd this also generates this json map:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e// helloWorld.js.map\n{\n \u0026quot;version\u0026quot;: 3,\n \u0026quot;file\u0026quot;: \u0026quot;ex.js\u0026quot;,\n \u0026quot;sourceRoot\u0026quot;: \u0026quot;\u0026quot;,\n \u0026quot;sources\u0026quot;: [\u0026quot;../ex.ts\u0026quot;],\n \u0026quot;names\u0026quot;: [],\n \u0026quot;mappings\u0026quot;: \u0026quot;;;AAAa,QAAA,UAAU,GAAG,IAAI,CAAA\u0026quot;\n}\n\u003c/code\u003e\u003c/pre\u003e\n"
1428
1556
  },
1429
1557
  "sourceRoot": {
1430
- "description": "Specify the root path for debuggers to find the reference source code.",
1431
- "markdownDescription": "Specify the root path for debuggers to find the reference source code.\n\nSee more: https://www.typescriptlang.org/tsconfig#sourceRoot",
1558
+ "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`.",
1559
+ "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`.",
1432
1560
  "type": [
1433
1561
  "string",
1434
1562
  "null"
1435
- ]
1563
+ ],
1564
+ "x-intellij-html-description": "\u003cp\u003eSpecify 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:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;sourceMap\u0026quot;: true,\n \u0026quot;sourceRoot\u0026quot;: \u0026quot;https://my-website.com/debug/source/\u0026quot;\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWould declare that \u003ccode\u003eindex.js\u003c/code\u003e will have a source file at \u003ccode\u003ehttps://my-website.com/debug/source/index.ts\u003c/code\u003e.\u003c/p\u003e\n"
1436
1565
  },
1437
1566
  "strict": {
1438
- "default": false,
1439
- "description": "Enable all strict type-checking options.",
1440
- "markdownDescription": "Enable all strict type-checking options.\n\nSee more: https://www.typescriptlang.org/tsconfig#strict",
1567
+ "default": true,
1568
+ "description": "The `strict` flag enables a wide range of type checking behavior that results in stronger guarantees of program correctness.\nTurning this on is equivalent to enabling all of the _strict mode family_ options, which are outlined below.\nYou can then turn off individual strict mode family checks as needed.\n\nFuture versions of TypeScript may introduce additional stricter checking under this flag, so upgrades of TypeScript might result in new type errors in your program.\nWhen appropriate and possible, a corresponding flag will be added to disable that behavior.\n\nAs of TypeScript 6.0, `strict` defaults to `true`.",
1569
+ "markdownDescription": "The `strict` flag enables a wide range of type checking behavior that results in stronger guarantees of program correctness.\nTurning this on is equivalent to enabling all of the _strict mode family_ options, which are outlined below.\nYou can then turn off individual strict mode family checks as needed.\n\nFuture versions of TypeScript may introduce additional stricter checking under this flag, so upgrades of TypeScript might result in new type errors in your program.\nWhen appropriate and possible, a corresponding flag will be added to disable that behavior.\n\nAs of TypeScript 6.0, `strict` defaults to `true`.",
1441
1570
  "type": [
1442
1571
  "boolean",
1443
1572
  "null"
1444
- ]
1573
+ ],
1574
+ "x-intellij-html-description": "\u003cp\u003eThe \u003ccode\u003estrict\u003c/code\u003e flag enables a wide range of type checking behavior that results in stronger guarantees of program correctness.\nTurning this on is equivalent to enabling all of the \u003cem\u003estrict mode family\u003c/em\u003e options, which are outlined below.\nYou can then turn off individual strict mode family checks as needed.\u003c/p\u003e\n\u003cp\u003eFuture versions of TypeScript may introduce additional stricter checking under this flag, so upgrades of TypeScript might result in new type errors in your program.\nWhen appropriate and possible, a corresponding flag will be added to disable that behavior.\u003c/p\u003e\n\u003cp\u003eAs of TypeScript 6.0, \u003ccode\u003estrict\u003c/code\u003e defaults to \u003ccode\u003etrue\u003c/code\u003e.\u003c/p\u003e\n"
1445
1575
  },
1446
1576
  "strictBindCallApply": {
1447
1577
  "default": false,
1448
- "description": "Check that the arguments for `bind`, `call`, and `apply` methods match the original function.",
1449
- "markdownDescription": "Check that the arguments for `bind`, `call`, and `apply` methods match the original function.\n\nSee more: https://www.typescriptlang.org/tsconfig#strictBindCallApply",
1578
+ "description": "When set, TypeScript will check that the built-in methods of functions `call`, `bind`, and `apply` are invoked with correct argument for the underlying function:\n\n```ts twoslash\n// @strictBindCallApply: true\n// @errors: 2345\n\n// With strictBindCallApply on\nfunction fn(x: string) {\n return parseInt(x);\n}\n\nconst n1 = fn.call(undefined, \"10\");\n\nconst n2 = fn.call(undefined, false);\n```\n\nOtherwise, these functions accept any arguments and will return `any`:\n\n```ts twoslash\n// @strictBindCallApply: false\n\n// With strictBindCallApply off\nfunction fn(x: string) {\n return parseInt(x);\n}\n\n// Note: No error; return type is 'any'\nconst n = fn.call(undefined, false);\n```",
1579
+ "markdownDescription": "When set, TypeScript will check that the built-in methods of functions `call`, `bind`, and `apply` are invoked with correct argument for the underlying function:\n\n```ts twoslash\n// @strictBindCallApply: true\n// @errors: 2345\n\n// With strictBindCallApply on\nfunction fn(x: string) {\n return parseInt(x);\n}\n\nconst n1 = fn.call(undefined, \"10\");\n\nconst n2 = fn.call(undefined, false);\n```\n\nOtherwise, these functions accept any arguments and will return `any`:\n\n```ts twoslash\n// @strictBindCallApply: false\n\n// With strictBindCallApply off\nfunction fn(x: string) {\n return parseInt(x);\n}\n\n// Note: No error; return type is 'any'\nconst n = fn.call(undefined, false);\n```",
1450
1580
  "type": [
1451
1581
  "boolean",
1452
1582
  "null"
1453
- ]
1583
+ ],
1584
+ "x-intellij-html-description": "\u003cp\u003eWhen set, TypeScript will check that the built-in methods of functions \u003ccode\u003ecall\u003c/code\u003e, \u003ccode\u003ebind\u003c/code\u003e, and \u003ccode\u003eapply\u003c/code\u003e are invoked with correct argument for the underlying function:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @strictBindCallApply: true\n// @errors: 2345\n\n// With strictBindCallApply on\nfunction fn(x: string) {\n return parseInt(x);\n}\n\nconst n1 = fn.call(undefined, \u0026quot;10\u0026quot;);\n\nconst n2 = fn.call(undefined, false);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eOtherwise, these functions accept any arguments and will return \u003ccode\u003eany\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @strictBindCallApply: false\n\n// With strictBindCallApply off\nfunction fn(x: string) {\n return parseInt(x);\n}\n\n// Note: No error; return type is \u0026#39;any\u0026#39;\nconst n = fn.call(undefined, false);\n\u003c/code\u003e\u003c/pre\u003e\n"
1454
1585
  },
1455
1586
  "strictBuiltinIteratorReturn": {
1456
1587
  "default": false,
1457
- "description": "Built-in iterators are instantiated with a `TReturn` type of `undefined` instead of `any`.",
1458
- "markdownDescription": "Built-in iterators are instantiated with a `TReturn` type of `undefined` instead of `any`.\n\nSee more: https://www.typescriptlang.org/tsconfig#strictBuiltinIteratorReturn",
1588
+ "description": "Built-in iterators are instantiated with a `TReturn` type of undefined instead of `any`.",
1589
+ "markdownDescription": "Built-in iterators are instantiated with a `TReturn` type of undefined instead of `any`.",
1459
1590
  "type": [
1460
1591
  "boolean",
1461
1592
  "null"
1462
- ]
1593
+ ],
1594
+ "x-intellij-html-description": "\u003cp\u003eBuilt-in iterators are instantiated with a \u003ccode\u003eTReturn\u003c/code\u003e type of undefined instead of \u003ccode\u003eany\u003c/code\u003e.\u003c/p\u003e\n"
1463
1595
  },
1464
1596
  "strictFunctionTypes": {
1465
1597
  "default": false,
1466
- "description": "When assigning functions, check to ensure parameters and the return values are subtype-compatible.",
1467
- "markdownDescription": "When assigning functions, check to ensure parameters and the return values are subtype-compatible.\n\nSee more: https://www.typescriptlang.org/tsconfig#strictFunctionTypes",
1598
+ "description": "When enabled, this flag causes functions parameters to be checked more correctly.\n\nHere's a basic example with `strictFunctionTypes` off:\n\n```ts twoslash\n// @strictFunctionTypes: false\nfunction fn(x: string) {\n console.log(\"Hello, \" + x.toLowerCase());\n}\n\ntype StringOrNumberFunc = (ns: string | number) =\u003e void;\n\n// Unsafe assignment\nlet func: StringOrNumberFunc = fn;\n// Unsafe call - will crash\nfunc(10);\n```\n\nWith `strictFunctionTypes` _on_, the error is correctly detected:\n\n```ts twoslash\n// @errors: 2322\nfunction fn(x: string) {\n console.log(\"Hello, \" + x.toLowerCase());\n}\n\ntype StringOrNumberFunc = (ns: string | number) =\u003e void;\n\n// Unsafe assignment is prevented\nlet func: StringOrNumberFunc = fn;\n```\n\nDuring development of this feature, we discovered a large number of inherently unsafe class hierarchies, including some in the DOM.\nBecause of this, the setting only applies to functions written in _function_ syntax, not to those in _method_ syntax:\n\n```ts twoslash\ntype Methodish = {\n func(x: string | number): void;\n};\n\nfunction fn(x: string) {\n console.log(\"Hello, \" + x.toLowerCase());\n}\n\n// Ultimately an unsafe assignment, but not detected\nconst m: Methodish = {\n func: fn,\n};\nm.func(10);\n```",
1599
+ "markdownDescription": "When enabled, this flag causes functions parameters to be checked more correctly.\n\nHere's a basic example with `strictFunctionTypes` off:\n\n```ts twoslash\n// @strictFunctionTypes: false\nfunction fn(x: string) {\n console.log(\"Hello, \" + x.toLowerCase());\n}\n\ntype StringOrNumberFunc = (ns: string | number) =\u003e void;\n\n// Unsafe assignment\nlet func: StringOrNumberFunc = fn;\n// Unsafe call - will crash\nfunc(10);\n```\n\nWith `strictFunctionTypes` _on_, the error is correctly detected:\n\n```ts twoslash\n// @errors: 2322\nfunction fn(x: string) {\n console.log(\"Hello, \" + x.toLowerCase());\n}\n\ntype StringOrNumberFunc = (ns: string | number) =\u003e void;\n\n// Unsafe assignment is prevented\nlet func: StringOrNumberFunc = fn;\n```\n\nDuring development of this feature, we discovered a large number of inherently unsafe class hierarchies, including some in the DOM.\nBecause of this, the setting only applies to functions written in _function_ syntax, not to those in _method_ syntax:\n\n```ts twoslash\ntype Methodish = {\n func(x: string | number): void;\n};\n\nfunction fn(x: string) {\n console.log(\"Hello, \" + x.toLowerCase());\n}\n\n// Ultimately an unsafe assignment, but not detected\nconst m: Methodish = {\n func: fn,\n};\nm.func(10);\n```",
1468
1600
  "type": [
1469
1601
  "boolean",
1470
1602
  "null"
1471
- ]
1603
+ ],
1604
+ "x-intellij-html-description": "\u003cp\u003eWhen enabled, this flag causes functions parameters to be checked more correctly.\u003c/p\u003e\n\u003cp\u003eHere\u0026#39;s a basic example with \u003ccode\u003estrictFunctionTypes\u003c/code\u003e off:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @strictFunctionTypes: false\nfunction fn(x: string) {\n console.log(\u0026quot;Hello, \u0026quot; + x.toLowerCase());\n}\n\ntype StringOrNumberFunc = (ns: string | number) =\u0026gt; void;\n\n// Unsafe assignment\nlet func: StringOrNumberFunc = fn;\n// Unsafe call - will crash\nfunc(10);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith \u003ccode\u003estrictFunctionTypes\u003c/code\u003e \u003cem\u003eon\u003c/em\u003e, the error is correctly detected:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 2322\nfunction fn(x: string) {\n console.log(\u0026quot;Hello, \u0026quot; + x.toLowerCase());\n}\n\ntype StringOrNumberFunc = (ns: string | number) =\u0026gt; void;\n\n// Unsafe assignment is prevented\nlet func: StringOrNumberFunc = fn;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eDuring development of this feature, we discovered a large number of inherently unsafe class hierarchies, including some in the DOM.\nBecause of this, the setting only applies to functions written in \u003cem\u003efunction\u003c/em\u003e syntax, not to those in \u003cem\u003emethod\u003c/em\u003e syntax:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003etype Methodish = {\n func(x: string | number): void;\n};\n\nfunction fn(x: string) {\n console.log(\u0026quot;Hello, \u0026quot; + x.toLowerCase());\n}\n\n// Ultimately an unsafe assignment, but not detected\nconst m: Methodish = {\n func: fn,\n};\nm.func(10);\n\u003c/code\u003e\u003c/pre\u003e\n"
1472
1605
  },
1473
1606
  "strictNullChecks": {
1474
1607
  "default": false,
1475
- "description": "When type checking, take into account `null` and `undefined`.",
1476
- "markdownDescription": "When type checking, take into account `null` and `undefined`.\n\nSee more: https://www.typescriptlang.org/tsconfig#strictNullChecks",
1608
+ "description": "When `strictNullChecks` is `false`, `null` and `undefined` are effectively ignored by the language.\nThis can lead to unexpected errors at runtime.\n\nWhen `strictNullChecks` is `true`, `null` and `undefined` have their own distinct types and you'll get a type error if you try to use them where a concrete value is expected.\n\nFor example with this TypeScript code, `users.find` has no guarantee that it will actually find a user, but you can\nwrite code as though it will:\n\n```ts twoslash\n// @strictNullChecks: false\n// @target: ES2015\ndeclare const loggedInUsername: string;\n\nconst users = [\n { name: \"Oby\", age: 12 },\n { name: \"Heera\", age: 32 },\n];\n\nconst loggedInUser = users.find((u) =\u003e u.name === loggedInUsername);\nconsole.log(loggedInUser.age);\n```\n\nSetting `strictNullChecks` to `true` will raise an error that you have not made a guarantee that the `loggedInUser` exists before trying to use it.\n\n```ts twoslash\n// @errors: 2339 2532 18048\n// @target: ES2020\n// @strictNullChecks\ndeclare const loggedInUsername: string;\n\nconst users = [\n { name: \"Oby\", age: 12 },\n { name: \"Heera\", age: 32 },\n];\n\nconst loggedInUser = users.find((u) =\u003e u.name === loggedInUsername);\nconsole.log(loggedInUser.age);\n```\n\nThe second example failed because the array's `find` function looks a bit like this simplification:\n\n```ts\n// When strictNullChecks: true\ntype Array = {\n find(predicate: (value: any, index: number) =\u003e boolean): S | undefined;\n};\n\n// When strictNullChecks: false the undefined is removed from the type system,\n// allowing you to write code which assumes it always found a result\ntype Array = {\n find(predicate: (value: any, index: number) =\u003e boolean): S;\n};\n```",
1609
+ "markdownDescription": "When `strictNullChecks` is `false`, `null` and `undefined` are effectively ignored by the language.\nThis can lead to unexpected errors at runtime.\n\nWhen `strictNullChecks` is `true`, `null` and `undefined` have their own distinct types and you'll get a type error if you try to use them where a concrete value is expected.\n\nFor example with this TypeScript code, `users.find` has no guarantee that it will actually find a user, but you can\nwrite code as though it will:\n\n```ts twoslash\n// @strictNullChecks: false\n// @target: ES2015\ndeclare const loggedInUsername: string;\n\nconst users = [\n { name: \"Oby\", age: 12 },\n { name: \"Heera\", age: 32 },\n];\n\nconst loggedInUser = users.find((u) =\u003e u.name === loggedInUsername);\nconsole.log(loggedInUser.age);\n```\n\nSetting `strictNullChecks` to `true` will raise an error that you have not made a guarantee that the `loggedInUser` exists before trying to use it.\n\n```ts twoslash\n// @errors: 2339 2532 18048\n// @target: ES2020\n// @strictNullChecks\ndeclare const loggedInUsername: string;\n\nconst users = [\n { name: \"Oby\", age: 12 },\n { name: \"Heera\", age: 32 },\n];\n\nconst loggedInUser = users.find((u) =\u003e u.name === loggedInUsername);\nconsole.log(loggedInUser.age);\n```\n\nThe second example failed because the array's `find` function looks a bit like this simplification:\n\n```ts\n// When strictNullChecks: true\ntype Array = {\n find(predicate: (value: any, index: number) =\u003e boolean): S | undefined;\n};\n\n// When strictNullChecks: false the undefined is removed from the type system,\n// allowing you to write code which assumes it always found a result\ntype Array = {\n find(predicate: (value: any, index: number) =\u003e boolean): S;\n};\n```",
1477
1610
  "type": [
1478
1611
  "boolean",
1479
1612
  "null"
1480
- ]
1613
+ ],
1614
+ "x-intellij-html-description": "\u003cp\u003eWhen \u003ccode\u003estrictNullChecks\u003c/code\u003e is \u003ccode\u003efalse\u003c/code\u003e, \u003ccode\u003enull\u003c/code\u003e and \u003ccode\u003eundefined\u003c/code\u003e are effectively ignored by the language.\nThis can lead to unexpected errors at runtime.\u003c/p\u003e\n\u003cp\u003eWhen \u003ccode\u003estrictNullChecks\u003c/code\u003e is \u003ccode\u003etrue\u003c/code\u003e, \u003ccode\u003enull\u003c/code\u003e and \u003ccode\u003eundefined\u003c/code\u003e have their own distinct types and you\u0026#39;ll get a type error if you try to use them where a concrete value is expected.\u003c/p\u003e\n\u003cp\u003eFor example with this TypeScript code, \u003ccode\u003eusers.find\u003c/code\u003e has no guarantee that it will actually find a user, but you can\nwrite code as though it will:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @strictNullChecks: false\n// @target: ES2015\ndeclare const loggedInUsername: string;\n\nconst users = [\n { name: \u0026quot;Oby\u0026quot;, age: 12 },\n { name: \u0026quot;Heera\u0026quot;, age: 32 },\n];\n\nconst loggedInUser = users.find((u) =\u0026gt; u.name === loggedInUsername);\nconsole.log(loggedInUser.age);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eSetting \u003ccode\u003estrictNullChecks\u003c/code\u003e to \u003ccode\u003etrue\u003c/code\u003e will raise an error that you have not made a guarantee that the \u003ccode\u003eloggedInUser\u003c/code\u003e exists before trying to use it.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 2339 2532 18048\n// @target: ES2020\n// @strictNullChecks\ndeclare const loggedInUsername: string;\n\nconst users = [\n { name: \u0026quot;Oby\u0026quot;, age: 12 },\n { name: \u0026quot;Heera\u0026quot;, age: 32 },\n];\n\nconst loggedInUser = users.find((u) =\u0026gt; u.name === loggedInUsername);\nconsole.log(loggedInUser.age);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe second example failed because the array\u0026#39;s \u003ccode\u003efind\u003c/code\u003e function looks a bit like this simplification:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// When strictNullChecks: true\ntype Array = {\n find(predicate: (value: any, index: number) =\u0026gt; boolean): S | undefined;\n};\n\n// When strictNullChecks: false the undefined is removed from the type system,\n// allowing you to write code which assumes it always found a result\ntype Array = {\n find(predicate: (value: any, index: number) =\u0026gt; boolean): S;\n};\n\u003c/code\u003e\u003c/pre\u003e\n"
1481
1615
  },
1482
1616
  "strictPropertyInitialization": {
1483
1617
  "default": false,
1484
- "description": "Check for class properties that are declared but not set in the constructor.",
1485
- "markdownDescription": "Check for class properties that are declared but not set in the constructor.\n\nSee more: https://www.typescriptlang.org/tsconfig#strictPropertyInitialization",
1618
+ "description": "When set to true, TypeScript will raise an error when a class property was declared but not set in the constructor.\n\n```ts twoslash\n// @errors: 2564\nclass UserAccount {\n name: string;\n accountType = \"user\";\n\n email: string;\n address: string | undefined;\n\n constructor(name: string) {\n this.name = name;\n // Note that this.email is not set\n }\n}\n```\n\nIn the above case:\n\n- `this.name` is set specifically.\n- `this.accountType` is set by default.\n- `this.email` is not set and raises an error.\n- `this.address` is declared as potentially `undefined` which means it does not have to be set.",
1619
+ "markdownDescription": "When set to true, TypeScript will raise an error when a class property was declared but not set in the constructor.\n\n```ts twoslash\n// @errors: 2564\nclass UserAccount {\n name: string;\n accountType = \"user\";\n\n email: string;\n address: string | undefined;\n\n constructor(name: string) {\n this.name = name;\n // Note that this.email is not set\n }\n}\n```\n\nIn the above case:\n\n- `this.name` is set specifically.\n- `this.accountType` is set by default.\n- `this.email` is not set and raises an error.\n- `this.address` is declared as potentially `undefined` which means it does not have to be set.",
1486
1620
  "type": [
1487
1621
  "boolean",
1488
1622
  "null"
1489
- ]
1623
+ ],
1624
+ "x-intellij-html-description": "\u003cp\u003eWhen set to true, TypeScript will raise an error when a class property was declared but not set in the constructor.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 2564\nclass UserAccount {\n name: string;\n accountType = \u0026quot;user\u0026quot;;\n\n email: string;\n address: string | undefined;\n\n constructor(name: string) {\n this.name = name;\n // Note that this.email is not set\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eIn the above case:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003ethis.name\u003c/code\u003e is set specifically.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ethis.accountType\u003c/code\u003e is set by default.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ethis.email\u003c/code\u003e is not set and raises an error.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ethis.address\u003c/code\u003e is declared as potentially \u003ccode\u003eundefined\u003c/code\u003e which means it does not have to be set.\u003c/li\u003e\n\u003c/ul\u003e\n"
1490
1625
  },
1491
1626
  "stripInternal": {
1492
- "description": "Disable emitting declarations that have `@internal` in their JSDoc comments.",
1493
- "markdownDescription": "Disable emitting declarations that have `@internal` in their JSDoc comments.\n\nSee more: https://www.typescriptlang.org/tsconfig#stripInternal",
1627
+ "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.",
1628
+ "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.",
1494
1629
  "type": [
1495
1630
  "boolean",
1496
1631
  "null"
1497
- ]
1632
+ ],
1633
+ "x-intellij-html-description": "\u003cp\u003eDo not emit declarations for code that has an \u003ccode\u003e@internal\u003c/code\u003e 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 \u003ccode\u003ed.ts\u003c/code\u003e files, look at \u003ca href=\"https://api-extractor.com/\"\u003eapi-extractor\u003c/a\u003e.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e/**\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\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith the flag set to \u003ccode\u003efalse\u003c/code\u003e (default):\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith \u003ccode\u003estripInternal\u003c/code\u003e set to \u003ccode\u003etrue\u003c/code\u003e the \u003ccode\u003ed.ts\u003c/code\u003e emitted will be redacted.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe JavaScript output is still the same.\u003c/p\u003e\n"
1498
1634
  },
1499
1635
  "suppressExcessPropertyErrors": {
1500
1636
  "default": false,
1501
- "description": "Disable reporting of excess property errors during the creation of object literals.",
1502
- "markdownDescription": "Disable reporting of excess property errors during the creation of object literals.\n\nSee more: https://www.typescriptlang.org/tsconfig#suppressExcessPropertyErrors",
1637
+ "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`.",
1638
+ "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`.",
1503
1639
  "type": [
1504
1640
  "boolean",
1505
1641
  "null"
1506
- ]
1642
+ ],
1643
+ "x-intellij-html-description": "\u003cp\u003eThis disables reporting of excess property errors, such as the one shown in the following example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @errors: 2322\ntype Point = { x: number; y: number };\nconst p: Point = { x: 1, y: 3, m: 10 };\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis flag was added to help people migrate to the stricter checking of new object literals in \u003ca href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-1-6.html#stricter-object-literal-assignment-checks\"\u003eTypeScript 1.6\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eWe don\u0026#39;t recommend using this flag in a modern codebase, you can suppress one-off cases where you need it using \u003ccode\u003e// @ts-ignore\u003c/code\u003e.\u003c/p\u003e\n"
1507
1644
  },
1508
1645
  "suppressImplicitAnyIndexErrors": {
1509
1646
  "default": false,
1510
- "description": "Suppress `noImplicitAny` errors when indexing objects that lack index signatures.",
1511
- "markdownDescription": "Suppress `noImplicitAny` errors when indexing objects that lack index signatures.\n\nSee more: https://www.typescriptlang.org/tsconfig#suppressImplicitAnyIndexErrors",
1647
+ "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```",
1648
+ "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```",
1512
1649
  "type": [
1513
1650
  "boolean",
1514
1651
  "null"
1515
- ]
1652
+ ],
1653
+ "x-intellij-html-description": "\u003cp\u003eTurning \u003ccode\u003esuppressImplicitAnyIndexErrors\u003c/code\u003e on suppresses reporting the error about implicit anys when indexing into objects, as shown in the following example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @noImplicitAny: true\n// @suppressImplicitAnyIndexErrors: false\n// @strict: true\n// @errors: 7053\nconst obj = { x: 10 };\nconsole.log(obj[\u0026quot;foo\u0026quot;]);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eUsing \u003ccode\u003esuppressImplicitAnyIndexErrors\u003c/code\u003e is quite a drastic approach. It is recommended to use a \u003ccode\u003e@ts-ignore\u003c/code\u003e comment instead:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @noImplicitAny: true\n// @strict: true\nconst obj = { x: 10 };\n// @ts-ignore\nconsole.log(obj[\u0026quot;foo\u0026quot;]);\n\u003c/code\u003e\u003c/pre\u003e\n"
1516
1654
  },
1517
1655
  "target": {
1518
1656
  "anyOf": [
@@ -1531,25 +1669,26 @@
1531
1669
  "es2022",
1532
1670
  "es2023",
1533
1671
  "es2024",
1672
+ "es2025",
1534
1673
  "esnext"
1535
1674
  ]
1536
1675
  },
1537
1676
  {
1538
- "pattern": "^([Ee][Ss]([356]|(20(1[56789]|2[01234]))|[Nn][Ee][Xx][Tt]))$"
1677
+ "pattern": "^([Ee][Ss]([356]|(20(1[56789]|2[012345]))|[Nn][Ee][Xx][Tt]))$"
1539
1678
  }
1540
1679
  ],
1541
- "default": "es3",
1542
- "description": "Set the JavaScript language version for emitted JavaScript and include compatible library declarations.",
1543
- "markdownDescription": "Set the JavaScript language version for emitted JavaScript and include compatible library declarations.\n\nSee more: https://www.typescriptlang.org/tsconfig#target",
1680
+ "default": "es2025",
1681
+ "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 `() =\u003e 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.\n\nAs of TypeScript 6.0, the default is `es2025`, which advances alongside the ECMAScript standard.",
1682
+ "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 `() =\u003e 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.\n\nAs of TypeScript 6.0, the default is `es2025`, which advances alongside the ECMAScript standard.",
1544
1683
  "type": [
1545
1684
  "string",
1546
1685
  "null"
1547
- ]
1686
+ ],
1687
+ "x-intellij-html-description": "\u003cp\u003eModern browsers support all ES6 features, so \u003ccode\u003eES6\u003c/code\u003e 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.\u003c/p\u003e\n\u003cp\u003eThe \u003ccode\u003etarget\u003c/code\u003e setting changes which JS features are downleveled and which are left intact.\nFor example, an arrow function \u003ccode\u003e() =\u0026gt; this\u003c/code\u003e will be turned into an equivalent \u003ccode\u003efunction\u003c/code\u003e expression if \u003ccode\u003etarget\u003c/code\u003e is ES5 or lower.\u003c/p\u003e\n\u003cp\u003eChanging \u003ccode\u003etarget\u003c/code\u003e also changes the default value of \u003ca href=\"https://typescriptlang.org/tsconfig/#lib\"\u003e\u003ccode\u003elib\u003c/code\u003e\u003c/a\u003e.\nYou may \u0026quot;mix and match\u0026quot; \u003ccode\u003etarget\u003c/code\u003e and \u003ccode\u003elib\u003c/code\u003e settings as desired, but you could just set \u003ccode\u003etarget\u003c/code\u003e for convenience.\u003c/p\u003e\n\u003cp\u003eFor developer platforms like Node there are baselines for the \u003ccode\u003etarget\u003c/code\u003e, depending on the type of platform and its version. You can find a set of community organized TSConfigs at \u003ca href=\"https://github.com/tsconfig/bases#centralized-recommendations-for-tsconfig-bases\"\u003etsconfig/bases\u003c/a\u003e, which has configurations for common platforms and their versions.\u003c/p\u003e\n\u003cp\u003eThe special \u003ccode\u003eESNext\u003c/code\u003e value refers to the highest version your version of TypeScript supports.\nThis setting should be used with caution, since it doesn\u0026#39;t mean the same thing between different TypeScript versions and can make upgrades less predictable.\u003c/p\u003e\n\u003cp\u003eAs of TypeScript 6.0, the default is \u003ccode\u003ees2025\u003c/code\u003e, which advances alongside the ECMAScript standard.\u003c/p\u003e\n"
1548
1688
  },
1549
1689
  "traceResolution": {
1550
1690
  "default": false,
1551
- "description": "Log paths used during the `moduleResolution` process.",
1552
- "markdownDescription": "Log paths used during the `moduleResolution` process.\n\nSee more: https://www.typescriptlang.org/tsconfig#traceResolution",
1691
+ "description": "Enable tracing of the name resolution process. Requires TypeScript version 2.0 or later.",
1553
1692
  "type": [
1554
1693
  "boolean",
1555
1694
  "null"
@@ -1557,62 +1696,69 @@
1557
1696
  },
1558
1697
  "tsBuildInfoFile": {
1559
1698
  "default": ".tsbuildinfo",
1560
- "description": "Specify the path to .tsbuildinfo incremental compilation file.",
1561
- "markdownDescription": "Specify the path to .tsbuildinfo incremental compilation file.\n\nSee more: https://www.typescriptlang.org/tsconfig#tsBuildInfoFile",
1699
+ "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 `\u003coutFile\u003e.tsbuildinfo`.\n- If `rootDir` and `outDir` are set, then the file is `\u003coutDir\u003e/\u003crelative path to config from rootDir\u003e/\u003cconfig name\u003e.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 `\u003coutDir\u003e/\u003cconfig name\u003e.tsbuildInfo`\n- Otherwise, the default is `\u003cconfig name\u003e.tsbuildInfo`",
1700
+ "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 `\u003coutFile\u003e.tsbuildinfo`.\n- If `rootDir` and `outDir` are set, then the file is `\u003coutDir\u003e/\u003crelative path to config from rootDir\u003e/\u003cconfig name\u003e.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 `\u003coutDir\u003e/\u003cconfig name\u003e.tsbuildInfo`\n- Otherwise, the default is `\u003cconfig name\u003e.tsbuildInfo`",
1562
1701
  "type": [
1563
1702
  "string",
1564
1703
  "null"
1565
- ]
1704
+ ],
1705
+ "x-intellij-html-description": "\u003cp\u003eThis 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 \u003ca href=\"https://typescriptlang.org/docs/handbook/project-references.html\"\u003ein the handbook\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eThe default depends on a combination of other settings:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIf \u003ccode\u003eoutFile\u003c/code\u003e is set, the default is \u003ccode\u003e\u0026lt;outFile\u0026gt;.tsbuildinfo\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eIf \u003ccode\u003erootDir\u003c/code\u003e and \u003ccode\u003eoutDir\u003c/code\u003e are set, then the file is \u003ccode\u003e\u0026lt;outDir\u0026gt;/\u0026lt;relative path to config from rootDir\u0026gt;/\u0026lt;config name\u0026gt;.tsbuildinfo\u003c/code\u003e\nFor example, if \u003ccode\u003erootDir\u003c/code\u003e is \u003ccode\u003esrc\u003c/code\u003e, \u003ccode\u003eoutDir\u003c/code\u003e is \u003ccode\u003edest\u003c/code\u003e, and the config is\n\u003ccode\u003e./tsconfig.json\u003c/code\u003e, then the default is \u003ccode\u003e./tsconfig.tsbuildinfo\u003c/code\u003e\nas the relative path from \u003ccode\u003esrc/\u003c/code\u003e to \u003ccode\u003e./tsconfig.json\u003c/code\u003e is \u003ccode\u003e../\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eIf \u003ccode\u003eoutDir\u003c/code\u003e is set, then the default is \u003ccode\u003e\u0026lt;outDir\u0026gt;/\u0026lt;config name\u0026gt;.tsbuildInfo\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003eOtherwise, the default is \u003ccode\u003e\u0026lt;config name\u0026gt;.tsbuildInfo\u003c/code\u003e\u003c/li\u003e\n\u003c/ul\u003e\n"
1566
1706
  },
1567
1707
  "typeRoots": {
1568
- "description": "Specify multiple folders that act like `./node_modules/@types`.",
1708
+ "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`.",
1569
1709
  "items": {
1570
1710
  "type": "string"
1571
1711
  },
1572
- "markdownDescription": "Specify multiple folders that act like `./node_modules/@types`.\n\nSee more: https://www.typescriptlang.org/tsconfig#typeRoots",
1712
+ "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`.",
1573
1713
  "type": [
1574
1714
  "array",
1575
1715
  "null"
1576
1716
  ],
1577
- "uniqueItems": true
1717
+ "uniqueItems": true,
1718
+ "x-intellij-html-description": "\u003cp\u003eBy default all \u003cem\u003evisible\u003c/em\u003e \u0026quot;\u003ccode\u003e@types\u003c/code\u003e\u0026quot; packages are included in your compilation.\nPackages in \u003ccode\u003enode_modules/@types\u003c/code\u003e of any enclosing folder are considered \u003cem\u003evisible\u003c/em\u003e.\nFor example, that means packages within \u003ccode\u003e./node_modules/@types/\u003c/code\u003e, \u003ccode\u003e../node_modules/@types/\u003c/code\u003e, \u003ccode\u003e../../node_modules/@types/\u003c/code\u003e, and so on.\u003c/p\u003e\n\u003cp\u003eIf \u003ccode\u003etypeRoots\u003c/code\u003e is specified, \u003cem\u003eonly\u003c/em\u003e packages under \u003ccode\u003etypeRoots\u003c/code\u003e will be included. For example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;typeRoots\u0026quot;: [\u0026quot;./typings\u0026quot;, \u0026quot;./vendor/types\u0026quot;]\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis config file will include \u003cem\u003eall\u003c/em\u003e packages under \u003ccode\u003e./typings\u003c/code\u003e and \u003ccode\u003e./vendor/types\u003c/code\u003e, and no packages from \u003ccode\u003e./node_modules/@types\u003c/code\u003e.\nAll paths are relative to the \u003ccode\u003etsconfig.json\u003c/code\u003e.\u003c/p\u003e\n"
1578
1719
  },
1579
1720
  "types": {
1580
- "description": "Specify type package names to be included without being referenced in a source file.",
1721
+ "default": [],
1722
+ "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.\n\nAs of TypeScript 6.0, the default is `[]` (empty array), meaning no `@types` packages are included in the global scope automatically.",
1581
1723
  "items": {
1582
1724
  "type": "string"
1583
1725
  },
1584
- "markdownDescription": "Specify type package names to be included without being referenced in a source file.\n\nSee more: https://www.typescriptlang.org/tsconfig#types",
1726
+ "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.\n\nAs of TypeScript 6.0, the default is `[]` (empty array), meaning no `@types` packages are included in the global scope automatically.",
1585
1727
  "type": [
1586
1728
  "array",
1587
1729
  "null"
1588
1730
  ],
1589
- "uniqueItems": true
1731
+ "uniqueItems": true,
1732
+ "x-intellij-html-description": "\u003cp\u003eBy default all \u003cem\u003evisible\u003c/em\u003e \u0026quot;\u003ccode\u003e@types\u003c/code\u003e\u0026quot; packages are included in your compilation.\nPackages in \u003ccode\u003enode_modules/@types\u003c/code\u003e of any enclosing folder are considered \u003cem\u003evisible\u003c/em\u003e.\nFor example, that means packages within \u003ccode\u003e./node_modules/@types/\u003c/code\u003e, \u003ccode\u003e../node_modules/@types/\u003c/code\u003e, \u003ccode\u003e../../node_modules/@types/\u003c/code\u003e, and so on.\u003c/p\u003e\n\u003cp\u003eIf \u003ccode\u003etypes\u003c/code\u003e is specified, only packages listed will be included in the global scope. For instance:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;types\u0026quot;: [\u0026quot;node\u0026quot;, \u0026quot;jest\u0026quot;, \u0026quot;express\u0026quot;]\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis \u003ccode\u003etsconfig.json\u003c/code\u003e file will \u003cem\u003eonly\u003c/em\u003e include \u003ccode\u003e./node_modules/@types/node\u003c/code\u003e, \u003ccode\u003e./node_modules/@types/jest\u003c/code\u003e and \u003ccode\u003e./node_modules/@types/express\u003c/code\u003e.\nOther packages under \u003ccode\u003enode_modules/@types/*\u003c/code\u003e will not be included.\u003c/p\u003e\n\u003ch3\u003eWhat does this affect?\u003c/h3\u003e\n\u003cp\u003eThis option does not affect how \u003ccode\u003e@types/*\u003c/code\u003e are included in your application code, for example if you had the above \u003ccode\u003ecompilerOptions\u003c/code\u003e example with code like:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eimport * as moment from \u0026quot;moment\u0026quot;;\n\nmoment().format(\u0026quot;MMMM Do YYYY, h:mm:ss a\u0026quot;);\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThe \u003ccode\u003emoment\u003c/code\u003e import would be fully typed.\u003c/p\u003e\n\u003cp\u003eWhen you have this option set, by not including a module in the \u003ccode\u003etypes\u003c/code\u003e array it:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWill not add globals to your project (e.g \u003ccode\u003eprocess\u003c/code\u003e in node, or \u003ccode\u003eexpect\u003c/code\u003e in Jest)\u003c/li\u003e\n\u003cli\u003eWill not have exports appear as auto-import recommendations\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThis feature differs from \u003ca href=\"https://typescriptlang.org/tsconfig/#typeRoots\"\u003e\u003ccode\u003etypeRoots\u003c/code\u003e\u003c/a\u003e in that it is about specifying only the exact types you want included, whereas \u003ca href=\"https://typescriptlang.org/tsconfig/#typeRoots\"\u003e\u003ccode\u003etypeRoots\u003c/code\u003e\u003c/a\u003e supports saying you want particular folders.\u003c/p\u003e\n\u003cp\u003eAs of TypeScript 6.0, the default is \u003ccode\u003e[]\u003c/code\u003e (empty array), meaning no \u003ccode\u003e@types\u003c/code\u003e packages are included in the global scope automatically.\u003c/p\u003e\n"
1590
1733
  },
1591
1734
  "useDefineForClassFields": {
1592
1735
  "default": false,
1593
- "description": "Emit ECMAScript-standard-compliant class fields.",
1594
- "markdownDescription": "Emit ECMAScript-standard-compliant class fields.\n\nSee more: https://www.typescriptlang.org/tsconfig#useDefineForClassFields",
1736
+ "description": "This flag is used as part of migrating to the upcoming standard version of class fields. TypeScript introduced class fields many years before it was ratified in TC39. The latest version of the upcoming specification has a different runtime behavior to TypeScript's implementation but the same syntax.\n\nThis flag switches to the upcoming ECMA runtime behavior.\n\nYou can read more about the transition in [the 3.7 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#the-usedefineforclassfields-flag-and-the-declare-property-modifier).",
1737
+ "markdownDescription": "This flag is used as part of migrating to the upcoming standard version of class fields. TypeScript introduced class fields many years before it was ratified in TC39. The latest version of the upcoming specification has a different runtime behavior to TypeScript's implementation but the same syntax.\n\nThis flag switches to the upcoming ECMA runtime behavior.\n\nYou can read more about the transition in [the 3.7 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#the-usedefineforclassfields-flag-and-the-declare-property-modifier).",
1595
1738
  "type": [
1596
1739
  "boolean",
1597
1740
  "null"
1598
- ]
1741
+ ],
1742
+ "x-intellij-html-description": "\u003cp\u003eThis flag is used as part of migrating to the upcoming standard version of class fields. TypeScript introduced class fields many years before it was ratified in TC39. The latest version of the upcoming specification has a different runtime behavior to TypeScript\u0026#39;s implementation but the same syntax.\u003c/p\u003e\n\u003cp\u003eThis flag switches to the upcoming ECMA runtime behavior.\u003c/p\u003e\n\u003cp\u003eYou can read more about the transition in \u003ca href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#the-usedefineforclassfields-flag-and-the-declare-property-modifier\"\u003ethe 3.7 release notes\u003c/a\u003e.\u003c/p\u003e\n"
1599
1743
  },
1600
1744
  "useUnknownInCatchVariables": {
1601
1745
  "default": false,
1602
- "description": "Default catch clause variables as `unknown` instead of `any`.",
1603
- "markdownDescription": "Default catch clause variables as `unknown` instead of `any`.\n\nSee more: https://www.typescriptlang.org/tsconfig#useUnknownInCatchVariables",
1746
+ "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.",
1747
+ "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.",
1604
1748
  "type": [
1605
1749
  "boolean",
1606
1750
  "null"
1607
- ]
1751
+ ],
1752
+ "x-intellij-html-description": "\u003cp\u003eIn TypeScript 4.0, support was added to allow changing the type of the variable in a catch clause from \u003ccode\u003eany\u003c/code\u003e to \u003ccode\u003eunknown\u003c/code\u003e. Allowing for code like:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// @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\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis pattern ensures that error handling code becomes more comprehensive because you cannot guarantee that the object being thrown \u003cem\u003eis\u003c/em\u003e a Error subclass ahead of time. With the flag \u003ccode\u003euseUnknownInCatchVariables\u003c/code\u003e enabled, then you do not need the additional syntax (\u003ccode\u003e: unknown\u003c/code\u003e) nor a linter rule to try enforce this behavior.\u003c/p\u003e\n"
1608
1753
  },
1609
1754
  "verbatimModuleSyntax": {
1610
- "description": "Do not transform or elide any imports or exports not marked as type-only, ensuring they are written in the output file's format based on the `module` setting.",
1611
- "markdownDescription": "Do not transform or elide any imports or exports not marked as type-only, ensuring they are written in the output file's format based on the `module` setting.\n\nSee more: https://www.typescriptlang.org/tsconfig#verbatimModuleSyntax",
1755
+ "description": "By default, TypeScript does something called *import elision*.\nBasically, if you write something like\n\n```ts\nimport { Car } from \"./car\";\n\nexport function drive(car: Car) {\n // ...\n}\n```\n\nTypeScript detects that you're only using an import for types and drops the import entirely.\nYour output JavaScript might look something like this:\n\n```js\nexport function drive(car) {\n // ...\n}\n```\n\nMost of the time this is good, because if `Car` isn't a value that's exported from `./car`, we'll get a runtime error.\n\nBut it does add a layer of complexity for certain edge cases.\nFor example, notice there's no statement like `import \"./car\";` - the import was dropped entirely.\nThat actually makes a difference for modules that have side-effects or not.\n\nTypeScript's emit strategy for JavaScript also has another few layers of complexity - import elision isn't always just driven by how an import is used - it often consults how a value is declared as well.\nSo it's not always clear whether code like the following\n\n```ts\nexport { Car } from \"./car\";\n```\n\nshould be preserved or dropped.\nIf `Car` is declared with something like a `class`, then it can be preserved in the resulting JavaScript file.\nBut if `Car` is only declared as a `type` alias or `interface`, then the JavaScript file shouldn't export `Car` at all.\n\nWhile TypeScript might be able to make these emit decisions based on information from across files, not every compiler can.\n\nThe `type` modifier on imports and exports helps with these situations a bit.\nWe can make it explicit whether an import or export is only being used for type analysis, and can be dropped entirely in JavaScript files by using the `type` modifier.\n\n```ts\n// This statement can be dropped entirely in JS output\nimport type * as car from \"./car\";\n\n// The named import/export 'Car' can be dropped in JS output\nimport { type Car } from \"./car\";\nexport { type Car } from \"./car\";\n```\n\n`type` modifiers are not quite useful on their own - by default, module elision will still drop imports, and nothing forces you to make the distinction between `type` and plain imports and exports.\nSo TypeScript has the flag `--importsNotUsedAsValues` to make sure you use the `type` modifier, `--preserveValueImports` to prevent *some* module elision behavior, and `--isolatedModules` to make sure that your TypeScript code works across different compilers.\nUnfortunately, understanding the fine details of those 3 flags is hard, and there are still some edge cases with unexpected behavior.\n\nTypeScript 5.0 introduces a new option called `--verbatimModuleSyntax` to simplify the situation.\nThe rules are much simpler - any imports or exports without a `type` modifier are left around.\nAnything that uses the `type` modifier is dropped entirely.\n\n```ts\n// Erased away entirely.\nimport type { A } from \"a\";\n\n// Rewritten to 'import { b } from \"bcd\";'\nimport { b, type c, type d } from \"bcd\";\n\n// Rewritten to 'import {} from \"xyz\";'\nimport { type xyz } from \"xyz\";\n```\n\nWith this new option, what you see is what you get.\n\nThat does have some implications when it comes to module interop though.\nUnder this flag, ECMAScript `import`s and `export`s won't be rewritten to `require` calls when your settings or file extension implied a different module system.\nInstead, you'll get an error.\nIf you need to emit code that uses `require` and `module.exports`, you'll have to use TypeScript's module syntax that predates ES2015:\n\n\u003ctable\u003e\n\u003cthead\u003e\n \u003ctr\u003e\n \u003cth\u003eInput TypeScript\u003c/th\u003e\n \u003cth\u003eOutput JavaScript\u003c/th\u003e\n \u003c/tr\u003e\n\u003c/thead\u003e\n\n\u003ctr\u003e\n\u003ctd\u003e\n\n```ts\nimport foo = require(\"foo\");\n```\n\n\u003c/td\u003e\n\u003ctd\u003e\n\n```js\nconst foo = require(\"foo\");\n```\n\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\n```ts\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nexport = {\n foo,\n bar,\n baz\n};\n```\n\n\u003c/td\u003e\n\u003ctd\u003e\n\n```js\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nmodule.exports = {\n foo,\n bar,\n baz\n};\n```\n\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\nWhile this is a limitation, it does help make some issues more obvious.\nFor example, it's very common to forget to set the [`type` field in `package.json`](https://nodejs.org/api/packages.html#type) under `--module node16`.\nAs a result, developers would start writing CommonJS modules instead of ES modules without realizing it, giving surprising lookup rules and JavaScript output.\nThis new flag ensures that you're intentional about the file type you're using because the syntax is intentionally different.\n\nBecause `--verbatimModuleSyntax` provides a more consistent story than `--importsNotUsedAsValues` and `--preserveValueImports`, those two existing flags are being deprecated in its favor.\n\nFor more details, read up on [the original pull request](https://github.com/microsoft/TypeScript/pull/52203) and [its proposal issue](https://github.com/microsoft/TypeScript/issues/51479).",
1756
+ "markdownDescription": "By default, TypeScript does something called *import elision*.\nBasically, if you write something like\n\n```ts\nimport { Car } from \"./car\";\n\nexport function drive(car: Car) {\n // ...\n}\n```\n\nTypeScript detects that you're only using an import for types and drops the import entirely.\nYour output JavaScript might look something like this:\n\n```js\nexport function drive(car) {\n // ...\n}\n```\n\nMost of the time this is good, because if `Car` isn't a value that's exported from `./car`, we'll get a runtime error.\n\nBut it does add a layer of complexity for certain edge cases.\nFor example, notice there's no statement like `import \"./car\";` - the import was dropped entirely.\nThat actually makes a difference for modules that have side-effects or not.\n\nTypeScript's emit strategy for JavaScript also has another few layers of complexity - import elision isn't always just driven by how an import is used - it often consults how a value is declared as well.\nSo it's not always clear whether code like the following\n\n```ts\nexport { Car } from \"./car\";\n```\n\nshould be preserved or dropped.\nIf `Car` is declared with something like a `class`, then it can be preserved in the resulting JavaScript file.\nBut if `Car` is only declared as a `type` alias or `interface`, then the JavaScript file shouldn't export `Car` at all.\n\nWhile TypeScript might be able to make these emit decisions based on information from across files, not every compiler can.\n\nThe `type` modifier on imports and exports helps with these situations a bit.\nWe can make it explicit whether an import or export is only being used for type analysis, and can be dropped entirely in JavaScript files by using the `type` modifier.\n\n```ts\n// This statement can be dropped entirely in JS output\nimport type * as car from \"./car\";\n\n// The named import/export 'Car' can be dropped in JS output\nimport { type Car } from \"./car\";\nexport { type Car } from \"./car\";\n```\n\n`type` modifiers are not quite useful on their own - by default, module elision will still drop imports, and nothing forces you to make the distinction between `type` and plain imports and exports.\nSo TypeScript has the flag `--importsNotUsedAsValues` to make sure you use the `type` modifier, `--preserveValueImports` to prevent *some* module elision behavior, and `--isolatedModules` to make sure that your TypeScript code works across different compilers.\nUnfortunately, understanding the fine details of those 3 flags is hard, and there are still some edge cases with unexpected behavior.\n\nTypeScript 5.0 introduces a new option called `--verbatimModuleSyntax` to simplify the situation.\nThe rules are much simpler - any imports or exports without a `type` modifier are left around.\nAnything that uses the `type` modifier is dropped entirely.\n\n```ts\n// Erased away entirely.\nimport type { A } from \"a\";\n\n// Rewritten to 'import { b } from \"bcd\";'\nimport { b, type c, type d } from \"bcd\";\n\n// Rewritten to 'import {} from \"xyz\";'\nimport { type xyz } from \"xyz\";\n```\n\nWith this new option, what you see is what you get.\n\nThat does have some implications when it comes to module interop though.\nUnder this flag, ECMAScript `import`s and `export`s won't be rewritten to `require` calls when your settings or file extension implied a different module system.\nInstead, you'll get an error.\nIf you need to emit code that uses `require` and `module.exports`, you'll have to use TypeScript's module syntax that predates ES2015:\n\n\u003ctable\u003e\n\u003cthead\u003e\n \u003ctr\u003e\n \u003cth\u003eInput TypeScript\u003c/th\u003e\n \u003cth\u003eOutput JavaScript\u003c/th\u003e\n \u003c/tr\u003e\n\u003c/thead\u003e\n\n\u003ctr\u003e\n\u003ctd\u003e\n\n```ts\nimport foo = require(\"foo\");\n```\n\n\u003c/td\u003e\n\u003ctd\u003e\n\n```js\nconst foo = require(\"foo\");\n```\n\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\n\n```ts\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nexport = {\n foo,\n bar,\n baz\n};\n```\n\n\u003c/td\u003e\n\u003ctd\u003e\n\n```js\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nmodule.exports = {\n foo,\n bar,\n baz\n};\n```\n\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\n\nWhile this is a limitation, it does help make some issues more obvious.\nFor example, it's very common to forget to set the [`type` field in `package.json`](https://nodejs.org/api/packages.html#type) under `--module node16`.\nAs a result, developers would start writing CommonJS modules instead of ES modules without realizing it, giving surprising lookup rules and JavaScript output.\nThis new flag ensures that you're intentional about the file type you're using because the syntax is intentionally different.\n\nBecause `--verbatimModuleSyntax` provides a more consistent story than `--importsNotUsedAsValues` and `--preserveValueImports`, those two existing flags are being deprecated in its favor.\n\nFor more details, read up on [the original pull request](https://github.com/microsoft/TypeScript/pull/52203) and [its proposal issue](https://github.com/microsoft/TypeScript/issues/51479).",
1612
1757
  "type": [
1613
1758
  "boolean",
1614
1759
  "null"
1615
- ]
1760
+ ],
1761
+ "x-intellij-html-description": "\u003cp\u003eBy default, TypeScript does something called \u003cem\u003eimport elision\u003c/em\u003e.\nBasically, if you write something like\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eimport { Car } from \u0026quot;./car\u0026quot;;\n\nexport function drive(car: Car) {\n // ...\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eTypeScript detects that you\u0026#39;re only using an import for types and drops the import entirely.\nYour output JavaScript might look something like this:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-js\"\u003eexport function drive(car) {\n // ...\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eMost of the time this is good, because if \u003ccode\u003eCar\u003c/code\u003e isn\u0026#39;t a value that\u0026#39;s exported from \u003ccode\u003e./car\u003c/code\u003e, we\u0026#39;ll get a runtime error.\u003c/p\u003e\n\u003cp\u003eBut it does add a layer of complexity for certain edge cases.\nFor example, notice there\u0026#39;s no statement like \u003ccode\u003eimport \u0026quot;./car\u0026quot;;\u003c/code\u003e - the import was dropped entirely.\nThat actually makes a difference for modules that have side-effects or not.\u003c/p\u003e\n\u003cp\u003eTypeScript\u0026#39;s emit strategy for JavaScript also has another few layers of complexity - import elision isn\u0026#39;t always just driven by how an import is used - it often consults how a value is declared as well.\nSo it\u0026#39;s not always clear whether code like the following\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eexport { Car } from \u0026quot;./car\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eshould be preserved or dropped.\nIf \u003ccode\u003eCar\u003c/code\u003e is declared with something like a \u003ccode\u003eclass\u003c/code\u003e, then it can be preserved in the resulting JavaScript file.\nBut if \u003ccode\u003eCar\u003c/code\u003e is only declared as a \u003ccode\u003etype\u003c/code\u003e alias or \u003ccode\u003einterface\u003c/code\u003e, then the JavaScript file shouldn\u0026#39;t export \u003ccode\u003eCar\u003c/code\u003e at all.\u003c/p\u003e\n\u003cp\u003eWhile TypeScript might be able to make these emit decisions based on information from across files, not every compiler can.\u003c/p\u003e\n\u003cp\u003eThe \u003ccode\u003etype\u003c/code\u003e modifier on imports and exports helps with these situations a bit.\nWe can make it explicit whether an import or export is only being used for type analysis, and can be dropped entirely in JavaScript files by using the \u003ccode\u003etype\u003c/code\u003e modifier.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// This statement can be dropped entirely in JS output\nimport type * as car from \u0026quot;./car\u0026quot;;\n\n// The named import/export \u0026#39;Car\u0026#39; can be dropped in JS output\nimport { type Car } from \u0026quot;./car\u0026quot;;\nexport { type Car } from \u0026quot;./car\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003etype\u003c/code\u003e modifiers are not quite useful on their own - by default, module elision will still drop imports, and nothing forces you to make the distinction between \u003ccode\u003etype\u003c/code\u003e and plain imports and exports.\nSo TypeScript has the flag \u003ccode\u003e--importsNotUsedAsValues\u003c/code\u003e to make sure you use the \u003ccode\u003etype\u003c/code\u003e modifier, \u003ccode\u003e--preserveValueImports\u003c/code\u003e to prevent \u003cem\u003esome\u003c/em\u003e module elision behavior, and \u003ccode\u003e--isolatedModules\u003c/code\u003e to make sure that your TypeScript code works across different compilers.\nUnfortunately, understanding the fine details of those 3 flags is hard, and there are still some edge cases with unexpected behavior.\u003c/p\u003e\n\u003cp\u003eTypeScript 5.0 introduces a new option called \u003ccode\u003e--verbatimModuleSyntax\u003c/code\u003e to simplify the situation.\nThe rules are much simpler - any imports or exports without a \u003ccode\u003etype\u003c/code\u003e modifier are left around.\nAnything that uses the \u003ccode\u003etype\u003c/code\u003e modifier is dropped entirely.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-ts\"\u003e// Erased away entirely.\nimport type { A } from \u0026quot;a\u0026quot;;\n\n// Rewritten to \u0026#39;import { b } from \u0026quot;bcd\u0026quot;;\u0026#39;\nimport { b, type c, type d } from \u0026quot;bcd\u0026quot;;\n\n// Rewritten to \u0026#39;import {} from \u0026quot;xyz\u0026quot;;\u0026#39;\nimport { type xyz } from \u0026quot;xyz\u0026quot;;\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWith this new option, what you see is what you get.\u003c/p\u003e\n\u003cp\u003eThat does have some implications when it comes to module interop though.\nUnder this flag, ECMAScript \u003ccode\u003eimport\u003c/code\u003es and \u003ccode\u003eexport\u003c/code\u003es won\u0026#39;t be rewritten to \u003ccode\u003erequire\u003c/code\u003e calls when your settings or file extension implied a different module system.\nInstead, you\u0026#39;ll get an error.\nIf you need to emit code that uses \u003ccode\u003erequire\u003c/code\u003e and \u003ccode\u003emodule.exports\u003c/code\u003e, you\u0026#39;ll have to use TypeScript\u0026#39;s module syntax that predates ES2015:\u003c/p\u003e\n\u003ctable\u003e\n\u003cthead\u003e\n \u003ctr\u003e\n \u003cth\u003eInput TypeScript\u003c/th\u003e\n \u003cth\u003eOutput JavaScript\u003c/th\u003e\n \u003c/tr\u003e\n\u003c/thead\u003e\u003ctr\u003e\n\u003ctd\u003e\u003cpre\u003e\u003ccode class=\"language-ts\"\u003eimport foo = require(\u0026quot;foo\u0026quot;);\n\u003c/code\u003e\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\u003cpre\u003e\u003ccode class=\"language-js\"\u003econst foo = require(\u0026quot;foo\u0026quot;);\n\u003c/code\u003e\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e\u003cpre\u003e\u003ccode class=\"language-ts\"\u003efunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nexport = {\n foo,\n bar,\n baz\n};\n\u003c/code\u003e\u003c/pre\u003e\n\u003c/td\u003e\n\u003ctd\u003e\u003cpre\u003e\u003ccode class=\"language-js\"\u003efunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nmodule.exports = {\n foo,\n bar,\n baz\n};\n\u003c/code\u003e\u003c/pre\u003e\n\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/table\u003e\u003cp\u003eWhile this is a limitation, it does help make some issues more obvious.\nFor example, it\u0026#39;s very common to forget to set the \u003ca href=\"https://nodejs.org/api/packages.html#type\"\u003e\u003ccode\u003etype\u003c/code\u003e field in \u003ccode\u003epackage.json\u003c/code\u003e\u003c/a\u003e under \u003ccode\u003e--module node16\u003c/code\u003e.\nAs a result, developers would start writing CommonJS modules instead of ES modules without realizing it, giving surprising lookup rules and JavaScript output.\nThis new flag ensures that you\u0026#39;re intentional about the file type you\u0026#39;re using because the syntax is intentionally different.\u003c/p\u003e\n\u003cp\u003eBecause \u003ccode\u003e--verbatimModuleSyntax\u003c/code\u003e provides a more consistent story than \u003ccode\u003e--importsNotUsedAsValues\u003c/code\u003e and \u003ccode\u003e--preserveValueImports\u003c/code\u003e, those two existing flags are being deprecated in its favor.\u003c/p\u003e\n\u003cp\u003eFor more details, read up on \u003ca href=\"https://github.com/microsoft/TypeScript/pull/52203\"\u003ethe original pull request\u003c/a\u003e and \u003ca href=\"https://github.com/microsoft/TypeScript/issues/51479\"\u003eits proposal issue\u003c/a\u003e.\u003c/p\u003e\n"
1616
1762
  },
1617
1763
  "watch": {
1618
1764
  "description": "Watch input files.",
@@ -2433,22 +2579,25 @@
2433
2579
  "excludeDefinition": {
2434
2580
  "properties": {
2435
2581
  "exclude": {
2436
- "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.",
2582
+ "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 `/// \u003creference` 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.",
2437
2583
  "items": {
2438
2584
  "type": "string"
2439
2585
  },
2586
+ "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 `/// \u003creference` 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.",
2440
2587
  "type": [
2441
2588
  "array",
2442
2589
  "null"
2443
2590
  ],
2444
- "uniqueItems": true
2591
+ "uniqueItems": true,
2592
+ "x-intellij-html-description": "\u003cp\u003eSpecifies a list of files to be excluded from compilation. The \u0026#39;exclude\u0026#39; property only affects the files included via the \u0026#39;include\u0026#39; property and not the \u0026#39;files\u0026#39; property. Glob patterns require TypeScript version 2.0 or later.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eSpecifies an array of filenames or patterns that should be skipped when resolving \u003ca href=\"https://typescriptlang.org/tsconfig/#include\"\u003e\u003ccode\u003einclude\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eImportant\u003c/strong\u003e: \u003ccode\u003eexclude\u003c/code\u003e \u003cem\u003eonly\u003c/em\u003e changes which files are included as a result of the \u003ca href=\"https://typescriptlang.org/tsconfig/#include\"\u003e\u003ccode\u003einclude\u003c/code\u003e\u003c/a\u003e setting.\nA file specified by \u003ccode\u003eexclude\u003c/code\u003e can still become part of your codebase due to an \u003ccode\u003eimport\u003c/code\u003e statement in your code, a \u003ccode\u003etypes\u003c/code\u003e inclusion, a \u003ccode\u003e/// \u0026lt;reference\u003c/code\u003e directive, or being specified in the \u003ca href=\"https://typescriptlang.org/tsconfig/#files\"\u003e\u003ccode\u003efiles\u003c/code\u003e\u003c/a\u003e list.\u003c/p\u003e\n\u003cp\u003eIt is not a mechanism that \u003cstrong\u003eprevents\u003c/strong\u003e a file from being included in the codebase - it simply changes what the \u003ca href=\"https://typescriptlang.org/tsconfig/#include\"\u003e\u003ccode\u003einclude\u003c/code\u003e\u003c/a\u003e setting finds.\u003c/p\u003e\n"
2445
2593
  }
2446
2594
  }
2447
2595
  },
2448
2596
  "extendsDefinition": {
2449
2597
  "properties": {
2450
2598
  "extends": {
2451
- "description": "Path to base configuration file to inherit from (requires TypeScript version 2.1 or later), or array of base files, with the rightmost files having the greater priority (requires TypeScript version 5.0 or later).",
2599
+ "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.",
2600
+ "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.",
2452
2601
  "oneOf": [
2453
2602
  {
2454
2603
  "default": "",
@@ -2461,56 +2610,64 @@
2461
2610
  },
2462
2611
  "type": "array"
2463
2612
  }
2464
- ]
2613
+ ],
2614
+ "x-intellij-html-description": "\u003cp\u003ePath to base configuration file to inherit from. Requires TypeScript version 2.1 or later.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eThe value of \u003ccode\u003eextends\u003c/code\u003e is a string which contains a path to another configuration file to inherit from.\nThe path may use Node.js style resolution.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eIt\u0026#39;s worth noting that \u003ca href=\"https://typescriptlang.org/tsconfig/#files\"\u003e\u003ccode\u003efiles\u003c/code\u003e\u003c/a\u003e, \u003ca href=\"https://typescriptlang.org/tsconfig/#include\"\u003e\u003ccode\u003einclude\u003c/code\u003e\u003c/a\u003e, and \u003ca href=\"https://typescriptlang.org/tsconfig/#exclude\"\u003e\u003ccode\u003eexclude\u003c/code\u003e\u003c/a\u003e from the inheriting config file \u003cem\u003eoverwrite\u003c/em\u003e those from the\nbase config file, and that circularity between configuration files is not allowed.\u003c/p\u003e\n\u003cp\u003eCurrently, the only top-level property that is excluded from inheritance is \u003ca href=\"https://typescriptlang.org/tsconfig/#references\"\u003e\u003ccode\u003ereferences\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n\u003ch5\u003eExample\u003c/h5\u003e\n\u003cp\u003e\u003ccode\u003econfigs/base.json\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;noImplicitAny\u0026quot;: true,\n \u0026quot;strictNullChecks\u0026quot;: true\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003etsconfig.json\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;extends\u0026quot;: \u0026quot;./configs/base\u0026quot;,\n \u0026quot;files\u0026quot;: [\u0026quot;main.ts\u0026quot;, \u0026quot;supplemental.ts\u0026quot;]\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003etsconfig.nostrictnull.json\u003c/code\u003e:\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;extends\u0026quot;: \u0026quot;./tsconfig\u0026quot;,\n \u0026quot;compilerOptions\u0026quot;: {\n \u0026quot;strictNullChecks\u0026quot;: false\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eProperties with relative paths found in the configuration file, which aren\u0026#39;t excluded from inheritance, will be resolved relative to the configuration file they originated in.\u003c/p\u003e\n"
2465
2615
  }
2466
2616
  }
2467
2617
  },
2468
2618
  "filesDefinition": {
2469
2619
  "properties": {
2470
2620
  "files": {
2471
- "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.",
2621
+ "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).",
2472
2622
  "items": {
2473
2623
  "type": "string"
2474
2624
  },
2625
+ "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).",
2475
2626
  "type": [
2476
2627
  "array",
2477
2628
  "null"
2478
2629
  ],
2479
- "uniqueItems": true
2630
+ "uniqueItems": true,
2631
+ "x-intellij-html-description": "\u003cp\u003eIf no \u0026#39;files\u0026#39; or \u0026#39;include\u0026#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 \u0026#39;exclude\u0026#39;. When a \u0026#39;files\u0026#39; property is specified, only those files and those specified by \u0026#39;include\u0026#39; are included.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eSpecifies an allowlist of files to include in the program. An error occurs if any of the files can\u0026#39;t be found.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;compilerOptions\u0026quot;: {},\n \u0026quot;files\u0026quot;: [\n \u0026quot;core.ts\u0026quot;,\n \u0026quot;sys.ts\u0026quot;,\n \u0026quot;types.ts\u0026quot;,\n \u0026quot;scanner.ts\u0026quot;,\n \u0026quot;parser.ts\u0026quot;,\n \u0026quot;utilities.ts\u0026quot;,\n \u0026quot;binder.ts\u0026quot;,\n \u0026quot;checker.ts\u0026quot;,\n \u0026quot;tsc.ts\u0026quot;\n ]\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis is useful when you only have a small number of files and don\u0026#39;t need to use a glob to reference many files.\nIf you need that then use \u003ca href=\"https://typescriptlang.org/tsconfig/#include\"\u003e\u003ccode\u003einclude\u003c/code\u003e\u003c/a\u003e.\u003c/p\u003e\n"
2480
2632
  }
2481
2633
  }
2482
2634
  },
2483
2635
  "includeDefinition": {
2484
2636
  "properties": {
2485
2637
  "include": {
2486
- "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.",
2638
+ "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\u003c!-- 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``` --\u003e\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).",
2487
2639
  "items": {
2488
2640
  "type": "string"
2489
2641
  },
2642
+ "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\u003c!-- 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``` --\u003e\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).",
2490
2643
  "type": [
2491
2644
  "array",
2492
2645
  "null"
2493
2646
  ],
2494
- "uniqueItems": true
2647
+ "uniqueItems": true,
2648
+ "x-intellij-html-description": "\u003cp\u003eSpecifies a list of glob patterns that match files to be included in compilation. If no \u0026#39;files\u0026#39; or \u0026#39;include\u0026#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 \u0026#39;exclude\u0026#39;. Requires TypeScript version 2.0 or later.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eSpecifies an array of filenames or patterns to include in the program.\nThese filenames are resolved relative to the directory containing the \u003ccode\u003etsconfig.json\u003c/code\u003e file.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;include\u0026quot;: [\u0026quot;src/**/*\u0026quot;, \u0026quot;tests/**/*\u0026quot;]\n}\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWhich would include:\u003c/p\u003e\n\u003c!-- 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``` --\u003e\u003cpre\u003e\u003ccode\u003e.\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\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003einclude\u003c/code\u003e and \u003ccode\u003eexclude\u003c/code\u003e support wildcard characters to make glob patterns:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003e*\u003c/code\u003e matches zero or more characters (excluding directory separators)\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e?\u003c/code\u003e matches any one character (excluding directory separators)\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003e**/\u003c/code\u003e matches any directory nested to any level\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIf 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. \u003ccode\u003e.ts\u003c/code\u003e, \u003ccode\u003e.tsx\u003c/code\u003e, and \u003ccode\u003e.d.ts\u003c/code\u003e by default, with \u003ccode\u003e.js\u003c/code\u003e and \u003ccode\u003e.jsx\u003c/code\u003e if \u003ca href=\"https://typescriptlang.org/tsconfig/#allowJs\"\u003e\u003ccode\u003eallowJs\u003c/code\u003e\u003c/a\u003e is set to true).\u003c/p\u003e\n"
2495
2649
  }
2496
2650
  }
2497
2651
  },
2498
2652
  "referencesDefinition": {
2499
2653
  "properties": {
2500
2654
  "references": {
2501
- "description": "Referenced projects. Requires TypeScript version 3.0 or later.",
2655
+ "description": "Referenced projects. Requires TypeScript version 3.0 or later.\n\n---\n\nProject references are a way to structure your TypeScript programs into smaller pieces.\nUsing Project References can greatly improve build and editor interaction times, enforce logical separation between components, and organize your code in new and improved ways.\n\nYou can read more about how references works in the [Project References](https://typescriptlang.org/docs/handbook/project-references.html) section of the handbook",
2502
2656
  "items": {
2503
2657
  "description": "Project reference.",
2504
2658
  "properties": {
2505
2659
  "path": {
2506
2660
  "description": "Path to referenced tsconfig or to folder containing tsconfig.",
2661
+ "minLength": 1,
2507
2662
  "type": "string"
2508
2663
  }
2509
2664
  },
2510
2665
  "type": "object"
2511
2666
  },
2667
+ "markdownDescription": "Referenced projects. Requires TypeScript version 3.0 or later.\n\n---\n\nProject references are a way to structure your TypeScript programs into smaller pieces.\nUsing Project References can greatly improve build and editor interaction times, enforce logical separation between components, and organize your code in new and improved ways.\n\nYou can read more about how references works in the [Project References](https://typescriptlang.org/docs/handbook/project-references.html) section of the handbook",
2512
2668
  "type": "array",
2513
- "uniqueItems": true
2669
+ "uniqueItems": true,
2670
+ "x-intellij-html-description": "\u003cp\u003eReferenced projects. Requires TypeScript version 3.0 or later.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eProject references are a way to structure your TypeScript programs into smaller pieces.\nUsing Project References can greatly improve build and editor interaction times, enforce logical separation between components, and organize your code in new and improved ways.\u003c/p\u003e\n\u003cp\u003eYou can read more about how references works in the \u003ca href=\"https://typescriptlang.org/docs/handbook/project-references.html\"\u003eProject References\u003c/a\u003e section of the handbook\u003c/p\u003e\n"
2514
2671
  }
2515
2672
  }
2516
2673
  },
@@ -2633,7 +2790,7 @@
2633
2790
  },
2634
2791
  "moduleTypes": {
2635
2792
  "$ref": "#/definitions/tsNodeModuleTypes",
2636
- "description": "Override certain paths to be compiled and executed as CommonJS or ECMAScript modules.\nWhen overridden, the tsconfig \"module\" and package.json \"type\" fields are overridden, and\nthe file extension is ignored.\nThis is useful if you cannot use .mts, .cts, .mjs, or .cjs file extensions;\nit achieves the same effect.\n\nEach key is a glob pattern following the same rules as tsconfig's \"include\" array.\nWhen multiple patterns match the same file, the last pattern takes precedence.\n\n`cjs` overrides matches files to compile and execute as CommonJS.\n`esm` overrides matches files to compile and execute as native ECMAScript modules.\n`package` overrides either of the above to default behavior, which obeys package.json \"type\" and\ntsconfig.json \"module\" options."
2793
+ "description": "Override certain paths to be compiled and executed as CommonJS or ECMAScript modules.\nWhen overridden, the tsconfig \"module\" and package.json \"type\" fields are overridden.\nThis is useful because TypeScript files cannot use the .cjs nor .mjs file extensions;\nit achieves the same effect.\n\nEach key is a glob pattern following the same rules as tsconfig's \"include\" array.\nWhen multiple patterns match the same file, the last pattern takes precedence.\n\n`cjs` overrides matches files to compile and execute as CommonJS.\n`esm` overrides matches files to compile and execute as native ECMAScript modules.\n`package` overrides either of the above to default behavior, which obeys package.json \"type\" and\ntsconfig.json \"module\" options."
2637
2794
  },
2638
2795
  "preferTsExts": {
2639
2796
  "default": false,
@@ -2805,36 +2962,39 @@
2805
2962
  "description": "Settings for the watch mode in TypeScript.",
2806
2963
  "properties": {
2807
2964
  "excludeDirectories": {
2808
- "description": "Remove a list of directories from the watch process.",
2965
+ "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```",
2809
2966
  "items": {
2810
2967
  "type": "string"
2811
2968
  },
2812
- "markdownDescription": "Remove a list of directories from the watch process.\n\nSee more: https://www.typescriptlang.org/tsconfig#excludeDirectories",
2969
+ "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```",
2813
2970
  "type": [
2814
2971
  "array",
2815
2972
  "null"
2816
2973
  ],
2817
- "uniqueItems": true
2974
+ "uniqueItems": true,
2975
+ "x-intellij-html-description": "\u003cp\u003eYou can use \u003ca href=\"https://typescriptlang.org/tsconfig/#excludeFiles\"\u003e\u003ccode\u003eexcludeFiles\u003c/code\u003e\u003c/a\u003e to drastically reduce the number of files which are watched during \u003ccode\u003e--watch\u003c/code\u003e. This can be a useful way to reduce the number of open file which TypeScript tracks on Linux.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;watchOptions\u0026quot;: {\n \u0026quot;excludeDirectories\u0026quot;: [\u0026quot;**/node_modules\u0026quot;, \u0026quot;_build\u0026quot;, \u0026quot;temp/*\u0026quot;]\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n"
2818
2976
  },
2819
2977
  "excludeFiles": {
2820
- "description": "Remove a list of files from the watch mode's processing.",
2978
+ "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```",
2821
2979
  "items": {
2822
2980
  "type": "string"
2823
2981
  },
2824
- "markdownDescription": "Remove a list of files from the watch mode's processing.\n\nSee more: https://www.typescriptlang.org/tsconfig#excludeFiles",
2982
+ "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```",
2825
2983
  "type": [
2826
2984
  "array",
2827
2985
  "null"
2828
2986
  ],
2829
- "uniqueItems": true
2987
+ "uniqueItems": true,
2988
+ "x-intellij-html-description": "\u003cp\u003eYou can use \u003ccode\u003eexcludeFiles\u003c/code\u003e to remove a set of specific files from the files which are watched.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;watchOptions\u0026quot;: {\n \u0026quot;excludeFiles\u0026quot;: [\u0026quot;temp/file.ts\u0026quot;]\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n"
2830
2989
  },
2831
2990
  "fallbackPolling": {
2832
- "description": "Specify what approach the watcher should use if the system runs out of native file watchers.",
2833
- "markdownDescription": "Specify what approach the watcher should use if the system runs out of native file watchers.\n\nSee more: https://www.typescriptlang.org/tsconfig#fallbackPolling",
2991
+ "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.",
2992
+ "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.",
2834
2993
  "type": [
2835
2994
  "string",
2836
2995
  "null"
2837
- ]
2996
+ ],
2997
+ "x-intellij-html-description": "\u003cp\u003eWhen 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\u0026#39;t support native file watchers.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003efixedPollingInterval\u003c/code\u003e: Check every file for changes several times a second at a fixed interval.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003epriorityPollingInterval\u003c/code\u003e: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003edynamicPriorityPolling\u003c/code\u003e: Use a dynamic queue where less-frequently modified files will be checked less often.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003esynchronousWatchDirectory\u003c/code\u003e: Disable deferred watching on directories. Deferred watching is useful when lots of file changes might occur at once (e.g. a change in \u003ccode\u003enode_modules\u003c/code\u003e from running \u003ccode\u003enpm install\u003c/code\u003e), but you might want to disable it with this flag for some less-common setups.\u003c/li\u003e\n\u003c/ul\u003e\n"
2838
2998
  },
2839
2999
  "force": {
2840
3000
  "description": "~",
@@ -2844,28 +3004,31 @@
2844
3004
  ]
2845
3005
  },
2846
3006
  "synchronousWatchDirectory": {
2847
- "description": "Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively.",
2848
- "markdownDescription": "Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively.\n\nSee more: https://www.typescriptlang.org/tsconfig#synchronousWatchDirectory",
3007
+ "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```",
3008
+ "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```",
2849
3009
  "type": [
2850
3010
  "boolean",
2851
3011
  "null"
2852
- ]
3012
+ ],
3013
+ "x-intellij-html-description": "\u003cp\u003eSynchronously 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.\u003c/p\u003e\n\u003cpre\u003e\u003ccode class=\"language-json\"\u003e{\n \u0026quot;watchOptions\u0026quot;: {\n \u0026quot;synchronousWatchDirectory\u0026quot;: true\n }\n}\n\u003c/code\u003e\u003c/pre\u003e\n"
2853
3014
  },
2854
3015
  "watchDirectory": {
2855
- "description": "Specify how directories are watched on systems that lack recursive file-watching functionality.",
2856
- "markdownDescription": "Specify how directories are watched on systems that lack recursive file-watching functionality.\n\nSee more: https://www.typescriptlang.org/tsconfig#watchDirectory",
3016
+ "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.",
3017
+ "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.",
2857
3018
  "type": [
2858
3019
  "string",
2859
3020
  "null"
2860
- ]
3021
+ ],
3022
+ "x-intellij-html-description": "\u003cp\u003eThe strategy for how entire directory trees are watched under systems that lack recursive file-watching functionality.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003efixedPollingInterval\u003c/code\u003e: Check every directory for changes several times a second at a fixed interval.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003edynamicPriorityPolling\u003c/code\u003e: Use a dynamic queue where less-frequently modified directories will be checked less often.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003euseFsEvents\u003c/code\u003e (the default): Attempt to use the operating system/file system\u0026#39;s native events for directory changes.\u003c/li\u003e\n\u003c/ul\u003e\n"
2861
3023
  },
2862
3024
  "watchFile": {
2863
- "description": "Specify how the TypeScript watch mode works.",
2864
- "markdownDescription": "Specify how the TypeScript watch mode works.\n\nSee more: https://www.typescriptlang.org/tsconfig#watchFile",
3025
+ "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",
3026
+ "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",
2865
3027
  "type": [
2866
3028
  "string",
2867
3029
  "null"
2868
- ]
3030
+ ],
3031
+ "x-intellij-html-description": "\u003cp\u003eThe strategy for how individual files are watched.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003efixedPollingInterval\u003c/code\u003e: Check every file for changes several times a second at a fixed interval.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003epriorityPollingInterval\u003c/code\u003e: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003edynamicPriorityPolling\u003c/code\u003e: Use a dynamic queue where less-frequently modified files will be checked less often.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003euseFsEvents\u003c/code\u003e (the default): Attempt to use the operating system/file system\u0026#39;s native events for file changes.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003euseFsEventsOnParentDirectory\u003c/code\u003e: Attempt to use the operating system/file system\u0026#39;s native events to listen for changes on a file\u0026#39;s parent directory\u003c/li\u003e\n\u003c/ul\u003e\n"
2869
3032
  }
2870
3033
  },
2871
3034
  "type": [