schema.json

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "$comment": "Note that this schema uses 'null' in various places. The value of 'null' is UNDOCUMENTED (https://github.com/microsoft/TypeScript/pull/18058)",
  "allowTrailingCommas": true,
  "allOf": [
    {
      "$ref": "#/definitions/compilerOptionsDefinition"
    },
    {
      "$ref": "#/definitions/compileOnSaveDefinition"
    },
    {
      "$ref": "#/definitions/typeAcquisitionDefinition"
    },
    {
      "$ref": "#/definitions/extendsDefinition"
    },
    {
      "$ref": "#/definitions/watchOptionsDefinition"
    },
    {
      "$ref": "#/definitions/buildOptionsDefinition"
    },
    {
      "$ref": "#/definitions/tsNodeDefinition"
    },
    {
      "anyOf": [
        {
          "$ref": "#/definitions/filesDefinition"
        },
        {
          "$ref": "#/definitions/excludeDefinition"
        },
        {
          "$ref": "#/definitions/includeDefinition"
        },
        {
          "$ref": "#/definitions/referencesDefinition"
        }
      ]
    }
  ],
  "definitions": {
    "//": {
      "explainer": "https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#overview",
      "reference": "https://www.typescriptlang.org/tsconfig",
      "reference metadata": "https://github.com/microsoft/TypeScript-Website/blob/v2/packages/tsconfig-reference/scripts/tsconfigRules.ts"
    },
    "filesDefinition": {
      "properties": {
        "files": {
          "description": "If no 'files' or 'include' property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by 'exclude'. When a 'files' property is specified, only those files and those specified by 'include' are included.\n\n---\n\nSpecifies an allowlist of files to include in the program. An error occurs if any of the files can't be found.\n\n```json tsconfig\n{\n  \"compilerOptions\": {},\n  \"files\": [\n    \"core.ts\",\n    \"sys.ts\",\n    \"types.ts\",\n    \"scanner.ts\",\n    \"parser.ts\",\n    \"utilities.ts\",\n    \"binder.ts\",\n    \"checker.ts\",\n    \"tsc.ts\"\n  ]\n}\n```\n\nThis is useful when you only have a small number of files and don't need to use a glob to reference many files.\nIf you need that then use [`include`](https://typescriptlang.org/tsconfig/#include).",
          "type": [
            "array",
            "null"
          ],
          "uniqueItems": true,
          "items": {
            "type": "string"
          },
          "markdownDescription": "If no 'files' or 'include' property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by 'exclude'. When a 'files' property is specified, only those files and those specified by 'include' are included.\n\n---\n\nSpecifies an allowlist of files to include in the program. An error occurs if any of the files can't be found.\n\n```json tsconfig\n{\n  \"compilerOptions\": {},\n  \"files\": [\n    \"core.ts\",\n    \"sys.ts\",\n    \"types.ts\",\n    \"scanner.ts\",\n    \"parser.ts\",\n    \"utilities.ts\",\n    \"binder.ts\",\n    \"checker.ts\",\n    \"tsc.ts\"\n  ]\n}\n```\n\nThis is useful when you only have a small number of files and don't need to use a glob to reference many files.\nIf you need that then use [`include`](https://typescriptlang.org/tsconfig/#include).",
          "x-intellij-html-description": "<p>If no &#39;files&#39; or &#39;include&#39; property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by &#39;exclude&#39;. When a &#39;files&#39; property is specified, only those files and those specified by &#39;include&#39; are included.</p>\n<hr>\n<p>Specifies an allowlist of files to include in the program. An error occurs if any of the files can&#39;t be found.</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {},\n  &quot;files&quot;: [\n    &quot;core.ts&quot;,\n    &quot;sys.ts&quot;,\n    &quot;types.ts&quot;,\n    &quot;scanner.ts&quot;,\n    &quot;parser.ts&quot;,\n    &quot;utilities.ts&quot;,\n    &quot;binder.ts&quot;,\n    &quot;checker.ts&quot;,\n    &quot;tsc.ts&quot;\n  ]\n}\n</code></pre>\n<p>This is useful when you only have a small number of files and don&#39;t need to use a glob to reference many files.\nIf you need that then use <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a>.</p>\n"
        }
      }
    },
    "excludeDefinition": {
      "properties": {
        "exclude": {
          "description": "Specifies a list of files to be excluded from compilation. The 'exclude' property only affects the files included via the 'include' property and not the 'files' property. Glob patterns require TypeScript version 2.0 or later.\n\n---\n\nSpecifies an array of filenames or patterns that should be skipped when resolving [`include`](https://typescriptlang.org/tsconfig/#include).\n\n**Important**: `exclude` _only_ changes which files are included as a result of the [`include`](https://typescriptlang.org/tsconfig/#include) setting.\nA file specified by `exclude` can still become part of your codebase due to an `import` statement in your code, a `types` inclusion, a `/// <reference` directive, or being specified in the [`files`](https://typescriptlang.org/tsconfig/#files) list.\n\nIt is not a mechanism that **prevents** a file from being included in the codebase - it simply changes what the [`include`](https://typescriptlang.org/tsconfig/#include) setting finds.",
          "type": [
            "array",
            "null"
          ],
          "uniqueItems": true,
          "items": {
            "type": "string"
          },
          "markdownDescription": "Specifies a list of files to be excluded from compilation. The 'exclude' property only affects the files included via the 'include' property and not the 'files' property. Glob patterns require TypeScript version 2.0 or later.\n\n---\n\nSpecifies an array of filenames or patterns that should be skipped when resolving [`include`](https://typescriptlang.org/tsconfig/#include).\n\n**Important**: `exclude` _only_ changes which files are included as a result of the [`include`](https://typescriptlang.org/tsconfig/#include) setting.\nA file specified by `exclude` can still become part of your codebase due to an `import` statement in your code, a `types` inclusion, a `/// <reference` directive, or being specified in the [`files`](https://typescriptlang.org/tsconfig/#files) list.\n\nIt is not a mechanism that **prevents** a file from being included in the codebase - it simply changes what the [`include`](https://typescriptlang.org/tsconfig/#include) setting finds.",
          "x-intellij-html-description": "<p>Specifies a list of files to be excluded from compilation. The &#39;exclude&#39; property only affects the files included via the &#39;include&#39; property and not the &#39;files&#39; property. Glob patterns require TypeScript version 2.0 or later.</p>\n<hr>\n<p>Specifies an array of filenames or patterns that should be skipped when resolving <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a>.</p>\n<p><strong>Important</strong>: <code>exclude</code> <em>only</em> changes which files are included as a result of the <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a> setting.\nA file specified by <code>exclude</code> can still become part of your codebase due to an <code>import</code> statement in your code, a <code>types</code> inclusion, a <code>/// &lt;reference</code> directive, or being specified in the <a href=\"https://typescriptlang.org/tsconfig/#files\"><code>files</code></a> list.</p>\n<p>It is not a mechanism that <strong>prevents</strong> a file from being included in the codebase - it simply changes what the <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a> setting finds.</p>\n"
        }
      }
    },
    "includeDefinition": {
      "properties": {
        "include": {
          "description": "Specifies a list of glob patterns that match files to be included in compilation. If no 'files' or 'include' property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by 'exclude'. Requires TypeScript version 2.0 or later.\n\n---\n\nSpecifies an array of filenames or patterns to include in the program.\nThese filenames are resolved relative to the directory containing the `tsconfig.json` file.\n\n```json\n{\n  \"include\": [\"src/**/*\", \"tests/**/*\"]\n}\n```\n\nWhich would include:\n\n<!-- TODO: #135\n```diff\n  .\n- ├── scripts\n- │   ├── lint.ts\n- │   ├── update_deps.ts\n- │   └── utils.ts\n+ ├── src\n+ │   ├── client\n+ │   │    ├── index.ts\n+ │   │    └── utils.ts\n+ │   ├── server\n+ │   │    └── index.ts\n+ ├── tests\n+ │   ├── app.test.ts\n+ │   ├── utils.ts\n+ │   └── tests.d.ts\n- ├── package.json\n- ├── tsconfig.json\n- └── yarn.lock\n``` -->\n\n```\n.\n├── scripts                ⨯\n│   ├── lint.ts            ⨯\n│   ├── update_deps.ts     ⨯\n│   └── utils.ts           ⨯\n├── src                    ✓\n│   ├── client             ✓\n│   │    ├── index.ts      ✓\n│   │    └── utils.ts      ✓\n│   ├── server             ✓\n│   │    └── index.ts      ✓\n├── tests                  ✓\n│   ├── app.test.ts        ✓\n│   ├── utils.ts           ✓\n│   └── tests.d.ts         ✓\n├── package.json\n├── tsconfig.json\n└── yarn.lock\n```\n\n`include` and `exclude` support wildcard characters to make glob patterns:\n\n- `*` matches zero or more characters (excluding directory separators)\n- `?` matches any one character (excluding directory separators)\n- `**/` matches any directory nested to any level\n\nIf the last path segment in a pattern does not contain a file extension or wildcard character, then it is treated as a directory, and files with supported extensions inside that directory are included (e.g. `.ts`, `.tsx`, and `.d.ts` by default, with `.js` and `.jsx` if [`allowJs`](https://typescriptlang.org/tsconfig/#allowJs) is set to true).",
          "type": [
            "array",
            "null"
          ],
          "uniqueItems": true,
          "items": {
            "type": "string"
          },
          "markdownDescription": "Specifies a list of glob patterns that match files to be included in compilation. If no 'files' or 'include' property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by 'exclude'. Requires TypeScript version 2.0 or later.\n\n---\n\nSpecifies an array of filenames or patterns to include in the program.\nThese filenames are resolved relative to the directory containing the `tsconfig.json` file.\n\n```json\n{\n  \"include\": [\"src/**/*\", \"tests/**/*\"]\n}\n```\n\nWhich would include:\n\n<!-- TODO: #135\n```diff\n  .\n- ├── scripts\n- │   ├── lint.ts\n- │   ├── update_deps.ts\n- │   └── utils.ts\n+ ├── src\n+ │   ├── client\n+ │   │    ├── index.ts\n+ │   │    └── utils.ts\n+ │   ├── server\n+ │   │    └── index.ts\n+ ├── tests\n+ │   ├── app.test.ts\n+ │   ├── utils.ts\n+ │   └── tests.d.ts\n- ├── package.json\n- ├── tsconfig.json\n- └── yarn.lock\n``` -->\n\n```\n.\n├── scripts                ⨯\n│   ├── lint.ts            ⨯\n│   ├── update_deps.ts     ⨯\n│   └── utils.ts           ⨯\n├── src                    ✓\n│   ├── client             ✓\n│   │    ├── index.ts      ✓\n│   │    └── utils.ts      ✓\n│   ├── server             ✓\n│   │    └── index.ts      ✓\n├── tests                  ✓\n│   ├── app.test.ts        ✓\n│   ├── utils.ts           ✓\n│   └── tests.d.ts         ✓\n├── package.json\n├── tsconfig.json\n└── yarn.lock\n```\n\n`include` and `exclude` support wildcard characters to make glob patterns:\n\n- `*` matches zero or more characters (excluding directory separators)\n- `?` matches any one character (excluding directory separators)\n- `**/` matches any directory nested to any level\n\nIf the last path segment in a pattern does not contain a file extension or wildcard character, then it is treated as a directory, and files with supported extensions inside that directory are included (e.g. `.ts`, `.tsx`, and `.d.ts` by default, with `.js` and `.jsx` if [`allowJs`](https://typescriptlang.org/tsconfig/#allowJs) is set to true).",
          "x-intellij-html-description": "<p>Specifies a list of glob patterns that match files to be included in compilation. If no &#39;files&#39; or &#39;include&#39; property is present in a tsconfig.json, the compiler defaults to including all files in the containing directory and subdirectories except those specified by &#39;exclude&#39;. Requires TypeScript version 2.0 or later.</p>\n<hr>\n<p>Specifies an array of filenames or patterns to include in the program.\nThese filenames are resolved relative to the directory containing the <code>tsconfig.json</code> file.</p>\n<pre><code class=\"language-json\">{\n  &quot;include&quot;: [&quot;src/**/*&quot;, &quot;tests/**/*&quot;]\n}\n</code></pre>\n<p>Which would include:</p>\n<!-- TODO: #135\n```diff\n  .\n- ├── scripts\n- │   ├── lint.ts\n- │   ├── update_deps.ts\n- │   └── utils.ts\n+ ├── src\n+ │   ├── client\n+ │   │    ├── index.ts\n+ │   │    └── utils.ts\n+ │   ├── server\n+ │   │    └── index.ts\n+ ├── tests\n+ │   ├── app.test.ts\n+ │   ├── utils.ts\n+ │   └── tests.d.ts\n- ├── package.json\n- ├── tsconfig.json\n- └── yarn.lock\n``` --><pre><code>.\n├── scripts                ⨯\n│   ├── lint.ts            ⨯\n│   ├── update_deps.ts     ⨯\n│   └── utils.ts           ⨯\n├── src                    ✓\n│   ├── client             ✓\n│   │    ├── index.ts      ✓\n│   │    └── utils.ts      ✓\n│   ├── server             ✓\n│   │    └── index.ts      ✓\n├── tests                  ✓\n│   ├── app.test.ts        ✓\n│   ├── utils.ts           ✓\n│   └── tests.d.ts         ✓\n├── package.json\n├── tsconfig.json\n└── yarn.lock\n</code></pre>\n<p><code>include</code> and <code>exclude</code> support wildcard characters to make glob patterns:</p>\n<ul>\n<li><code>*</code> matches zero or more characters (excluding directory separators)</li>\n<li><code>?</code> matches any one character (excluding directory separators)</li>\n<li><code>**/</code> matches any directory nested to any level</li>\n</ul>\n<p>If the last path segment in a pattern does not contain a file extension or wildcard character, then it is treated as a directory, and files with supported extensions inside that directory are included (e.g. <code>.ts</code>, <code>.tsx</code>, and <code>.d.ts</code> by default, with <code>.js</code> and <code>.jsx</code> if <a href=\"https://typescriptlang.org/tsconfig/#allowJs\"><code>allowJs</code></a> is set to true).</p>\n"
        }
      }
    },
    "compileOnSaveDefinition": {
      "properties": {
        "compileOnSave": {
          "description": "Enable Compile-on-Save for this project.",
          "type": [
            "boolean",
            "null"
          ]
        }
      }
    },
    "extendsDefinition": {
      "properties": {
        "extends": {
          "description": "Path to base configuration file to inherit from. Requires TypeScript version 2.1 or later.\n\n---\n\nThe value of `extends` is a string which contains a path to another configuration file to inherit from.\nThe path may use Node.js style resolution.\n\nThe configuration from the base file are loaded first, then overridden by those in the inheriting config file. All relative paths found in the configuration file will be resolved relative to the configuration file they originated in.\n\nIt's worth noting that [`files`](https://typescriptlang.org/tsconfig/#files), [`include`](https://typescriptlang.org/tsconfig/#include), and [`exclude`](https://typescriptlang.org/tsconfig/#exclude) from the inheriting config file _overwrite_ those from the\nbase config file, and that circularity between configuration files is not allowed.\n\nCurrently, the only top-level property that is excluded from inheritance is [`references`](https://typescriptlang.org/tsconfig/#references).\n\n##### Example\n\n`configs/base.json`:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"noImplicitAny\": true,\n    \"strictNullChecks\": true\n  }\n}\n```\n\n`tsconfig.json`:\n\n```json tsconfig\n{\n  \"extends\": \"./configs/base\",\n  \"files\": [\"main.ts\", \"supplemental.ts\"]\n}\n```\n\n`tsconfig.nostrictnull.json`:\n\n```json tsconfig\n{\n  \"extends\": \"./tsconfig\",\n  \"compilerOptions\": {\n    \"strictNullChecks\": false\n  }\n}\n```\n\nProperties with relative paths found in the configuration file, which aren't excluded from inheritance, will be resolved relative to the configuration file they originated in.",
          "oneOf": [
            {
              "default": "",
              "type": "string"
            },
            {
              "default": [],
              "items": {
                "type": "string"
              },
              "type": "array"
            }
          ],
          "markdownDescription": "Path to base configuration file to inherit from. Requires TypeScript version 2.1 or later.\n\n---\n\nThe value of `extends` is a string which contains a path to another configuration file to inherit from.\nThe path may use Node.js style resolution.\n\nThe configuration from the base file are loaded first, then overridden by those in the inheriting config file. All relative paths found in the configuration file will be resolved relative to the configuration file they originated in.\n\nIt's worth noting that [`files`](https://typescriptlang.org/tsconfig/#files), [`include`](https://typescriptlang.org/tsconfig/#include), and [`exclude`](https://typescriptlang.org/tsconfig/#exclude) from the inheriting config file _overwrite_ those from the\nbase config file, and that circularity between configuration files is not allowed.\n\nCurrently, the only top-level property that is excluded from inheritance is [`references`](https://typescriptlang.org/tsconfig/#references).\n\n##### Example\n\n`configs/base.json`:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"noImplicitAny\": true,\n    \"strictNullChecks\": true\n  }\n}\n```\n\n`tsconfig.json`:\n\n```json tsconfig\n{\n  \"extends\": \"./configs/base\",\n  \"files\": [\"main.ts\", \"supplemental.ts\"]\n}\n```\n\n`tsconfig.nostrictnull.json`:\n\n```json tsconfig\n{\n  \"extends\": \"./tsconfig\",\n  \"compilerOptions\": {\n    \"strictNullChecks\": false\n  }\n}\n```\n\nProperties with relative paths found in the configuration file, which aren't excluded from inheritance, will be resolved relative to the configuration file they originated in.",
          "x-intellij-html-description": "<p>Path to base configuration file to inherit from. Requires TypeScript version 2.1 or later.</p>\n<hr>\n<p>The value of <code>extends</code> is a string which contains a path to another configuration file to inherit from.\nThe path may use Node.js style resolution.</p>\n<p>The configuration from the base file are loaded first, then overridden by those in the inheriting config file. All relative paths found in the configuration file will be resolved relative to the configuration file they originated in.</p>\n<p>It&#39;s worth noting that <a href=\"https://typescriptlang.org/tsconfig/#files\"><code>files</code></a>, <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a>, and <a href=\"https://typescriptlang.org/tsconfig/#exclude\"><code>exclude</code></a> from the inheriting config file <em>overwrite</em> those from the\nbase config file, and that circularity between configuration files is not allowed.</p>\n<p>Currently, the only top-level property that is excluded from inheritance is <a href=\"https://typescriptlang.org/tsconfig/#references\"><code>references</code></a>.</p>\n<h5>Example</h5>\n<p><code>configs/base.json</code>:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;noImplicitAny&quot;: true,\n    &quot;strictNullChecks&quot;: true\n  }\n}\n</code></pre>\n<p><code>tsconfig.json</code>:</p>\n<pre><code class=\"language-json\">{\n  &quot;extends&quot;: &quot;./configs/base&quot;,\n  &quot;files&quot;: [&quot;main.ts&quot;, &quot;supplemental.ts&quot;]\n}\n</code></pre>\n<p><code>tsconfig.nostrictnull.json</code>:</p>\n<pre><code class=\"language-json\">{\n  &quot;extends&quot;: &quot;./tsconfig&quot;,\n  &quot;compilerOptions&quot;: {\n    &quot;strictNullChecks&quot;: false\n  }\n}\n</code></pre>\n<p>Properties with relative paths found in the configuration file, which aren&#39;t excluded from inheritance, will be resolved relative to the configuration file they originated in.</p>\n"
        }
      }
    },
    "buildOptionsDefinition": {
      "properties": {
        "buildOptions": {
          "properties": {
            "dry": {
              "description": "~",
              "type": [
                "boolean",
                "null"
              ],
              "default": false
            },
            "force": {
              "description": "Build all projects, including those that appear to be up to date",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Build all projects, including those that appear to be up to date",
              "x-intellij-html-description": "<p>Build all projects, including those that appear to be up to date</p>\n"
            },
            "verbose": {
              "description": "Enable verbose logging",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Enable verbose logging",
              "x-intellij-html-description": "<p>Enable verbose logging</p>\n"
            },
            "incremental": {
              "description": "Tells TypeScript to save information about the project graph from the last compilation to files stored on disk. This\ncreates a series of `.tsbuildinfo` files in the same folder as your compilation output. They are not used by your\nJavaScript at runtime and can be safely deleted. You can read more about the flag in the [3.4 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#faster-subsequent-builds-with-the---incremental-flag).\n\nTo control which folders you want to the files to be built to, use the config option [`tsBuildInfoFile`](https://typescriptlang.org/tsconfig/#tsBuildInfoFile).",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Tells TypeScript to save information about the project graph from the last compilation to files stored on disk. This\ncreates a series of `.tsbuildinfo` files in the same folder as your compilation output. They are not used by your\nJavaScript at runtime and can be safely deleted. You can read more about the flag in the [3.4 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#faster-subsequent-builds-with-the---incremental-flag).\n\nTo control which folders you want to the files to be built to, use the config option [`tsBuildInfoFile`](https://typescriptlang.org/tsconfig/#tsBuildInfoFile).",
              "x-intellij-html-description": "<p>Tells TypeScript to save information about the project graph from the last compilation to files stored on disk. This\ncreates a series of <code>.tsbuildinfo</code> files in the same folder as your compilation output. They are not used by your\nJavaScript at runtime and can be safely deleted. You can read more about the flag in the <a href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#faster-subsequent-builds-with-the---incremental-flag\">3.4 release notes</a>.</p>\n<p>To control which folders you want to the files to be built to, use the config option <a href=\"https://typescriptlang.org/tsconfig/#tsBuildInfoFile\"><code>tsBuildInfoFile</code></a>.</p>\n"
            },
            "assumeChangesOnlyAffectDirectDependencies": {
              "description": "When this option is enabled, TypeScript will avoid rechecking/rebuilding all truly possibly-affected files, and only recheck/rebuild files that have changed as well as files that directly import them.\n\nThis can be considered a 'fast & loose' implementation of the watching algorithm, which can drastically reduce incremental rebuild times at the expense of having to run the full build occasionally to get all compiler error messages.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "When this option is enabled, TypeScript will avoid rechecking/rebuilding all truly possibly-affected files, and only recheck/rebuild files that have changed as well as files that directly import them.\n\nThis can be considered a 'fast & loose' implementation of the watching algorithm, which can drastically reduce incremental rebuild times at the expense of having to run the full build occasionally to get all compiler error messages.",
              "x-intellij-html-description": "<p>When this option is enabled, TypeScript will avoid rechecking/rebuilding all truly possibly-affected files, and only recheck/rebuild files that have changed as well as files that directly import them.</p>\n<p>This can be considered a &#39;fast &amp; loose&#39; implementation of the watching algorithm, which can drastically reduce incremental rebuild times at the expense of having to run the full build occasionally to get all compiler error messages.</p>\n"
            },
            "traceResolution": {
              "description": "When you are trying to debug why a module isn't being included.\nYou can set `traceResolution` to `true` to have TypeScript print information about its resolution process for each processed file.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "When you are trying to debug why a module isn't being included.\nYou can set `traceResolution` to `true` to have TypeScript print information about its resolution process for each processed file.",
              "x-intellij-html-description": "<p>When you are trying to debug why a module isn&#39;t being included.\nYou can set <code>traceResolution</code> to <code>true</code> to have TypeScript print information about its resolution process for each processed file.</p>\n"
            }
          }
        }
      }
    },
    "watchOptionsDefinition": {
      "properties": {
        "watchOptions": {
          "type": [
            "object",
            "null"
          ],
          "description": "Settings for the watch mode in TypeScript.",
          "properties": {
            "force": {
              "description": "~",
              "type": [
                "string",
                "null"
              ]
            },
            "watchFile": {
              "description": "The strategy for how individual files are watched.\n\n- `fixedPollingInterval`: Check every file for changes several times a second at a fixed interval.\n- `priorityPollingInterval`: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified files will be checked less often.\n- `useFsEvents` (the default): Attempt to use the operating system/file system's native events for file changes.\n- `useFsEventsOnParentDirectory`: Attempt to use the operating system/file system's native events to listen for changes on a file's parent directory",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "The strategy for how individual files are watched.\n\n- `fixedPollingInterval`: Check every file for changes several times a second at a fixed interval.\n- `priorityPollingInterval`: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified files will be checked less often.\n- `useFsEvents` (the default): Attempt to use the operating system/file system's native events for file changes.\n- `useFsEventsOnParentDirectory`: Attempt to use the operating system/file system's native events to listen for changes on a file's parent directory",
              "x-intellij-html-description": "<p>The strategy for how individual files are watched.</p>\n<ul>\n<li><code>fixedPollingInterval</code>: Check every file for changes several times a second at a fixed interval.</li>\n<li><code>priorityPollingInterval</code>: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.</li>\n<li><code>dynamicPriorityPolling</code>: Use a dynamic queue where less-frequently modified files will be checked less often.</li>\n<li><code>useFsEvents</code> (the default): Attempt to use the operating system/file system&#39;s native events for file changes.</li>\n<li><code>useFsEventsOnParentDirectory</code>: Attempt to use the operating system/file system&#39;s native events to listen for changes on a file&#39;s parent directory</li>\n</ul>\n"
            },
            "watchDirectory": {
              "description": "The strategy for how entire directory trees are watched under systems that lack recursive file-watching functionality.\n\n- `fixedPollingInterval`: Check every directory for changes several times a second at a fixed interval.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified directories will be checked less often.\n- `useFsEvents` (the default): Attempt to use the operating system/file system's native events for directory changes.",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "The strategy for how entire directory trees are watched under systems that lack recursive file-watching functionality.\n\n- `fixedPollingInterval`: Check every directory for changes several times a second at a fixed interval.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified directories will be checked less often.\n- `useFsEvents` (the default): Attempt to use the operating system/file system's native events for directory changes.",
              "x-intellij-html-description": "<p>The strategy for how entire directory trees are watched under systems that lack recursive file-watching functionality.</p>\n<ul>\n<li><code>fixedPollingInterval</code>: Check every directory for changes several times a second at a fixed interval.</li>\n<li><code>dynamicPriorityPolling</code>: Use a dynamic queue where less-frequently modified directories will be checked less often.</li>\n<li><code>useFsEvents</code> (the default): Attempt to use the operating system/file system&#39;s native events for directory changes.</li>\n</ul>\n"
            },
            "fallbackPolling": {
              "description": "When using file system events, this option specifies the polling strategy that gets used when the system runs out of native file watchers and/or doesn't support native file watchers.\n\n- `fixedPollingInterval`: Check every file for changes several times a second at a fixed interval.\n- `priorityPollingInterval`: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified files will be checked less often.\n- `synchronousWatchDirectory`: Disable deferred watching on directories. Deferred watching is useful when lots of file changes might occur at once (e.g. a change in `node_modules` from running `npm install`), but you might want to disable it with this flag for some less-common setups.",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "When using file system events, this option specifies the polling strategy that gets used when the system runs out of native file watchers and/or doesn't support native file watchers.\n\n- `fixedPollingInterval`: Check every file for changes several times a second at a fixed interval.\n- `priorityPollingInterval`: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.\n- `dynamicPriorityPolling`: Use a dynamic queue where less-frequently modified files will be checked less often.\n- `synchronousWatchDirectory`: Disable deferred watching on directories. Deferred watching is useful when lots of file changes might occur at once (e.g. a change in `node_modules` from running `npm install`), but you might want to disable it with this flag for some less-common setups.",
              "x-intellij-html-description": "<p>When using file system events, this option specifies the polling strategy that gets used when the system runs out of native file watchers and/or doesn&#39;t support native file watchers.</p>\n<ul>\n<li><code>fixedPollingInterval</code>: Check every file for changes several times a second at a fixed interval.</li>\n<li><code>priorityPollingInterval</code>: Check every file for changes several times a second, but use heuristics to check certain types of files less frequently than others.</li>\n<li><code>dynamicPriorityPolling</code>: Use a dynamic queue where less-frequently modified files will be checked less often.</li>\n<li><code>synchronousWatchDirectory</code>: Disable deferred watching on directories. Deferred watching is useful when lots of file changes might occur at once (e.g. a change in <code>node_modules</code> from running <code>npm install</code>), but you might want to disable it with this flag for some less-common setups.</li>\n</ul>\n"
            },
            "synchronousWatchDirectory": {
              "description": "Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively. Instead of giving a small timeout to allow for potentially multiple edits to occur on a file.\n\n```json tsconfig\n{\n  \"watchOptions\": {\n    \"synchronousWatchDirectory\": true\n  }\n}\n```",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively. Instead of giving a small timeout to allow for potentially multiple edits to occur on a file.\n\n```json tsconfig\n{\n  \"watchOptions\": {\n    \"synchronousWatchDirectory\": true\n  }\n}\n```",
              "x-intellij-html-description": "<p>Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively. Instead of giving a small timeout to allow for potentially multiple edits to occur on a file.</p>\n<pre><code class=\"language-json\">{\n  &quot;watchOptions&quot;: {\n    &quot;synchronousWatchDirectory&quot;: true\n  }\n}\n</code></pre>\n"
            },
            "excludeFiles": {
              "description": "You can use `excludeFiles` to remove a set of specific files from the files which are watched.\n\n```json tsconfig\n{\n  \"watchOptions\": {\n    \"excludeFiles\": [\"temp/file.ts\"]\n  }\n}\n```",
              "type": [
                "array",
                "null"
              ],
              "uniqueItems": true,
              "items": {
                "type": "string"
              },
              "markdownDescription": "You can use `excludeFiles` to remove a set of specific files from the files which are watched.\n\n```json tsconfig\n{\n  \"watchOptions\": {\n    \"excludeFiles\": [\"temp/file.ts\"]\n  }\n}\n```",
              "x-intellij-html-description": "<p>You can use <code>excludeFiles</code> to remove a set of specific files from the files which are watched.</p>\n<pre><code class=\"language-json\">{\n  &quot;watchOptions&quot;: {\n    &quot;excludeFiles&quot;: [&quot;temp/file.ts&quot;]\n  }\n}\n</code></pre>\n"
            },
            "excludeDirectories": {
              "description": "You can use [`excludeFiles`](https://typescriptlang.org/tsconfig/#excludeFiles) to drastically reduce the number of files which are watched during `--watch`. This can be a useful way to reduce the number of open file which TypeScript tracks on Linux.\n\n```json tsconfig\n{\n  \"watchOptions\": {\n    \"excludeDirectories\": [\"**/node_modules\", \"_build\", \"temp/*\"]\n  }\n}\n```",
              "type": [
                "array",
                "null"
              ],
              "uniqueItems": true,
              "items": {
                "type": "string"
              },
              "markdownDescription": "You can use [`excludeFiles`](https://typescriptlang.org/tsconfig/#excludeFiles) to drastically reduce the number of files which are watched during `--watch`. This can be a useful way to reduce the number of open file which TypeScript tracks on Linux.\n\n```json tsconfig\n{\n  \"watchOptions\": {\n    \"excludeDirectories\": [\"**/node_modules\", \"_build\", \"temp/*\"]\n  }\n}\n```",
              "x-intellij-html-description": "<p>You can use <a href=\"https://typescriptlang.org/tsconfig/#excludeFiles\"><code>excludeFiles</code></a> to drastically reduce the number of files which are watched during <code>--watch</code>. This can be a useful way to reduce the number of open file which TypeScript tracks on Linux.</p>\n<pre><code class=\"language-json\">{\n  &quot;watchOptions&quot;: {\n    &quot;excludeDirectories&quot;: [&quot;**/node_modules&quot;, &quot;_build&quot;, &quot;temp/*&quot;]\n  }\n}\n</code></pre>\n"
            }
          }
        }
      }
    },
    "compilerOptionsDefinition": {
      "properties": {
        "compilerOptions": {
          "type": [
            "object",
            "null"
          ],
          "description": "Instructs the TypeScript compiler how to compile .ts files.",
          "properties": {
            "allowArbitraryExtensions": {
              "description": "In TypeScript 5.0, when an import path ends in an extension that isn't a known JavaScript or TypeScript file extension, the compiler will look for a declaration file for that path in the form of `{file basename}.d.{extension}.ts`.\nFor example, if you are using a CSS loader in a bundler project, you might want to write (or generate) declaration files for those stylesheets:\n\n```css\n/* app.css */\n.cookie-banner {\n  display: none;\n}\n```\n\n```ts\n// app.d.css.ts\ndeclare const css: {\n  cookieBanner: string;\n};\nexport default css;\n```\n\n```ts\n// App.tsx\nimport styles from \"./app.css\";\n\nstyles.cookieBanner; // string\n```\n\nBy default, this import will raise an error to let you know that TypeScript doesn't understand this file type and your runtime might not support importing it.\nBut if you've configured your runtime or bundler to handle it, you can suppress the error with the new `--allowArbitraryExtensions` compiler option.\n\nNote that historically, a similar effect has often been achievable by adding a declaration file named `app.css.d.ts` instead of `app.d.css.ts` - however, this just worked through Node's `require` resolution rules for CommonJS.\nStrictly speaking, the former is interpreted as a declaration file for a JavaScript file named `app.css.js`.\nBecause relative files imports need to include extensions in Node's ESM support, TypeScript would error on our example in an ESM file under `--moduleResolution node16` or `nodenext`.\n\nFor more information, read up [the proposal for this feature](https://github.com/microsoft/TypeScript/issues/50133) and [its corresponding pull request](https://github.com/microsoft/TypeScript/pull/51435).",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "In TypeScript 5.0, when an import path ends in an extension that isn't a known JavaScript or TypeScript file extension, the compiler will look for a declaration file for that path in the form of `{file basename}.d.{extension}.ts`.\nFor example, if you are using a CSS loader in a bundler project, you might want to write (or generate) declaration files for those stylesheets:\n\n```css\n/* app.css */\n.cookie-banner {\n  display: none;\n}\n```\n\n```ts\n// app.d.css.ts\ndeclare const css: {\n  cookieBanner: string;\n};\nexport default css;\n```\n\n```ts\n// App.tsx\nimport styles from \"./app.css\";\n\nstyles.cookieBanner; // string\n```\n\nBy default, this import will raise an error to let you know that TypeScript doesn't understand this file type and your runtime might not support importing it.\nBut if you've configured your runtime or bundler to handle it, you can suppress the error with the new `--allowArbitraryExtensions` compiler option.\n\nNote that historically, a similar effect has often been achievable by adding a declaration file named `app.css.d.ts` instead of `app.d.css.ts` - however, this just worked through Node's `require` resolution rules for CommonJS.\nStrictly speaking, the former is interpreted as a declaration file for a JavaScript file named `app.css.js`.\nBecause relative files imports need to include extensions in Node's ESM support, TypeScript would error on our example in an ESM file under `--moduleResolution node16` or `nodenext`.\n\nFor more information, read up [the proposal for this feature](https://github.com/microsoft/TypeScript/issues/50133) and [its corresponding pull request](https://github.com/microsoft/TypeScript/pull/51435).",
              "x-intellij-html-description": "<p>In TypeScript 5.0, when an import path ends in an extension that isn&#39;t a known JavaScript or TypeScript file extension, the compiler will look for a declaration file for that path in the form of <code>{file basename}.d.{extension}.ts</code>.\nFor example, if you are using a CSS loader in a bundler project, you might want to write (or generate) declaration files for those stylesheets:</p>\n<pre><code class=\"language-css\">/* app.css */\n.cookie-banner {\n  display: none;\n}\n</code></pre>\n<pre><code class=\"language-ts\">// app.d.css.ts\ndeclare const css: {\n  cookieBanner: string;\n};\nexport default css;\n</code></pre>\n<pre><code class=\"language-ts\">// App.tsx\nimport styles from &quot;./app.css&quot;;\n\nstyles.cookieBanner; // string\n</code></pre>\n<p>By default, this import will raise an error to let you know that TypeScript doesn&#39;t understand this file type and your runtime might not support importing it.\nBut if you&#39;ve configured your runtime or bundler to handle it, you can suppress the error with the new <code>--allowArbitraryExtensions</code> compiler option.</p>\n<p>Note that historically, a similar effect has often been achievable by adding a declaration file named <code>app.css.d.ts</code> instead of <code>app.d.css.ts</code> - however, this just worked through Node&#39;s <code>require</code> resolution rules for CommonJS.\nStrictly speaking, the former is interpreted as a declaration file for a JavaScript file named <code>app.css.js</code>.\nBecause relative files imports need to include extensions in Node&#39;s ESM support, TypeScript would error on our example in an ESM file under <code>--moduleResolution node16</code> or <code>nodenext</code>.</p>\n<p>For more information, read up <a href=\"https://github.com/microsoft/TypeScript/issues/50133\">the proposal for this feature</a> and <a href=\"https://github.com/microsoft/TypeScript/pull/51435\">its corresponding pull request</a>.</p>\n"
            },
            "allowImportingTsExtensions": {
              "description": "`--allowImportingTsExtensions` allows TypeScript files to import each other with a TypeScript-specific extension like `.ts`, `.mts`, or `.tsx`.\n\nThis flag is only allowed when `--noEmit` or `--emitDeclarationOnly` is enabled, since these import paths would not be resolvable at runtime in JavaScript output files.\nThe expectation here is that your resolver (e.g. your bundler, a runtime, or some other tool) is going to make these imports between `.ts` files work.",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "`--allowImportingTsExtensions` allows TypeScript files to import each other with a TypeScript-specific extension like `.ts`, `.mts`, or `.tsx`.\n\nThis flag is only allowed when `--noEmit` or `--emitDeclarationOnly` is enabled, since these import paths would not be resolvable at runtime in JavaScript output files.\nThe expectation here is that your resolver (e.g. your bundler, a runtime, or some other tool) is going to make these imports between `.ts` files work.",
              "x-intellij-html-description": "<p><code>--allowImportingTsExtensions</code> allows TypeScript files to import each other with a TypeScript-specific extension like <code>.ts</code>, <code>.mts</code>, or <code>.tsx</code>.</p>\n<p>This flag is only allowed when <code>--noEmit</code> or <code>--emitDeclarationOnly</code> is enabled, since these import paths would not be resolvable at runtime in JavaScript output files.\nThe expectation here is that your resolver (e.g. your bundler, a runtime, or some other tool) is going to make these imports between <code>.ts</code> files work.</p>\n"
            },
            "charset": {
              "description": "In prior versions of TypeScript, this controlled what encoding was used when reading text files from disk.\nToday, TypeScript assumes UTF-8 encoding, but will correctly detect UTF-16 (BE and LE) or UTF-8 BOMs.",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "In prior versions of TypeScript, this controlled what encoding was used when reading text files from disk.\nToday, TypeScript assumes UTF-8 encoding, but will correctly detect UTF-16 (BE and LE) or UTF-8 BOMs.",
              "x-intellij-html-description": "<p>In prior versions of TypeScript, this controlled what encoding was used when reading text files from disk.\nToday, TypeScript assumes UTF-8 encoding, but will correctly detect UTF-16 (BE and LE) or UTF-8 BOMs.</p>\n"
            },
            "composite": {
              "description": "The `composite` option enforces certain constraints which make it possible for build tools (including TypeScript\nitself, under `--build` mode) to quickly determine if a project has been built yet.\n\nWhen this setting is on:\n\n- The [`rootDir`](https://typescriptlang.org/tsconfig/#rootDir) setting, if not explicitly set, defaults to the directory containing the `tsconfig.json` file.\n\n- All implementation files must be matched by an [`include`](https://typescriptlang.org/tsconfig/#include) pattern or listed in the [`files`](https://typescriptlang.org/tsconfig/#files) array. If this constraint is violated, `tsc` will inform you which files weren't specified.\n\n- [`declaration`](https://typescriptlang.org/tsconfig/#declaration) defaults to `true`\n\nYou can find documentation on TypeScript projects in [the handbook](https://www.typescriptlang.org/docs/handbook/project-references.html).",
              "type": [
                "boolean",
                "null"
              ],
              "default": true,
              "markdownDescription": "The `composite` option enforces certain constraints which make it possible for build tools (including TypeScript\nitself, under `--build` mode) to quickly determine if a project has been built yet.\n\nWhen this setting is on:\n\n- The [`rootDir`](https://typescriptlang.org/tsconfig/#rootDir) setting, if not explicitly set, defaults to the directory containing the `tsconfig.json` file.\n\n- All implementation files must be matched by an [`include`](https://typescriptlang.org/tsconfig/#include) pattern or listed in the [`files`](https://typescriptlang.org/tsconfig/#files) array. If this constraint is violated, `tsc` will inform you which files weren't specified.\n\n- [`declaration`](https://typescriptlang.org/tsconfig/#declaration) defaults to `true`\n\nYou can find documentation on TypeScript projects in [the handbook](https://www.typescriptlang.org/docs/handbook/project-references.html).",
              "x-intellij-html-description": "<p>The <code>composite</code> option enforces certain constraints which make it possible for build tools (including TypeScript\nitself, under <code>--build</code> mode) to quickly determine if a project has been built yet.</p>\n<p>When this setting is on:</p>\n<ul>\n<li><p>The <a href=\"https://typescriptlang.org/tsconfig/#rootDir\"><code>rootDir</code></a> setting, if not explicitly set, defaults to the directory containing the <code>tsconfig.json</code> file.</p>\n</li>\n<li><p>All implementation files must be matched by an <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a> pattern or listed in the <a href=\"https://typescriptlang.org/tsconfig/#files\"><code>files</code></a> array. If this constraint is violated, <code>tsc</code> will inform you which files weren&#39;t specified.</p>\n</li>\n<li><p><a href=\"https://typescriptlang.org/tsconfig/#declaration\"><code>declaration</code></a> defaults to <code>true</code></p>\n</li>\n</ul>\n<p>You can find documentation on TypeScript projects in <a href=\"https://www.typescriptlang.org/docs/handbook/project-references.html\">the handbook</a>.</p>\n"
            },
            "customConditions": {
              "description": "`--customConditions` takes a list of additional [conditions](https://nodejs.org/api/packages.html#nested-conditions) that should succeed when TypeScript resolves from an [`exports`](https://nodejs.org/api/packages.html#exports) or [`imports`](https://nodejs.org/api/packages.html#imports) field of a `package.json`.\nThese conditions are added to whatever existing conditions a resolver will use by default.\n\nFor example, when this field is set in a `tsconfig.json` as so:\n\n```jsonc\n{\n    \"compilerOptions\": {\n        \"target\": \"es2022\",\n        \"moduleResolution\": \"bundler\",\n        \"customConditions\": [\"my-condition\"]\n    }\n}\n```\n\nAny time an `exports` or `imports` field is referenced in `package.json`, TypeScript will consider conditions called `my-condition`.\n\nSo when importing from a package with the following `package.json`\n\n```jsonc\n{\n    // ...\n    \"exports\": {\n        \".\": {\n            \"my-condition\": \"./foo.mjs\",\n            \"node\": \"./bar.mjs\",\n            \"import\": \"./baz.mjs\",\n            \"require\": \"./biz.mjs\"\n        }\n    }\n}\n```\n\nTypeScript will try to look for files corresponding to `foo.mjs`.\n\nThis field is only valid under the `node16`, `nodenext`, and `bundler` options for [`--moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution).",
              "type": [
                "array",
                "null"
              ],
              "uniqueItems": true,
              "items": {
                "type": "string"
              },
              "markdownDescription": "`--customConditions` takes a list of additional [conditions](https://nodejs.org/api/packages.html#nested-conditions) that should succeed when TypeScript resolves from an [`exports`](https://nodejs.org/api/packages.html#exports) or [`imports`](https://nodejs.org/api/packages.html#imports) field of a `package.json`.\nThese conditions are added to whatever existing conditions a resolver will use by default.\n\nFor example, when this field is set in a `tsconfig.json` as so:\n\n```jsonc\n{\n    \"compilerOptions\": {\n        \"target\": \"es2022\",\n        \"moduleResolution\": \"bundler\",\n        \"customConditions\": [\"my-condition\"]\n    }\n}\n```\n\nAny time an `exports` or `imports` field is referenced in `package.json`, TypeScript will consider conditions called `my-condition`.\n\nSo when importing from a package with the following `package.json`\n\n```jsonc\n{\n    // ...\n    \"exports\": {\n        \".\": {\n            \"my-condition\": \"./foo.mjs\",\n            \"node\": \"./bar.mjs\",\n            \"import\": \"./baz.mjs\",\n            \"require\": \"./biz.mjs\"\n        }\n    }\n}\n```\n\nTypeScript will try to look for files corresponding to `foo.mjs`.\n\nThis field is only valid under the `node16`, `nodenext`, and `bundler` options for [`--moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution).",
              "x-intellij-html-description": "<p><code>--customConditions</code> takes a list of additional <a href=\"https://nodejs.org/api/packages.html#nested-conditions\">conditions</a> that should succeed when TypeScript resolves from an <a href=\"https://nodejs.org/api/packages.html#exports\"><code>exports</code></a> or <a href=\"https://nodejs.org/api/packages.html#imports\"><code>imports</code></a> field of a <code>package.json</code>.\nThese conditions are added to whatever existing conditions a resolver will use by default.</p>\n<p>For example, when this field is set in a <code>tsconfig.json</code> as so:</p>\n<pre><code class=\"language-jsonc\">{\n    &quot;compilerOptions&quot;: {\n        &quot;target&quot;: &quot;es2022&quot;,\n        &quot;moduleResolution&quot;: &quot;bundler&quot;,\n        &quot;customConditions&quot;: [&quot;my-condition&quot;]\n    }\n}\n</code></pre>\n<p>Any time an <code>exports</code> or <code>imports</code> field is referenced in <code>package.json</code>, TypeScript will consider conditions called <code>my-condition</code>.</p>\n<p>So when importing from a package with the following <code>package.json</code></p>\n<pre><code class=\"language-jsonc\">{\n    // ...\n    &quot;exports&quot;: {\n        &quot;.&quot;: {\n            &quot;my-condition&quot;: &quot;./foo.mjs&quot;,\n            &quot;node&quot;: &quot;./bar.mjs&quot;,\n            &quot;import&quot;: &quot;./baz.mjs&quot;,\n            &quot;require&quot;: &quot;./biz.mjs&quot;\n        }\n    }\n}\n</code></pre>\n<p>TypeScript will try to look for files corresponding to <code>foo.mjs</code>.</p>\n<p>This field is only valid under the <code>node16</code>, <code>nodenext</code>, and <code>bundler</code> options for <a href=\"https://typescriptlang.org/tsconfig/#moduleResolution\"><code>--moduleResolution</code></a>.</p>\n"
            },
            "declaration": {
              "description": "Generate `.d.ts` files for every TypeScript or JavaScript file inside your project.\nThese `.d.ts` files are type definition files which describe the external API of your module.\nWith `.d.ts` files, tools like TypeScript can provide intellisense and accurate types for un-typed code.\n\nWhen `declaration` is set to `true`, running the compiler with this TypeScript code:\n\n```ts twoslash\nexport let helloWorld = \"hi\";\n```\n\nWill generate an `index.js` file like this:\n\n```ts twoslash\n// @showEmit\nexport let helloWorld = \"hi\";\n```\n\nWith a corresponding `helloWorld.d.ts`:\n\n```ts twoslash\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\nexport let helloWorld = \"hi\";\n```\n\nWhen working with `.d.ts` files for JavaScript files you may want to use [`emitDeclarationOnly`](https://typescriptlang.org/tsconfig/#emitDeclarationOnly) or use [`outDir`](https://typescriptlang.org/tsconfig/#outDir) to ensure that the JavaScript files are not overwritten.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Generate `.d.ts` files for every TypeScript or JavaScript file inside your project.\nThese `.d.ts` files are type definition files which describe the external API of your module.\nWith `.d.ts` files, tools like TypeScript can provide intellisense and accurate types for un-typed code.\n\nWhen `declaration` is set to `true`, running the compiler with this TypeScript code:\n\n```ts twoslash\nexport let helloWorld = \"hi\";\n```\n\nWill generate an `index.js` file like this:\n\n```ts twoslash\n// @showEmit\nexport let helloWorld = \"hi\";\n```\n\nWith a corresponding `helloWorld.d.ts`:\n\n```ts twoslash\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\nexport let helloWorld = \"hi\";\n```\n\nWhen working with `.d.ts` files for JavaScript files you may want to use [`emitDeclarationOnly`](https://typescriptlang.org/tsconfig/#emitDeclarationOnly) or use [`outDir`](https://typescriptlang.org/tsconfig/#outDir) to ensure that the JavaScript files are not overwritten.",
              "x-intellij-html-description": "<p>Generate <code>.d.ts</code> files for every TypeScript or JavaScript file inside your project.\nThese <code>.d.ts</code> files are type definition files which describe the external API of your module.\nWith <code>.d.ts</code> files, tools like TypeScript can provide intellisense and accurate types for un-typed code.</p>\n<p>When <code>declaration</code> is set to <code>true</code>, running the compiler with this TypeScript code:</p>\n<pre><code class=\"language-ts\">export let helloWorld = &quot;hi&quot;;\n</code></pre>\n<p>Will generate an <code>index.js</code> file like this:</p>\n<pre><code class=\"language-ts\">// @showEmit\nexport let helloWorld = &quot;hi&quot;;\n</code></pre>\n<p>With a corresponding <code>helloWorld.d.ts</code>:</p>\n<pre><code class=\"language-ts\">// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\nexport let helloWorld = &quot;hi&quot;;\n</code></pre>\n<p>When working with <code>.d.ts</code> files for JavaScript files you may want to use <a href=\"https://typescriptlang.org/tsconfig/#emitDeclarationOnly\"><code>emitDeclarationOnly</code></a> or use <a href=\"https://typescriptlang.org/tsconfig/#outDir\"><code>outDir</code></a> to ensure that the JavaScript files are not overwritten.</p>\n"
            },
            "declarationDir": {
              "description": "Offers a way to configure the root directory for where declaration files are emitted.\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nwith this `tsconfig.json`:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"declaration\": true,\n    \"declarationDir\": \"./types\"\n  }\n}\n```\n\nWould place the d.ts for the `index.ts` in a `types` folder:\n\n```\nexample\n├── index.js\n├── index.ts\n├── package.json\n├── tsconfig.json\n└── types\n    └── index.d.ts\n```",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "Offers a way to configure the root directory for where declaration files are emitted.\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nwith this `tsconfig.json`:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"declaration\": true,\n    \"declarationDir\": \"./types\"\n  }\n}\n```\n\nWould place the d.ts for the `index.ts` in a `types` folder:\n\n```\nexample\n├── index.js\n├── index.ts\n├── package.json\n├── tsconfig.json\n└── types\n    └── index.d.ts\n```",
              "x-intellij-html-description": "<p>Offers a way to configure the root directory for where declaration files are emitted.</p>\n<pre><code>example\n├── index.ts\n├── package.json\n└── tsconfig.json\n</code></pre>\n<p>with this <code>tsconfig.json</code>:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;declaration&quot;: true,\n    &quot;declarationDir&quot;: &quot;./types&quot;\n  }\n}\n</code></pre>\n<p>Would place the d.ts for the <code>index.ts</code> in a <code>types</code> folder:</p>\n<pre><code>example\n├── index.js\n├── index.ts\n├── package.json\n├── tsconfig.json\n└── types\n    └── index.d.ts\n</code></pre>\n"
            },
            "diagnostics": {
              "description": "Used to output diagnostic information for debugging. This command is a subset of [`extendedDiagnostics`](https://typescriptlang.org/tsconfig/#extendedDiagnostics) which are more user-facing results, and easier to interpret.\n\nIf you have been asked by a TypeScript compiler engineer to give the results using this flag in a compile, in which there is no harm in using [`extendedDiagnostics`](https://typescriptlang.org/tsconfig/#extendedDiagnostics) instead.",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "Used to output diagnostic information for debugging. This command is a subset of [`extendedDiagnostics`](https://typescriptlang.org/tsconfig/#extendedDiagnostics) which are more user-facing results, and easier to interpret.\n\nIf you have been asked by a TypeScript compiler engineer to give the results using this flag in a compile, in which there is no harm in using [`extendedDiagnostics`](https://typescriptlang.org/tsconfig/#extendedDiagnostics) instead.",
              "x-intellij-html-description": "<p>Used to output diagnostic information for debugging. This command is a subset of <a href=\"https://typescriptlang.org/tsconfig/#extendedDiagnostics\"><code>extendedDiagnostics</code></a> which are more user-facing results, and easier to interpret.</p>\n<p>If you have been asked by a TypeScript compiler engineer to give the results using this flag in a compile, in which there is no harm in using <a href=\"https://typescriptlang.org/tsconfig/#extendedDiagnostics\"><code>extendedDiagnostics</code></a> instead.</p>\n"
            },
            "disableReferencedProjectLoad": {
              "description": "In multi-project TypeScript programs, TypeScript will load all of the available projects into memory in order to provide accurate results for editor responses which require a full knowledge graph like 'Find All References'.\n\nIf your project is large, you can use the flag `disableReferencedProjectLoad` to disable the automatic loading of all projects. Instead, projects are loaded dynamically as you open files through your editor.",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "In multi-project TypeScript programs, TypeScript will load all of the available projects into memory in order to provide accurate results for editor responses which require a full knowledge graph like 'Find All References'.\n\nIf your project is large, you can use the flag `disableReferencedProjectLoad` to disable the automatic loading of all projects. Instead, projects are loaded dynamically as you open files through your editor.",
              "x-intellij-html-description": "<p>In multi-project TypeScript programs, TypeScript will load all of the available projects into memory in order to provide accurate results for editor responses which require a full knowledge graph like &#39;Find All References&#39;.</p>\n<p>If your project is large, you can use the flag <code>disableReferencedProjectLoad</code> to disable the automatic loading of all projects. Instead, projects are loaded dynamically as you open files through your editor.</p>\n"
            },
            "noPropertyAccessFromIndexSignature": {
              "description": "This setting ensures consistency between accessing a field via the \"dot\" (`obj.key`) syntax, and \"indexed\" (`obj[\"key\"]`) and the way which the property is declared in the type.\n\nWithout this flag, TypeScript will allow you to use the dot syntax to access fields which are not defined:\n\n```ts twoslash\n// @errors: 4111\ndeclare function getSettings(): GameSettings;\n// ---cut---\ninterface GameSettings {\n  // Known up-front properties\n  speed: \"fast\" | \"medium\" | \"slow\";\n  quality: \"high\" | \"low\";\n\n  // Assume anything unknown to the interface\n  // is a string.\n  [key: string]: string;\n}\n\nconst settings = getSettings();\nsettings.speed;\n//       ^?\nsettings.quality;\n//       ^?\n\n// Unknown key accessors are allowed on\n// this object, and are `string`\nsettings.username;\n//       ^?\n```\n\nTurning the flag on will raise an error because the unknown field uses dot syntax instead of indexed syntax.\n\n```ts twoslash\n// @errors: 4111\n// @noPropertyAccessFromIndexSignature\ndeclare function getSettings(): GameSettings;\ninterface GameSettings {\n  speed: \"fast\" | \"medium\" | \"slow\";\n  quality: \"high\" | \"low\";\n  [key: string]: string;\n}\n// ---cut---\nconst settings = getSettings();\nsettings.speed;\nsettings.quality;\n\n// This would need to be settings[\"username\"];\nsettings.username;\n//       ^?\n```\n\nThe goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "This setting ensures consistency between accessing a field via the \"dot\" (`obj.key`) syntax, and \"indexed\" (`obj[\"key\"]`) and the way which the property is declared in the type.\n\nWithout this flag, TypeScript will allow you to use the dot syntax to access fields which are not defined:\n\n```ts twoslash\n// @errors: 4111\ndeclare function getSettings(): GameSettings;\n// ---cut---\ninterface GameSettings {\n  // Known up-front properties\n  speed: \"fast\" | \"medium\" | \"slow\";\n  quality: \"high\" | \"low\";\n\n  // Assume anything unknown to the interface\n  // is a string.\n  [key: string]: string;\n}\n\nconst settings = getSettings();\nsettings.speed;\n//       ^?\nsettings.quality;\n//       ^?\n\n// Unknown key accessors are allowed on\n// this object, and are `string`\nsettings.username;\n//       ^?\n```\n\nTurning the flag on will raise an error because the unknown field uses dot syntax instead of indexed syntax.\n\n```ts twoslash\n// @errors: 4111\n// @noPropertyAccessFromIndexSignature\ndeclare function getSettings(): GameSettings;\ninterface GameSettings {\n  speed: \"fast\" | \"medium\" | \"slow\";\n  quality: \"high\" | \"low\";\n  [key: string]: string;\n}\n// ---cut---\nconst settings = getSettings();\nsettings.speed;\nsettings.quality;\n\n// This would need to be settings[\"username\"];\nsettings.username;\n//       ^?\n```\n\nThe goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.",
              "x-intellij-html-description": "<p>This setting ensures consistency between accessing a field via the &quot;dot&quot; (<code>obj.key</code>) syntax, and &quot;indexed&quot; (<code>obj[&quot;key&quot;]</code>) and the way which the property is declared in the type.</p>\n<p>Without this flag, TypeScript will allow you to use the dot syntax to access fields which are not defined:</p>\n<pre><code class=\"language-ts\">// @errors: 4111\ndeclare function getSettings(): GameSettings;\n// ---cut---\ninterface GameSettings {\n  // Known up-front properties\n  speed: &quot;fast&quot; | &quot;medium&quot; | &quot;slow&quot;;\n  quality: &quot;high&quot; | &quot;low&quot;;\n\n  // Assume anything unknown to the interface\n  // is a string.\n  [key: string]: string;\n}\n\nconst settings = getSettings();\nsettings.speed;\n//       ^?\nsettings.quality;\n//       ^?\n\n// Unknown key accessors are allowed on\n// this object, and are `string`\nsettings.username;\n//       ^?\n</code></pre>\n<p>Turning the flag on will raise an error because the unknown field uses dot syntax instead of indexed syntax.</p>\n<pre><code class=\"language-ts\">// @errors: 4111\n// @noPropertyAccessFromIndexSignature\ndeclare function getSettings(): GameSettings;\ninterface GameSettings {\n  speed: &quot;fast&quot; | &quot;medium&quot; | &quot;slow&quot;;\n  quality: &quot;high&quot; | &quot;low&quot;;\n  [key: string]: string;\n}\n// ---cut---\nconst settings = getSettings();\nsettings.speed;\nsettings.quality;\n\n// This would need to be settings[&quot;username&quot;];\nsettings.username;\n//       ^?\n</code></pre>\n<p>The goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.</p>\n"
            },
            "emitBOM": {
              "description": "Controls whether TypeScript will emit a [byte order mark (BOM)](https://wikipedia.org/wiki/Byte_order_mark) when writing output files.\nSome runtime environments require a BOM to correctly interpret a JavaScript files; others require that it is not present.\nThe default value of `false` is generally best unless you have a reason to change it.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Controls whether TypeScript will emit a [byte order mark (BOM)](https://wikipedia.org/wiki/Byte_order_mark) when writing output files.\nSome runtime environments require a BOM to correctly interpret a JavaScript files; others require that it is not present.\nThe default value of `false` is generally best unless you have a reason to change it.",
              "x-intellij-html-description": "<p>Controls whether TypeScript will emit a <a href=\"https://wikipedia.org/wiki/Byte_order_mark\">byte order mark (BOM)</a> when writing output files.\nSome runtime environments require a BOM to correctly interpret a JavaScript files; others require that it is not present.\nThe default value of <code>false</code> is generally best unless you have a reason to change it.</p>\n"
            },
            "emitDeclarationOnly": {
              "description": "_Only_ emit `.d.ts` files; do not emit `.js` files.\n\nThis setting is useful in two cases:\n\n- You are using a transpiler other than TypeScript to generate your JavaScript.\n- You are using TypeScript to only generate `d.ts` files for your consumers.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "_Only_ emit `.d.ts` files; do not emit `.js` files.\n\nThis setting is useful in two cases:\n\n- You are using a transpiler other than TypeScript to generate your JavaScript.\n- You are using TypeScript to only generate `d.ts` files for your consumers.",
              "x-intellij-html-description": "<p><em>Only</em> emit <code>.d.ts</code> files; do not emit <code>.js</code> files.</p>\n<p>This setting is useful in two cases:</p>\n<ul>\n<li>You are using a transpiler other than TypeScript to generate your JavaScript.</li>\n<li>You are using TypeScript to only generate <code>d.ts</code> files for your consumers.</li>\n</ul>\n"
            },
            "erasableSyntaxOnly": {
              "description": "Node.js [supports running TypeScript files directly](https://nodejs.org/api/typescript.html#type-stripping) as of v23.6;\nhowever, only TypeScript-specific syntax that does not have runtime semantics are supported under this mode.\nIn other words, it must be possible to easily *erase* any TypeScript-specific syntax from a file, leaving behind a valid JavaScript file.\n\nThat means the following constructs are not supported:\n\n* `enum` declarations\n* `namespace`s and `module`s with runtime code\n* parameter properties in classes\n* Non-ECMAScript `import =` and `export =` assignments\n* `<prefix>`-style type assertions\n\n```ts\n// ❌ error: An `import ... = require(...)` alias\nimport foo = require(\"foo\");\n\n// ❌ error: A namespace with runtime code.\nnamespace container {\n    foo.method();\n\n    export type Bar = string;\n}\n\n// ❌ error: An `import =` alias\nimport Bar = container.Bar;\n\nclass Point {\n    // ❌ error: Parameter properties\n    constructor(public x: number, public y: number) { }\n}\n\n// ❌ error: An `export =` assignment.\nexport = Point;\n\n// ❌ error: An enum declaration.\nenum Direction {\n    Up,\n    Down,\n    Left,\n    Right,\n}\n\n// ❌ error: <prefix>-style type assertion.\nconst num = <number>1;\n```\n\nSimilar tools like [ts-blank-space](https://github.com/bloomberg/ts-blank-space) or [Amaro](https://github.com/nodejs/amaro) (the underlying library for type-stripping in Node.js) have the same limitations.\nThese tools will provide helpful error messages if they encounter code that doesn't meet these requirements, but you still won't find out your code doesn't work until you actually try to run it.\n\nThe `--erasableSyntaxOnly` flag will cause TypeScript to error on most TypeScript-specific constructs that have runtime behavior.\n\n```ts\nclass C {\n    constructor(public x: number) { }\n    //          ~~~~~~~~~~~~~~~~\n    // error! This syntax is not allowed when 'erasableSyntaxOnly' is enabled.\n    }\n}\n```\n\nTypically, you will want to combine this flag with the `--verbatimModuleSyntax`, which ensures that a module contains the appropriate import syntax, and that import elision does not take place.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Node.js [supports running TypeScript files directly](https://nodejs.org/api/typescript.html#type-stripping) as of v23.6;\nhowever, only TypeScript-specific syntax that does not have runtime semantics are supported under this mode.\nIn other words, it must be possible to easily *erase* any TypeScript-specific syntax from a file, leaving behind a valid JavaScript file.\n\nThat means the following constructs are not supported:\n\n* `enum` declarations\n* `namespace`s and `module`s with runtime code\n* parameter properties in classes\n* Non-ECMAScript `import =` and `export =` assignments\n* `<prefix>`-style type assertions\n\n```ts\n// ❌ error: An `import ... = require(...)` alias\nimport foo = require(\"foo\");\n\n// ❌ error: A namespace with runtime code.\nnamespace container {\n    foo.method();\n\n    export type Bar = string;\n}\n\n// ❌ error: An `import =` alias\nimport Bar = container.Bar;\n\nclass Point {\n    // ❌ error: Parameter properties\n    constructor(public x: number, public y: number) { }\n}\n\n// ❌ error: An `export =` assignment.\nexport = Point;\n\n// ❌ error: An enum declaration.\nenum Direction {\n    Up,\n    Down,\n    Left,\n    Right,\n}\n\n// ❌ error: <prefix>-style type assertion.\nconst num = <number>1;\n```\n\nSimilar tools like [ts-blank-space](https://github.com/bloomberg/ts-blank-space) or [Amaro](https://github.com/nodejs/amaro) (the underlying library for type-stripping in Node.js) have the same limitations.\nThese tools will provide helpful error messages if they encounter code that doesn't meet these requirements, but you still won't find out your code doesn't work until you actually try to run it.\n\nThe `--erasableSyntaxOnly` flag will cause TypeScript to error on most TypeScript-specific constructs that have runtime behavior.\n\n```ts\nclass C {\n    constructor(public x: number) { }\n    //          ~~~~~~~~~~~~~~~~\n    // error! This syntax is not allowed when 'erasableSyntaxOnly' is enabled.\n    }\n}\n```\n\nTypically, you will want to combine this flag with the `--verbatimModuleSyntax`, which ensures that a module contains the appropriate import syntax, and that import elision does not take place.",
              "x-intellij-html-description": "<p>Node.js <a href=\"https://nodejs.org/api/typescript.html#type-stripping\">supports running TypeScript files directly</a> as of v23.6;\nhowever, only TypeScript-specific syntax that does not have runtime semantics are supported under this mode.\nIn other words, it must be possible to easily <em>erase</em> any TypeScript-specific syntax from a file, leaving behind a valid JavaScript file.</p>\n<p>That means the following constructs are not supported:</p>\n<ul>\n<li><code>enum</code> declarations</li>\n<li><code>namespace</code>s and <code>module</code>s with runtime code</li>\n<li>parameter properties in classes</li>\n<li>Non-ECMAScript <code>import =</code> and <code>export =</code> assignments</li>\n<li><code>&lt;prefix&gt;</code>-style type assertions</li>\n</ul>\n<pre><code class=\"language-ts\">// ❌ error: An `import ... = require(...)` alias\nimport foo = require(&quot;foo&quot;);\n\n// ❌ error: A namespace with runtime code.\nnamespace container {\n    foo.method();\n\n    export type Bar = string;\n}\n\n// ❌ error: An `import =` alias\nimport Bar = container.Bar;\n\nclass Point {\n    // ❌ error: Parameter properties\n    constructor(public x: number, public y: number) { }\n}\n\n// ❌ error: An `export =` assignment.\nexport = Point;\n\n// ❌ error: An enum declaration.\nenum Direction {\n    Up,\n    Down,\n    Left,\n    Right,\n}\n\n// ❌ error: &lt;prefix&gt;-style type assertion.\nconst num = &lt;number&gt;1;\n</code></pre>\n<p>Similar tools like <a href=\"https://github.com/bloomberg/ts-blank-space\">ts-blank-space</a> or <a href=\"https://github.com/nodejs/amaro\">Amaro</a> (the underlying library for type-stripping in Node.js) have the same limitations.\nThese tools will provide helpful error messages if they encounter code that doesn&#39;t meet these requirements, but you still won&#39;t find out your code doesn&#39;t work until you actually try to run it.</p>\n<p>The <code>--erasableSyntaxOnly</code> flag will cause TypeScript to error on most TypeScript-specific constructs that have runtime behavior.</p>\n<pre><code class=\"language-ts\">class C {\n    constructor(public x: number) { }\n    //          ~~~~~~~~~~~~~~~~\n    // error! This syntax is not allowed when &#39;erasableSyntaxOnly&#39; is enabled.\n    }\n}\n</code></pre>\n<p>Typically, you will want to combine this flag with the <code>--verbatimModuleSyntax</code>, which ensures that a module contains the appropriate import syntax, and that import elision does not take place.</p>\n"
            },
            "exactOptionalPropertyTypes": {
              "description": "With exactOptionalPropertyTypes enabled, TypeScript applies stricter rules around how it handles properties on `type` or `interfaces` which have a `?` prefix.\n\nFor example, this interface declares that there is a property which can be one of two strings: 'dark' or 'light' or it should not be in the object.\n\n```ts\ninterface UserDefaults {\n  // The absence of a value represents 'system'\n  colorThemeOverride?: \"dark\" | \"light\";\n}\n```\n\nWithout this flag enabled, there are three values which you can set `colorThemeOverride` to be: \"dark\", \"light\" and `undefined`.\n\nSetting the value to `undefined` will allow most JavaScript runtime checks for the existence to fail, which is effectively falsy. However, this isn't quite accurate; `colorThemeOverride: undefined` is not the same as `colorThemeOverride` not being defined. For example, `\"colorThemeOverride\" in settings` would have different behavior with `undefined` as the key compared to not being defined.\n\n`exactOptionalPropertyTypes` makes TypeScript truly enforce the definition provided as an optional property:\n\n```ts twoslash\n// @exactOptionalPropertyTypes\n// @errors: 2322 2412\ninterface UserDefaults {\n  colorThemeOverride?: \"dark\" | \"light\";\n}\ndeclare function getUserSettings(): UserDefaults;\n// ---cut---\nconst settings = getUserSettings();\nsettings.colorThemeOverride = \"dark\";\nsettings.colorThemeOverride = \"light\";\n\n// But not:\nsettings.colorThemeOverride = undefined;\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "With exactOptionalPropertyTypes enabled, TypeScript applies stricter rules around how it handles properties on `type` or `interfaces` which have a `?` prefix.\n\nFor example, this interface declares that there is a property which can be one of two strings: 'dark' or 'light' or it should not be in the object.\n\n```ts\ninterface UserDefaults {\n  // The absence of a value represents 'system'\n  colorThemeOverride?: \"dark\" | \"light\";\n}\n```\n\nWithout this flag enabled, there are three values which you can set `colorThemeOverride` to be: \"dark\", \"light\" and `undefined`.\n\nSetting the value to `undefined` will allow most JavaScript runtime checks for the existence to fail, which is effectively falsy. However, this isn't quite accurate; `colorThemeOverride: undefined` is not the same as `colorThemeOverride` not being defined. For example, `\"colorThemeOverride\" in settings` would have different behavior with `undefined` as the key compared to not being defined.\n\n`exactOptionalPropertyTypes` makes TypeScript truly enforce the definition provided as an optional property:\n\n```ts twoslash\n// @exactOptionalPropertyTypes\n// @errors: 2322 2412\ninterface UserDefaults {\n  colorThemeOverride?: \"dark\" | \"light\";\n}\ndeclare function getUserSettings(): UserDefaults;\n// ---cut---\nconst settings = getUserSettings();\nsettings.colorThemeOverride = \"dark\";\nsettings.colorThemeOverride = \"light\";\n\n// But not:\nsettings.colorThemeOverride = undefined;\n```",
              "x-intellij-html-description": "<p>With exactOptionalPropertyTypes enabled, TypeScript applies stricter rules around how it handles properties on <code>type</code> or <code>interfaces</code> which have a <code>?</code> prefix.</p>\n<p>For example, this interface declares that there is a property which can be one of two strings: &#39;dark&#39; or &#39;light&#39; or it should not be in the object.</p>\n<pre><code class=\"language-ts\">interface UserDefaults {\n  // The absence of a value represents &#39;system&#39;\n  colorThemeOverride?: &quot;dark&quot; | &quot;light&quot;;\n}\n</code></pre>\n<p>Without this flag enabled, there are three values which you can set <code>colorThemeOverride</code> to be: &quot;dark&quot;, &quot;light&quot; and <code>undefined</code>.</p>\n<p>Setting the value to <code>undefined</code> will allow most JavaScript runtime checks for the existence to fail, which is effectively falsy. However, this isn&#39;t quite accurate; <code>colorThemeOverride: undefined</code> is not the same as <code>colorThemeOverride</code> not being defined. For example, <code>&quot;colorThemeOverride&quot; in settings</code> would have different behavior with <code>undefined</code> as the key compared to not being defined.</p>\n<p><code>exactOptionalPropertyTypes</code> makes TypeScript truly enforce the definition provided as an optional property:</p>\n<pre><code class=\"language-ts\">// @exactOptionalPropertyTypes\n// @errors: 2322 2412\ninterface UserDefaults {\n  colorThemeOverride?: &quot;dark&quot; | &quot;light&quot;;\n}\ndeclare function getUserSettings(): UserDefaults;\n// ---cut---\nconst settings = getUserSettings();\nsettings.colorThemeOverride = &quot;dark&quot;;\nsettings.colorThemeOverride = &quot;light&quot;;\n\n// But not:\nsettings.colorThemeOverride = undefined;\n</code></pre>\n"
            },
            "incremental": {
              "description": "Enable incremental compilation. Requires TypeScript version 3.4 or later.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "tsBuildInfoFile": {
              "description": "This setting lets you specify a file for storing incremental compilation information as a part of composite projects which enables faster\nbuilding of larger TypeScript codebases. You can read more about composite projects [in the handbook](https://typescriptlang.org/docs/handbook/project-references.html).\n\nThe default depends on a combination of other settings:\n\n- If `outFile` is set, the default is `<outFile>.tsbuildinfo`.\n- If `rootDir` and `outDir` are set, then the file is `<outDir>/<relative path to config from rootDir>/<config name>.tsbuildinfo`\n  For example, if `rootDir` is `src`, `outDir` is `dest`, and the config is\n  `./tsconfig.json`, then the default is `./tsconfig.tsbuildinfo`\n  as the relative path from `src/` to `./tsconfig.json` is `../`.\n- If `outDir` is set, then the default is `<outDir>/<config name>.tsbuildInfo`\n- Otherwise, the default is `<config name>.tsbuildInfo`",
              "default": ".tsbuildinfo",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "This setting lets you specify a file for storing incremental compilation information as a part of composite projects which enables faster\nbuilding of larger TypeScript codebases. You can read more about composite projects [in the handbook](https://typescriptlang.org/docs/handbook/project-references.html).\n\nThe default depends on a combination of other settings:\n\n- If `outFile` is set, the default is `<outFile>.tsbuildinfo`.\n- If `rootDir` and `outDir` are set, then the file is `<outDir>/<relative path to config from rootDir>/<config name>.tsbuildinfo`\n  For example, if `rootDir` is `src`, `outDir` is `dest`, and the config is\n  `./tsconfig.json`, then the default is `./tsconfig.tsbuildinfo`\n  as the relative path from `src/` to `./tsconfig.json` is `../`.\n- If `outDir` is set, then the default is `<outDir>/<config name>.tsbuildInfo`\n- Otherwise, the default is `<config name>.tsbuildInfo`",
              "x-intellij-html-description": "<p>This setting lets you specify a file for storing incremental compilation information as a part of composite projects which enables faster\nbuilding of larger TypeScript codebases. You can read more about composite projects <a href=\"https://typescriptlang.org/docs/handbook/project-references.html\">in the handbook</a>.</p>\n<p>The default depends on a combination of other settings:</p>\n<ul>\n<li>If <code>outFile</code> is set, the default is <code>&lt;outFile&gt;.tsbuildinfo</code>.</li>\n<li>If <code>rootDir</code> and <code>outDir</code> are set, then the file is <code>&lt;outDir&gt;/&lt;relative path to config from rootDir&gt;/&lt;config name&gt;.tsbuildinfo</code>\nFor example, if <code>rootDir</code> is <code>src</code>, <code>outDir</code> is <code>dest</code>, and the config is\n<code>./tsconfig.json</code>, then the default is <code>./tsconfig.tsbuildinfo</code>\nas the relative path from <code>src/</code> to <code>./tsconfig.json</code> is <code>../</code>.</li>\n<li>If <code>outDir</code> is set, then the default is <code>&lt;outDir&gt;/&lt;config name&gt;.tsbuildInfo</code></li>\n<li>Otherwise, the default is <code>&lt;config name&gt;.tsbuildInfo</code></li>\n</ul>\n"
            },
            "inlineSourceMap": {
              "description": "When set, instead of writing out a `.js.map` file to provide source maps, TypeScript will embed the source map content in the `.js` files.\nAlthough this results in larger JS files, it can be convenient in some scenarios.\nFor example, you might want to debug JS files on a webserver that doesn't allow `.map` files to be served.\n\nMutually exclusive with [`sourceMap`](https://typescriptlang.org/tsconfig/#sourceMap).\n\nFor example, with this TypeScript:\n\n```ts\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nConverts to this JavaScript:\n\n```ts twoslash\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nThen enable building it with `inlineSourceMap` enabled there is a comment at the bottom of the file which includes\na source-map for the file.\n\n```ts twoslash\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "When set, instead of writing out a `.js.map` file to provide source maps, TypeScript will embed the source map content in the `.js` files.\nAlthough this results in larger JS files, it can be convenient in some scenarios.\nFor example, you might want to debug JS files on a webserver that doesn't allow `.map` files to be served.\n\nMutually exclusive with [`sourceMap`](https://typescriptlang.org/tsconfig/#sourceMap).\n\nFor example, with this TypeScript:\n\n```ts\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nConverts to this JavaScript:\n\n```ts twoslash\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nThen enable building it with `inlineSourceMap` enabled there is a comment at the bottom of the file which includes\na source-map for the file.\n\n```ts twoslash\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```",
              "x-intellij-html-description": "<p>When set, instead of writing out a <code>.js.map</code> file to provide source maps, TypeScript will embed the source map content in the <code>.js</code> files.\nAlthough this results in larger JS files, it can be convenient in some scenarios.\nFor example, you might want to debug JS files on a webserver that doesn&#39;t allow <code>.map</code> files to be served.</p>\n<p>Mutually exclusive with <a href=\"https://typescriptlang.org/tsconfig/#sourceMap\"><code>sourceMap</code></a>.</p>\n<p>For example, with this TypeScript:</p>\n<pre><code class=\"language-ts\">const helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n<p>Converts to this JavaScript:</p>\n<pre><code class=\"language-ts\">// @showEmit\nconst helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n<p>Then enable building it with <code>inlineSourceMap</code> enabled there is a comment at the bottom of the file which includes\na source-map for the file.</p>\n<pre><code class=\"language-ts\">// @inlineSourceMap\n// @showEmit\nconst helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n"
            },
            "inlineSources": {
              "description": "When set, TypeScript will include the original content of the `.ts` file as an embedded string in the source map (using the source map's `sourcesContent` property).\nThis is often useful in the same cases as [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap).\n\nRequires either [`sourceMap`](https://typescriptlang.org/tsconfig/#sourceMap) or [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) to be set.\n\nFor example, with this TypeScript:\n\n```ts twoslash\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nBy default converts to this JavaScript:\n\n```ts twoslash\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nThen enable building it with `inlineSources` and [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) enabled there is a comment at the bottom of the file which includes\na source-map for the file.\nNote that the end is different from the example in [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) because the source-map now contains the original source code also.\n\n```ts twoslash\n// @inlineSources\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "When set, TypeScript will include the original content of the `.ts` file as an embedded string in the source map (using the source map's `sourcesContent` property).\nThis is often useful in the same cases as [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap).\n\nRequires either [`sourceMap`](https://typescriptlang.org/tsconfig/#sourceMap) or [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) to be set.\n\nFor example, with this TypeScript:\n\n```ts twoslash\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nBy default converts to this JavaScript:\n\n```ts twoslash\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```\n\nThen enable building it with `inlineSources` and [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) enabled there is a comment at the bottom of the file which includes\na source-map for the file.\nNote that the end is different from the example in [`inlineSourceMap`](https://typescriptlang.org/tsconfig/#inlineSourceMap) because the source-map now contains the original source code also.\n\n```ts twoslash\n// @inlineSources\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = \"hi\";\nconsole.log(helloWorld);\n```",
              "x-intellij-html-description": "<p>When set, TypeScript will include the original content of the <code>.ts</code> file as an embedded string in the source map (using the source map&#39;s <code>sourcesContent</code> property).\nThis is often useful in the same cases as <a href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"><code>inlineSourceMap</code></a>.</p>\n<p>Requires either <a href=\"https://typescriptlang.org/tsconfig/#sourceMap\"><code>sourceMap</code></a> or <a href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"><code>inlineSourceMap</code></a> to be set.</p>\n<p>For example, with this TypeScript:</p>\n<pre><code class=\"language-ts\">const helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n<p>By default converts to this JavaScript:</p>\n<pre><code class=\"language-ts\">// @showEmit\nconst helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n<p>Then enable building it with <code>inlineSources</code> and <a href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"><code>inlineSourceMap</code></a> enabled there is a comment at the bottom of the file which includes\na source-map for the file.\nNote that the end is different from the example in <a href=\"https://typescriptlang.org/tsconfig/#inlineSourceMap\"><code>inlineSourceMap</code></a> because the source-map now contains the original source code also.</p>\n<pre><code class=\"language-ts\">// @inlineSources\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = &quot;hi&quot;;\nconsole.log(helloWorld);\n</code></pre>\n"
            },
            "jsx": {
              "description": "Controls how JSX constructs are emitted in JavaScript files.\nThis only affects output of JS files that started in `.tsx` files.\n\n- `react-jsx`: Emit `.js` files with the JSX changed to `_jsx` calls optimized for production\n- `react-jsxdev`: Emit `.js` files with the JSX changed to `_jsx` calls for development only\n- `preserve`: Emit `.jsx` files with the JSX unchanged\n- `react-native`: Emit `.js` files with the JSX unchanged\n- `react`: Emit `.js` files with JSX changed to the equivalent `React.createElement` calls\n\n### For example\n\nThis sample code:\n\n```tsx\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nReact: `\"react-jsx\"`<sup>[[1]](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html)</sup>\n\n```tsx twoslash\ndeclare module JSX {\n  interface Element {}\n  interface IntrinsicElements {\n    [s: string]: any;\n  }\n}\n// @showEmit\n// @noErrors\n// @jsx: react-jsx\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nReact dev transform: `\"react-jsxdev\"`<sup>[[1]](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html)</sup>\n\n```tsx twoslash\ndeclare module JSX {\n  interface Element {}\n  interface IntrinsicElements {\n    [s: string]: any;\n  }\n}\n// @showEmit\n// @noErrors\n// @jsx: react-jsxdev\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nPreserve: `\"preserve\"`\n\n```tsx twoslash\ndeclare module JSX {\n  interface Element {}\n  interface IntrinsicElements {\n    [s: string]: any;\n  }\n}\n// @showEmit\n// @noErrors\n// @jsx: preserve\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nReact Native: `\"react-native\"`\n\n```tsx twoslash\ndeclare module JSX {\n  interface Element {}\n  interface IntrinsicElements {\n    [s: string]: any;\n  }\n}\n// @showEmit\n// @noErrors\n// @jsx: react-native\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\n\nLegacy React runtime: `\"react\"`\n\n```tsx twoslash\ndeclare module JSX {\n  interface Element {}\n  interface IntrinsicElements {\n    [s: string]: any;\n  }\n}\n// @showEmit\n// @noErrors\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nThis option can be used on a per-file basis too using an `@jsxRuntime` comment.\n\nAlways use the classic runtime (`\"react\"`) for this file:\n\n```tsx\n/* @jsxRuntime classic */\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```\n\nAlways use the automatic runtime (`\"react-jsx\"`) for this file:\n\n```tsx\n/* @jsxRuntime automatic */\nexport const HelloWorld = () => <h1>Hello world</h1>;\n```",
              "enum": [
                "preserve",
                "react",
                "react-jsx",
                "react-jsxdev",
                "react-native"
              ]
            },
            "reactNamespace": {
              "description": "Use [`jsxFactory`](https://typescriptlang.org/tsconfig/#jsxFactory) instead. Specify the object invoked for `createElement` when targeting `react` for TSX files.",
              "type": [
                "string",
                "null"
              ],
              "default": "React",
              "markdownDescription": "Use [`jsxFactory`](https://typescriptlang.org/tsconfig/#jsxFactory) instead. Specify the object invoked for `createElement` when targeting `react` for TSX files.",
              "x-intellij-html-description": "<p>Use <a href=\"https://typescriptlang.org/tsconfig/#jsxFactory\"><code>jsxFactory</code></a> instead. Specify the object invoked for <code>createElement</code> when targeting <code>react</code> for TSX files.</p>\n"
            },
            "jsxFactory": {
              "description": "Changes the function called in `.js` files when compiling JSX Elements using the classic JSX runtime.\nThe most common change is to use `\"h\"` or `\"preact.h\"` instead of the default `\"React.createElement\"` if using `preact`.\n\nFor example, this TSX file:\n\n```tsx\nimport { h } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nWith `jsxFactory: \"h\"` looks like:\n\n```tsx twoslash\n// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nThis option can be used on a per-file basis too similar to [Babel's `/** @jsx h */` directive](https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#custom).\n\n```tsx twoslash\n/** @jsx h */\nimport { h } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nThe factory chosen will also affect where the `JSX` namespace is looked up (for type checking information) before falling back to the global one.\n\nIf the factory is defined as `React.createElement` (the default), the compiler will check for `React.JSX` before checking for a global `JSX`. If the factory is defined as `h`, it will check for `h.JSX` before a global `JSX`.",
              "type": [
                "string",
                "null"
              ],
              "default": "React.createElement",
              "markdownDescription": "Changes the function called in `.js` files when compiling JSX Elements using the classic JSX runtime.\nThe most common change is to use `\"h\"` or `\"preact.h\"` instead of the default `\"React.createElement\"` if using `preact`.\n\nFor example, this TSX file:\n\n```tsx\nimport { h } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nWith `jsxFactory: \"h\"` looks like:\n\n```tsx twoslash\n// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nThis option can be used on a per-file basis too similar to [Babel's `/** @jsx h */` directive](https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#custom).\n\n```tsx twoslash\n/** @jsx h */\nimport { h } from \"preact\";\n\nconst HelloWorld = () => <div>Hello</div>;\n```\n\nThe factory chosen will also affect where the `JSX` namespace is looked up (for type checking information) before falling back to the global one.\n\nIf the factory is defined as `React.createElement` (the default), the compiler will check for `React.JSX` before checking for a global `JSX`. If the factory is defined as `h`, it will check for `h.JSX` before a global `JSX`.",
              "x-intellij-html-description": "<p>Changes the function called in <code>.js</code> files when compiling JSX Elements using the classic JSX runtime.\nThe most common change is to use <code>&quot;h&quot;</code> or <code>&quot;preact.h&quot;</code> instead of the default <code>&quot;React.createElement&quot;</code> if using <code>preact</code>.</p>\n<p>For example, this TSX file:</p>\n<pre><code class=\"language-tsx\">import { h } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; &lt;div&gt;Hello&lt;/div&gt;;\n</code></pre>\n<p>With <code>jsxFactory: &quot;h&quot;</code> looks like:</p>\n<pre><code class=\"language-tsx\">// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; &lt;div&gt;Hello&lt;/div&gt;;\n</code></pre>\n<p>This option can be used on a per-file basis too similar to <a href=\"https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#custom\">Babel&#39;s <code>/** @jsx h */</code> directive</a>.</p>\n<pre><code class=\"language-tsx\">/** @jsx h */\nimport { h } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; &lt;div&gt;Hello&lt;/div&gt;;\n</code></pre>\n<p>The factory chosen will also affect where the <code>JSX</code> namespace is looked up (for type checking information) before falling back to the global one.</p>\n<p>If the factory is defined as <code>React.createElement</code> (the default), the compiler will check for <code>React.JSX</code> before checking for a global <code>JSX</code>. If the factory is defined as <code>h</code>, it will check for <code>h.JSX</code> before a global <code>JSX</code>.</p>\n"
            },
            "jsxFragmentFactory": {
              "description": "Specify the JSX fragment factory function to use when targeting react JSX emit with [`jsxFactory`](https://typescriptlang.org/tsconfig/#jsxFactory) compiler option is specified, e.g. `Fragment`.\n\nFor example with this TSConfig:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"target\": \"esnext\",\n    \"module\": \"commonjs\",\n    \"jsx\": \"react\",\n    \"jsxFactory\": \"h\",\n    \"jsxFragmentFactory\": \"Fragment\"\n  }\n}\n```\n\nThis TSX file:\n\n```tsx\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n  <>\n    <div>Hello</div>\n  </>\n);\n```\n\nWould look like:\n\n```tsx twoslash\n// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @jsxFragmentFactory: Fragment\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n  <>\n    <div>Hello</div>\n  </>\n);\n```\n\nThis option can be used on a per-file basis too similar to [Babel's `/* @jsxFrag h */` directive](https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#fragments).\n\nFor example:\n\n```tsx twoslash\n/** @jsx h */\n/** @jsxFrag Fragment */\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n  <>\n    <div>Hello</div>\n  </>\n);\n```",
              "type": [
                "string",
                "null"
              ],
              "default": "React.Fragment",
              "markdownDescription": "Specify the JSX fragment factory function to use when targeting react JSX emit with [`jsxFactory`](https://typescriptlang.org/tsconfig/#jsxFactory) compiler option is specified, e.g. `Fragment`.\n\nFor example with this TSConfig:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"target\": \"esnext\",\n    \"module\": \"commonjs\",\n    \"jsx\": \"react\",\n    \"jsxFactory\": \"h\",\n    \"jsxFragmentFactory\": \"Fragment\"\n  }\n}\n```\n\nThis TSX file:\n\n```tsx\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n  <>\n    <div>Hello</div>\n  </>\n);\n```\n\nWould look like:\n\n```tsx twoslash\n// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @jsxFragmentFactory: Fragment\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n  <>\n    <div>Hello</div>\n  </>\n);\n```\n\nThis option can be used on a per-file basis too similar to [Babel's `/* @jsxFrag h */` directive](https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#fragments).\n\nFor example:\n\n```tsx twoslash\n/** @jsx h */\n/** @jsxFrag Fragment */\n\nimport { h, Fragment } from \"preact\";\n\nconst HelloWorld = () => (\n  <>\n    <div>Hello</div>\n  </>\n);\n```",
              "x-intellij-html-description": "<p>Specify the JSX fragment factory function to use when targeting react JSX emit with <a href=\"https://typescriptlang.org/tsconfig/#jsxFactory\"><code>jsxFactory</code></a> compiler option is specified, e.g. <code>Fragment</code>.</p>\n<p>For example with this TSConfig:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;target&quot;: &quot;esnext&quot;,\n    &quot;module&quot;: &quot;commonjs&quot;,\n    &quot;jsx&quot;: &quot;react&quot;,\n    &quot;jsxFactory&quot;: &quot;h&quot;,\n    &quot;jsxFragmentFactory&quot;: &quot;Fragment&quot;\n  }\n}\n</code></pre>\n<p>This TSX file:</p>\n<pre><code class=\"language-tsx\">import { h, Fragment } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; (\n  &lt;&gt;\n    &lt;div&gt;Hello&lt;/div&gt;\n  &lt;/&gt;\n);\n</code></pre>\n<p>Would look like:</p>\n<pre><code class=\"language-tsx\">// @showEmit\n// @showEmittedFile: index.js\n// @jsxFactory: h\n// @jsxFragmentFactory: Fragment\n// @noErrors\n// @target: esnext\n// @module: commonjs\n\nimport { h, Fragment } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; (\n  &lt;&gt;\n    &lt;div&gt;Hello&lt;/div&gt;\n  &lt;/&gt;\n);\n</code></pre>\n<p>This option can be used on a per-file basis too similar to <a href=\"https://babeljs.io/docs/en/babel-plugin-transform-react-jsx#fragments\">Babel&#39;s <code>/* @jsxFrag h */</code> directive</a>.</p>\n<p>For example:</p>\n<pre><code class=\"language-tsx\">/** @jsx h */\n/** @jsxFrag Fragment */\n\nimport { h, Fragment } from &quot;preact&quot;;\n\nconst HelloWorld = () =&gt; (\n  &lt;&gt;\n    &lt;div&gt;Hello&lt;/div&gt;\n  &lt;/&gt;\n);\n</code></pre>\n"
            },
            "jsxImportSource": {
              "description": "Declares the module specifier to be used for importing the `jsx` and `jsxs` factory functions when using [`jsx`](https://typescriptlang.org/tsconfig/#jsx) as `\"react-jsx\"` or `\"react-jsxdev\"` which were introduced in TypeScript 4.1.\n\nWith [React 17](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html) the library supports a new form of JSX transformation via a separate import.\n\nFor example with this code:\n\n```tsx\nimport React from \"react\";\n\nfunction App() {\n  return <h1>Hello World</h1>;\n}\n```\n\nUsing this TSConfig:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"target\": \"esnext\",\n    \"module\": \"commonjs\",\n    \"jsx\": \"react-jsx\"\n  }\n}\n```\n\nThe emitted JavaScript from TypeScript is:\n\n```tsx twoslash\n// @showEmit\n// @noErrors\n// @jsx: react-jsx\n// @module: commonjs\n// @target: esnext\ndeclare module JSX {\n  interface Element {}\n  interface IntrinsicElements {\n    [s: string]: any;\n  }\n}\nimport React from \"react\";\n\nfunction App() {\n  return <h1>Hello World</h1>;\n}\n```\n\nFor example if you wanted to use `\"jsxImportSource\": \"preact\"`, you need a tsconfig like:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"target\": \"esnext\",\n    \"module\": \"commonjs\",\n    \"jsx\": \"react-jsx\",\n    \"jsxImportSource\": \"preact\",\n    \"types\": [\"preact\"]\n  }\n}\n```\n\nWhich generates code like:\n\n```tsx twoslash\n// @showEmit\n// @jsxImportSource: preact\n// @types: preact\n// @jsx: react-jsx\n// @target: esnext\n// @module: commonjs\n// @noErrors\n\nexport function App() {\n  return <h1>Hello World</h1>;\n}\n```\n\nAlternatively, you can use a per-file pragma to set this option, for example:\n\n```tsx\n/** @jsxImportSource preact */\n\nexport function App() {\n  return <h1>Hello World</h1>;\n}\n```\n\nWould add `preact/jsx-runtime` as an import for the `_jsx` factory.\n\n_Note:_ In order for this to work like you would expect, your `tsx` file must include an `export` or `import` so that it is considered a module.",
              "type": [
                "string",
                "null"
              ],
              "default": "react",
              "markdownDescription": "Declares the module specifier to be used for importing the `jsx` and `jsxs` factory functions when using [`jsx`](https://typescriptlang.org/tsconfig/#jsx) as `\"react-jsx\"` or `\"react-jsxdev\"` which were introduced in TypeScript 4.1.\n\nWith [React 17](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html) the library supports a new form of JSX transformation via a separate import.\n\nFor example with this code:\n\n```tsx\nimport React from \"react\";\n\nfunction App() {\n  return <h1>Hello World</h1>;\n}\n```\n\nUsing this TSConfig:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"target\": \"esnext\",\n    \"module\": \"commonjs\",\n    \"jsx\": \"react-jsx\"\n  }\n}\n```\n\nThe emitted JavaScript from TypeScript is:\n\n```tsx twoslash\n// @showEmit\n// @noErrors\n// @jsx: react-jsx\n// @module: commonjs\n// @target: esnext\ndeclare module JSX {\n  interface Element {}\n  interface IntrinsicElements {\n    [s: string]: any;\n  }\n}\nimport React from \"react\";\n\nfunction App() {\n  return <h1>Hello World</h1>;\n}\n```\n\nFor example if you wanted to use `\"jsxImportSource\": \"preact\"`, you need a tsconfig like:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"target\": \"esnext\",\n    \"module\": \"commonjs\",\n    \"jsx\": \"react-jsx\",\n    \"jsxImportSource\": \"preact\",\n    \"types\": [\"preact\"]\n  }\n}\n```\n\nWhich generates code like:\n\n```tsx twoslash\n// @showEmit\n// @jsxImportSource: preact\n// @types: preact\n// @jsx: react-jsx\n// @target: esnext\n// @module: commonjs\n// @noErrors\n\nexport function App() {\n  return <h1>Hello World</h1>;\n}\n```\n\nAlternatively, you can use a per-file pragma to set this option, for example:\n\n```tsx\n/** @jsxImportSource preact */\n\nexport function App() {\n  return <h1>Hello World</h1>;\n}\n```\n\nWould add `preact/jsx-runtime` as an import for the `_jsx` factory.\n\n_Note:_ In order for this to work like you would expect, your `tsx` file must include an `export` or `import` so that it is considered a module.",
              "x-intellij-html-description": "<p>Declares the module specifier to be used for importing the <code>jsx</code> and <code>jsxs</code> factory functions when using <a href=\"https://typescriptlang.org/tsconfig/#jsx\"><code>jsx</code></a> as <code>&quot;react-jsx&quot;</code> or <code>&quot;react-jsxdev&quot;</code> which were introduced in TypeScript 4.1.</p>\n<p>With <a href=\"https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html\">React 17</a> the library supports a new form of JSX transformation via a separate import.</p>\n<p>For example with this code:</p>\n<pre><code class=\"language-tsx\">import React from &quot;react&quot;;\n\nfunction App() {\n  return &lt;h1&gt;Hello World&lt;/h1&gt;;\n}\n</code></pre>\n<p>Using this TSConfig:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;target&quot;: &quot;esnext&quot;,\n    &quot;module&quot;: &quot;commonjs&quot;,\n    &quot;jsx&quot;: &quot;react-jsx&quot;\n  }\n}\n</code></pre>\n<p>The emitted JavaScript from TypeScript is:</p>\n<pre><code class=\"language-tsx\">// @showEmit\n// @noErrors\n// @jsx: react-jsx\n// @module: commonjs\n// @target: esnext\ndeclare module JSX {\n  interface Element {}\n  interface IntrinsicElements {\n    [s: string]: any;\n  }\n}\nimport React from &quot;react&quot;;\n\nfunction App() {\n  return &lt;h1&gt;Hello World&lt;/h1&gt;;\n}\n</code></pre>\n<p>For example if you wanted to use <code>&quot;jsxImportSource&quot;: &quot;preact&quot;</code>, you need a tsconfig like:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;target&quot;: &quot;esnext&quot;,\n    &quot;module&quot;: &quot;commonjs&quot;,\n    &quot;jsx&quot;: &quot;react-jsx&quot;,\n    &quot;jsxImportSource&quot;: &quot;preact&quot;,\n    &quot;types&quot;: [&quot;preact&quot;]\n  }\n}\n</code></pre>\n<p>Which generates code like:</p>\n<pre><code class=\"language-tsx\">// @showEmit\n// @jsxImportSource: preact\n// @types: preact\n// @jsx: react-jsx\n// @target: esnext\n// @module: commonjs\n// @noErrors\n\nexport function App() {\n  return &lt;h1&gt;Hello World&lt;/h1&gt;;\n}\n</code></pre>\n<p>Alternatively, you can use a per-file pragma to set this option, for example:</p>\n<pre><code class=\"language-tsx\">/** @jsxImportSource preact */\n\nexport function App() {\n  return &lt;h1&gt;Hello World&lt;/h1&gt;;\n}\n</code></pre>\n<p>Would add <code>preact/jsx-runtime</code> as an import for the <code>_jsx</code> factory.</p>\n<p><em>Note:</em> In order for this to work like you would expect, your <code>tsx</code> file must include an <code>export</code> or <code>import</code> so that it is considered a module.</p>\n"
            },
            "listFiles": {
              "description": "Print names of files part of the compilation. This is useful when you are not sure that TypeScript has\nincluded a file you expected.\n\nFor example:\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nWith:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"listFiles\": true\n  }\n}\n```\n\nWould echo paths like:\n\n```\n$ npm run tsc\npath/to/example/node_modules/typescript/lib/lib.d.ts\npath/to/example/node_modules/typescript/lib/lib.es5.d.ts\npath/to/example/node_modules/typescript/lib/lib.dom.d.ts\npath/to/example/node_modules/typescript/lib/lib.webworker.importscripts.d.ts\npath/to/example/node_modules/typescript/lib/lib.scripthost.d.ts\npath/to/example/index.ts\n```\n\nNote if using TypeScript 4.2, prefer [`explainFiles`](https://typescriptlang.org/tsconfig/#explainFiles) which offers an explanation of why a file was added too.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Print names of files part of the compilation. This is useful when you are not sure that TypeScript has\nincluded a file you expected.\n\nFor example:\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nWith:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"listFiles\": true\n  }\n}\n```\n\nWould echo paths like:\n\n```\n$ npm run tsc\npath/to/example/node_modules/typescript/lib/lib.d.ts\npath/to/example/node_modules/typescript/lib/lib.es5.d.ts\npath/to/example/node_modules/typescript/lib/lib.dom.d.ts\npath/to/example/node_modules/typescript/lib/lib.webworker.importscripts.d.ts\npath/to/example/node_modules/typescript/lib/lib.scripthost.d.ts\npath/to/example/index.ts\n```\n\nNote if using TypeScript 4.2, prefer [`explainFiles`](https://typescriptlang.org/tsconfig/#explainFiles) which offers an explanation of why a file was added too.",
              "x-intellij-html-description": "<p>Print names of files part of the compilation. This is useful when you are not sure that TypeScript has\nincluded a file you expected.</p>\n<p>For example:</p>\n<pre><code>example\n├── index.ts\n├── package.json\n└── tsconfig.json\n</code></pre>\n<p>With:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;listFiles&quot;: true\n  }\n}\n</code></pre>\n<p>Would echo paths like:</p>\n<pre><code>$ npm run tsc\npath/to/example/node_modules/typescript/lib/lib.d.ts\npath/to/example/node_modules/typescript/lib/lib.es5.d.ts\npath/to/example/node_modules/typescript/lib/lib.dom.d.ts\npath/to/example/node_modules/typescript/lib/lib.webworker.importscripts.d.ts\npath/to/example/node_modules/typescript/lib/lib.scripthost.d.ts\npath/to/example/index.ts\n</code></pre>\n<p>Note if using TypeScript 4.2, prefer <a href=\"https://typescriptlang.org/tsconfig/#explainFiles\"><code>explainFiles</code></a> which offers an explanation of why a file was added too.</p>\n"
            },
            "mapRoot": {
              "description": "Specify the location where debugger should locate map files instead of generated locations.\nThis string is treated verbatim inside the source-map, for example:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"sourceMap\": true,\n    \"mapRoot\": \"https://my-website.com/debug/sourcemaps/\"\n  }\n}\n```\n\nWould declare that `index.js` will have sourcemaps at `https://my-website.com/debug/sourcemaps/index.js.map`.",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "Specify the location where debugger should locate map files instead of generated locations.\nThis string is treated verbatim inside the source-map, for example:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"sourceMap\": true,\n    \"mapRoot\": \"https://my-website.com/debug/sourcemaps/\"\n  }\n}\n```\n\nWould declare that `index.js` will have sourcemaps at `https://my-website.com/debug/sourcemaps/index.js.map`.",
              "x-intellij-html-description": "<p>Specify the location where debugger should locate map files instead of generated locations.\nThis string is treated verbatim inside the source-map, for example:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;sourceMap&quot;: true,\n    &quot;mapRoot&quot;: &quot;https://my-website.com/debug/sourcemaps/&quot;\n  }\n}\n</code></pre>\n<p>Would declare that <code>index.js</code> will have sourcemaps at <code>https://my-website.com/debug/sourcemaps/index.js.map</code>.</p>\n"
            },
            "module": {
              "description": "Sets the module system for the program. See the [theory behind TypeScript’s `module` option](https://typescriptlang.org/docs/handbook/modules/theory.html#the-module-output-format) and [its reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#the-module-compiler-option) for more information. You very likely want `\"nodenext\"` for modern Node.js projects and `preserve` or `esnext` for code that will be bundled.\n\nChanging `module` affects [`moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution) which [also has a reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option).\n\nHere's some example output for this file:\n\n```ts twoslash\n// @filename: constants.ts\nexport const valueOfPi = 3.142;\n// ---cut---\n// @filename: index.ts\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `CommonJS`\n\n```ts twoslash\n// @showEmit\n// @module: commonjs\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `UMD`\n\n```ts twoslash\n// @showEmit\n// @module: umd\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `AMD`\n\n```ts twoslash\n// @showEmit\n// @module: amd\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `System`\n\n```ts twoslash\n// @showEmit\n// @module: system\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `ESNext`\n\n```ts twoslash\n// @showEmit\n// @module: esnext\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `ES2015`/`ES6`/`ES2020`/`ES2022`\n\n```ts twoslash\n// @showEmit\n// @module: es2015\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\nIn addition to the base functionality of `ES2015`/`ES6`, `ES2020` adds support for [dynamic `import`s](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import), and [`import.meta`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta) while `ES2022` further adds support for [top level `await`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await#top_level_await).\n\n#### `node16`/`node18`/`node20`/`nodenext`\n\nThe `node16`, `node18`, `node20`, and `nodenext` modes integrate with Node's [native ECMAScript Module support](https://nodejs.org/api/esm.html). The emitted JavaScript uses either `CommonJS` or `ES2020` output depending on the file extension and the value of the `type` setting in the nearest `package.json`. Module resolution also works differently. You can learn more in the [handbook](https://typescriptlang.org/docs/handbook/esm-node.html) and [Modules Reference](https://typescriptlang.org/docs/handbook/modules/reference.html#node16-node18-node20-nodenext).\n\n- `node16` is available from TypeScript 4.7\n- `node18` is available from TypeScript 5.8 as a replacement for `node16`, with added support for import attributes.\n- `node20` adds support for require(ESM).\n- `nodenext` is available from TypeScript 4.7, but its behavior changes with the latest stable versions of Node.js. `--module nodenext` implies the floating `--target esnext`.\n\n#### `preserve`\n\nIn `--module preserve` ([added](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-4.html#support-for-require-calls-in---moduleresolution-bundler-and---module-preserve) in TypeScript 5.4), ECMAScript imports and exports written in input files are preserved in the output, and CommonJS-style `import x = require(\"...\")` and `export = ...` statements are emitted as CommonJS `require` and `module.exports`. In other words, the format of each individual import or export statement is preserved, rather than being coerced into a single format for the whole compilation (or even a whole file).\n\n```ts twoslash\n// @showEmit\n// @module: preserve\n// @noErrors\nimport { valueOfPi } from \"./constants\";\nimport constants = require(\"./constants\");\n\nexport const piSquared = valueOfPi * constants.valueOfPi;\n```\n\nWhile it’s rare to need to mix imports and require calls in the same file, this `module` mode best reflects the capabilities of most modern bundlers, as well as the Bun runtime.\n\n> Why care about TypeScript’s `module` emit with a bundler or with Bun, where you’re likely also setting `noEmit`? TypeScript’s type checking and module resolution behavior are affected by the module format that it _would_ emit. Setting `module` gives TypeScript information about how your bundler or runtime will process imports and exports, which ensures that the types you see on imported values accurately reflect what will happen at runtime or after bundling.\n\n#### `None`\n\n```ts twoslash\n// @showEmit\n// @module: none\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```",
              "type": [
                "string",
                "null"
              ],
              "anyOf": [
                {
                  "enum": [
                    "commonjs",
                    "amd",
                    "system",
                    "umd",
                    "es6",
                    "es2015",
                    "es2020",
                    "esnext",
                    "none",
                    "es2022",
                    "node16",
                    "node18",
                    "node20",
                    "nodenext",
                    "preserve"
                  ]
                },
                {
                  "pattern": "^([Cc][Oo][Mm][Mm][Oo][Nn][Jj][Ss]|[AaUu][Mm][Dd]|[Ss][Yy][Ss][Tt][Ee][Mm]|[Ee][Ss]([356]|20(1[567]|2[02])|[Nn][Ee][Xx][Tt])|[Nn][Oo][dD][Ee](1[68]|20)|[Nn][Oo][Dd][Ee][Nn][Ee][Xx][Tt]|[Nn][Oo][Nn][Ee]|[Pp][Rr][Ee][Ss][Ee][Rr][Vv][Ee])$"
                }
              ],
              "markdownDescription": "Sets the module system for the program. See the [theory behind TypeScript’s `module` option](https://typescriptlang.org/docs/handbook/modules/theory.html#the-module-output-format) and [its reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#the-module-compiler-option) for more information. You very likely want `\"nodenext\"` for modern Node.js projects and `preserve` or `esnext` for code that will be bundled.\n\nChanging `module` affects [`moduleResolution`](https://typescriptlang.org/tsconfig/#moduleResolution) which [also has a reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option).\n\nHere's some example output for this file:\n\n```ts twoslash\n// @filename: constants.ts\nexport const valueOfPi = 3.142;\n// ---cut---\n// @filename: index.ts\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `CommonJS`\n\n```ts twoslash\n// @showEmit\n// @module: commonjs\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `UMD`\n\n```ts twoslash\n// @showEmit\n// @module: umd\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `AMD`\n\n```ts twoslash\n// @showEmit\n// @module: amd\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `System`\n\n```ts twoslash\n// @showEmit\n// @module: system\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `ESNext`\n\n```ts twoslash\n// @showEmit\n// @module: esnext\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\n#### `ES2015`/`ES6`/`ES2020`/`ES2022`\n\n```ts twoslash\n// @showEmit\n// @module: es2015\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```\n\nIn addition to the base functionality of `ES2015`/`ES6`, `ES2020` adds support for [dynamic `import`s](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import), and [`import.meta`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta) while `ES2022` further adds support for [top level `await`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await#top_level_await).\n\n#### `node16`/`node18`/`node20`/`nodenext`\n\nThe `node16`, `node18`, `node20`, and `nodenext` modes integrate with Node's [native ECMAScript Module support](https://nodejs.org/api/esm.html). The emitted JavaScript uses either `CommonJS` or `ES2020` output depending on the file extension and the value of the `type` setting in the nearest `package.json`. Module resolution also works differently. You can learn more in the [handbook](https://typescriptlang.org/docs/handbook/esm-node.html) and [Modules Reference](https://typescriptlang.org/docs/handbook/modules/reference.html#node16-node18-node20-nodenext).\n\n- `node16` is available from TypeScript 4.7\n- `node18` is available from TypeScript 5.8 as a replacement for `node16`, with added support for import attributes.\n- `node20` adds support for require(ESM).\n- `nodenext` is available from TypeScript 4.7, but its behavior changes with the latest stable versions of Node.js. `--module nodenext` implies the floating `--target esnext`.\n\n#### `preserve`\n\nIn `--module preserve` ([added](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-4.html#support-for-require-calls-in---moduleresolution-bundler-and---module-preserve) in TypeScript 5.4), ECMAScript imports and exports written in input files are preserved in the output, and CommonJS-style `import x = require(\"...\")` and `export = ...` statements are emitted as CommonJS `require` and `module.exports`. In other words, the format of each individual import or export statement is preserved, rather than being coerced into a single format for the whole compilation (or even a whole file).\n\n```ts twoslash\n// @showEmit\n// @module: preserve\n// @noErrors\nimport { valueOfPi } from \"./constants\";\nimport constants = require(\"./constants\");\n\nexport const piSquared = valueOfPi * constants.valueOfPi;\n```\n\nWhile it’s rare to need to mix imports and require calls in the same file, this `module` mode best reflects the capabilities of most modern bundlers, as well as the Bun runtime.\n\n> Why care about TypeScript’s `module` emit with a bundler or with Bun, where you’re likely also setting `noEmit`? TypeScript’s type checking and module resolution behavior are affected by the module format that it _would_ emit. Setting `module` gives TypeScript information about how your bundler or runtime will process imports and exports, which ensures that the types you see on imported values accurately reflect what will happen at runtime or after bundling.\n\n#### `None`\n\n```ts twoslash\n// @showEmit\n// @module: none\n// @noErrors\nimport { valueOfPi } from \"./constants\";\n\nexport const twoPi = valueOfPi * 2;\n```",
              "x-intellij-html-description": "<p>Sets the module system for the program. See the <a href=\"https://typescriptlang.org/docs/handbook/modules/theory.html#the-module-output-format\">theory behind TypeScript’s <code>module</code> option</a> and <a href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#the-module-compiler-option\">its reference page</a> for more information. You very likely want <code>&quot;nodenext&quot;</code> for modern Node.js projects and <code>preserve</code> or <code>esnext</code> for code that will be bundled.</p>\n<p>Changing <code>module</code> affects <a href=\"https://typescriptlang.org/tsconfig/#moduleResolution\"><code>moduleResolution</code></a> which <a href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option\">also has a reference page</a>.</p>\n<p>Here&#39;s some example output for this file:</p>\n<pre><code class=\"language-ts\">// @filename: constants.ts\nexport const valueOfPi = 3.142;\n// ---cut---\n// @filename: index.ts\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>CommonJS</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: commonjs\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>UMD</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: umd\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>AMD</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: amd\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>System</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: system\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>ESNext</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: esnext\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<h4><code>ES2015</code>/<code>ES6</code>/<code>ES2020</code>/<code>ES2022</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: es2015\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n<p>In addition to the base functionality of <code>ES2015</code>/<code>ES6</code>, <code>ES2020</code> adds support for <a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import\">dynamic <code>import</code>s</a>, and <a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import.meta\"><code>import.meta</code></a> while <code>ES2022</code> further adds support for <a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await#top_level_await\">top level <code>await</code></a>.</p>\n<h4><code>node16</code>/<code>node18</code>/<code>node20</code>/<code>nodenext</code></h4>\n<p>The <code>node16</code>, <code>node18</code>, <code>node20</code>, and <code>nodenext</code> modes integrate with Node&#39;s <a href=\"https://nodejs.org/api/esm.html\">native ECMAScript Module support</a>. The emitted JavaScript uses either <code>CommonJS</code> or <code>ES2020</code> output depending on the file extension and the value of the <code>type</code> setting in the nearest <code>package.json</code>. Module resolution also works differently. You can learn more in the <a href=\"https://typescriptlang.org/docs/handbook/esm-node.html\">handbook</a> and <a href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#node16-node18-node20-nodenext\">Modules Reference</a>.</p>\n<ul>\n<li><code>node16</code> is available from TypeScript 4.7</li>\n<li><code>node18</code> is available from TypeScript 5.8 as a replacement for <code>node16</code>, with added support for import attributes.</li>\n<li><code>node20</code> adds support for require(ESM).</li>\n<li><code>nodenext</code> is available from TypeScript 4.7, but its behavior changes with the latest stable versions of Node.js. <code>--module nodenext</code> implies the floating <code>--target esnext</code>.</li>\n</ul>\n<h4><code>preserve</code></h4>\n<p>In <code>--module preserve</code> (<a href=\"https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-4.html#support-for-require-calls-in---moduleresolution-bundler-and---module-preserve\">added</a> in TypeScript 5.4), ECMAScript imports and exports written in input files are preserved in the output, and CommonJS-style <code>import x = require(&quot;...&quot;)</code> and <code>export = ...</code> statements are emitted as CommonJS <code>require</code> and <code>module.exports</code>. In other words, the format of each individual import or export statement is preserved, rather than being coerced into a single format for the whole compilation (or even a whole file).</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: preserve\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\nimport constants = require(&quot;./constants&quot;);\n\nexport const piSquared = valueOfPi * constants.valueOfPi;\n</code></pre>\n<p>While it’s rare to need to mix imports and require calls in the same file, this <code>module</code> mode best reflects the capabilities of most modern bundlers, as well as the Bun runtime.</p>\n<blockquote>\n<p>Why care about TypeScript’s <code>module</code> emit with a bundler or with Bun, where you’re likely also setting <code>noEmit</code>? TypeScript’s type checking and module resolution behavior are affected by the module format that it <em>would</em> emit. Setting <code>module</code> gives TypeScript information about how your bundler or runtime will process imports and exports, which ensures that the types you see on imported values accurately reflect what will happen at runtime or after bundling.</p>\n</blockquote>\n<h4><code>None</code></h4>\n<pre><code class=\"language-ts\">// @showEmit\n// @module: none\n// @noErrors\nimport { valueOfPi } from &quot;./constants&quot;;\n\nexport const twoPi = valueOfPi * 2;\n</code></pre>\n"
            },
            "moduleResolution": {
              "description": "Specify the module resolution strategy:\n\n- `'node16'` or `'nodenext'` for modern versions of Node.js. Node.js v12 and later supports both ECMAScript imports and CommonJS `require`, which resolve using different algorithms. These `moduleResolution` values, when combined with the corresponding [`module`](https://typescriptlang.org/tsconfig/#module) values, picks the right algorithm for each resolution based on whether Node.js will see an `import` or `require` in the output JavaScript code.\n- `'node10'` (previously called `'node'`) for Node.js versions older than v10, which only support CommonJS `require`. You probably won't need to use `node10` in modern code.\n- `'bundler'` for use with bundlers. Like `node16` and `nodenext`, this mode supports package.json `\"imports\"` and `\"exports\"`, but unlike the Node.js resolution modes, `bundler` never requires file extensions on relative paths in imports.\n- `'classic'` was used in TypeScript before the release of 1.6. `classic` should not be used.\n\nThere are reference pages explaining the [theory behind TypeScript’s module resolution](https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution) and the [details of each option](https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option).",
              "type": [
                "string",
                "null"
              ],
              "anyOf": [
                {
                  "enum": [
                    "classic",
                    "node",
                    "node10",
                    "node16",
                    "nodenext",
                    "bundler"
                  ],
                  "markdownEnumDescriptions": [
                    "It’s recommended to use `\"node16\"` instead",
                    "Deprecated, use `\"node10\"` in TypeScript 5.0+ instead",
                    "It’s recommended to use `\"node16\"` instead",
                    "This is the recommended setting for libraries and Node.js applications",
                    "This is the recommended setting for libraries and Node.js applications",
                    "This is the recommended setting in TypeScript 5.0+ for applications that use a bundler"
                  ]
                },
                {
                  "pattern": "^(([Nn]ode)|([Nn]ode1[06])|([Nn]ode[Nn]ext)|([Cc]lassic)|([Bb]undler))$"
                }
              ],
              "markdownDescription": "Specify the module resolution strategy:\n\n- `'node16'` or `'nodenext'` for modern versions of Node.js. Node.js v12 and later supports both ECMAScript imports and CommonJS `require`, which resolve using different algorithms. These `moduleResolution` values, when combined with the corresponding [`module`](https://typescriptlang.org/tsconfig/#module) values, picks the right algorithm for each resolution based on whether Node.js will see an `import` or `require` in the output JavaScript code.\n- `'node10'` (previously called `'node'`) for Node.js versions older than v10, which only support CommonJS `require`. You probably won't need to use `node10` in modern code.\n- `'bundler'` for use with bundlers. Like `node16` and `nodenext`, this mode supports package.json `\"imports\"` and `\"exports\"`, but unlike the Node.js resolution modes, `bundler` never requires file extensions on relative paths in imports.\n- `'classic'` was used in TypeScript before the release of 1.6. `classic` should not be used.\n\nThere are reference pages explaining the [theory behind TypeScript’s module resolution](https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution) and the [details of each option](https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option).",
              "x-intellij-html-description": "<p>Specify the module resolution strategy:</p>\n<ul>\n<li><code>&#39;node16&#39;</code> or <code>&#39;nodenext&#39;</code> for modern versions of Node.js. Node.js v12 and later supports both ECMAScript imports and CommonJS <code>require</code>, which resolve using different algorithms. These <code>moduleResolution</code> values, when combined with the corresponding <a href=\"https://typescriptlang.org/tsconfig/#module\"><code>module</code></a> values, picks the right algorithm for each resolution based on whether Node.js will see an <code>import</code> or <code>require</code> in the output JavaScript code.</li>\n<li><code>&#39;node10&#39;</code> (previously called <code>&#39;node&#39;</code>) for Node.js versions older than v10, which only support CommonJS <code>require</code>. You probably won&#39;t need to use <code>node10</code> in modern code.</li>\n<li><code>&#39;bundler&#39;</code> for use with bundlers. Like <code>node16</code> and <code>nodenext</code>, this mode supports package.json <code>&quot;imports&quot;</code> and <code>&quot;exports&quot;</code>, but unlike the Node.js resolution modes, <code>bundler</code> never requires file extensions on relative paths in imports.</li>\n<li><code>&#39;classic&#39;</code> was used in TypeScript before the release of 1.6. <code>classic</code> should not be used.</li>\n</ul>\n<p>There are reference pages explaining the <a href=\"https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution\">theory behind TypeScript’s module resolution</a> and the <a href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option\">details of each option</a>.</p>\n"
            },
            "moduleSuffixes": {
              "description": "Provides a way to override the default list of file name suffixes to search when resolving a module.\n\n```json tsconfig\n{\n    \"compilerOptions\": {\n        \"moduleSuffixes\": [\".ios\", \".native\", \"\"]\n    }\n}\n```\n\nGiven the above configuration, an import like the following:\n\n```ts\nimport * as foo from \"./foo\";\n```\n\nTypeScript will look for the relative files `./foo.ios.ts`, `./foo.native.ts`, and finally `./foo.ts`.\n\nNote the empty string `\"\"` in [`moduleSuffixes`](https://typescriptlang.org/tsconfig/#moduleSuffixes) which is necessary for TypeScript to also look-up `./foo.ts`.\n\nThis feature can be useful for React Native projects where each target platform can use a separate tsconfig.json with differing `moduleSuffixes`.",
              "type": [
                "array",
                "null"
              ],
              "uniqueItems": true,
              "items": {
                "type": "string"
              },
              "markdownDescription": "Provides a way to override the default list of file name suffixes to search when resolving a module.\n\n```json tsconfig\n{\n    \"compilerOptions\": {\n        \"moduleSuffixes\": [\".ios\", \".native\", \"\"]\n    }\n}\n```\n\nGiven the above configuration, an import like the following:\n\n```ts\nimport * as foo from \"./foo\";\n```\n\nTypeScript will look for the relative files `./foo.ios.ts`, `./foo.native.ts`, and finally `./foo.ts`.\n\nNote the empty string `\"\"` in [`moduleSuffixes`](https://typescriptlang.org/tsconfig/#moduleSuffixes) which is necessary for TypeScript to also look-up `./foo.ts`.\n\nThis feature can be useful for React Native projects where each target platform can use a separate tsconfig.json with differing `moduleSuffixes`.",
              "x-intellij-html-description": "<p>Provides a way to override the default list of file name suffixes to search when resolving a module.</p>\n<pre><code class=\"language-json\">{\n    &quot;compilerOptions&quot;: {\n        &quot;moduleSuffixes&quot;: [&quot;.ios&quot;, &quot;.native&quot;, &quot;&quot;]\n    }\n}\n</code></pre>\n<p>Given the above configuration, an import like the following:</p>\n<pre><code class=\"language-ts\">import * as foo from &quot;./foo&quot;;\n</code></pre>\n<p>TypeScript will look for the relative files <code>./foo.ios.ts</code>, <code>./foo.native.ts</code>, and finally <code>./foo.ts</code>.</p>\n<p>Note the empty string <code>&quot;&quot;</code> in <a href=\"https://typescriptlang.org/tsconfig/#moduleSuffixes\"><code>moduleSuffixes</code></a> which is necessary for TypeScript to also look-up <code>./foo.ts</code>.</p>\n<p>This feature can be useful for React Native projects where each target platform can use a separate tsconfig.json with differing <code>moduleSuffixes</code>.</p>\n"
            },
            "newLine": {
              "description": "Specify the end of line sequence to be used when emitting files: 'CRLF' (dos) or 'LF' (unix).",
              "type": [
                "string",
                "null"
              ],
              "default": "lf",
              "anyOf": [
                {
                  "enum": [
                    "crlf",
                    "lf"
                  ]
                },
                {
                  "pattern": "^(CRLF|LF|crlf|lf)$"
                }
              ],
              "markdownDescription": "Specify the end of line sequence to be used when emitting files: 'CRLF' (dos) or 'LF' (unix).",
              "x-intellij-html-description": "<p>Specify the end of line sequence to be used when emitting files: &#39;CRLF&#39; (dos) or &#39;LF&#39; (unix).</p>\n"
            },
            "noEmit": {
              "description": "Do not emit compiler output files like JavaScript source code, source-maps or declarations.\n\nThis makes room for another tool like [Babel](https://babeljs.io/), or [swc](https://github.com/swc-project/swc) to handle converting the TypeScript file to a file which can run inside a JavaScript environment.\n\nYou can then use TypeScript as a tool for providing editor integration, and as a source code type-checker.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Do not emit compiler output files like JavaScript source code, source-maps or declarations.\n\nThis makes room for another tool like [Babel](https://babeljs.io/), or [swc](https://github.com/swc-project/swc) to handle converting the TypeScript file to a file which can run inside a JavaScript environment.\n\nYou can then use TypeScript as a tool for providing editor integration, and as a source code type-checker.",
              "x-intellij-html-description": "<p>Do not emit compiler output files like JavaScript source code, source-maps or declarations.</p>\n<p>This makes room for another tool like <a href=\"https://babeljs.io/\">Babel</a>, or <a href=\"https://github.com/swc-project/swc\">swc</a> to handle converting the TypeScript file to a file which can run inside a JavaScript environment.</p>\n<p>You can then use TypeScript as a tool for providing editor integration, and as a source code type-checker.</p>\n"
            },
            "noEmitHelpers": {
              "description": "Instead of importing helpers with [`importHelpers`](https://typescriptlang.org/tsconfig/#importHelpers), you can provide implementations in the global scope for the helpers you use and completely turn off emitting of helper functions.\n\nFor example, using this `async` function in ES5 requires a `await`-like function and `generator`-like function to run:\n\n```ts twoslash\nconst getAPI = async (url: string) => {\n  // Get API\n  return {};\n};\n```\n\nWhich creates quite a lot of JavaScript:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\nconst getAPI = async (url: string) => {\n  // Get API\n  return {};\n};\n```\n\nWhich can be switched out with your own globals via this flag:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\n// @noEmitHelpers\nconst getAPI = async (url: string) => {\n  // Get API\n  return {};\n};\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Instead of importing helpers with [`importHelpers`](https://typescriptlang.org/tsconfig/#importHelpers), you can provide implementations in the global scope for the helpers you use and completely turn off emitting of helper functions.\n\nFor example, using this `async` function in ES5 requires a `await`-like function and `generator`-like function to run:\n\n```ts twoslash\nconst getAPI = async (url: string) => {\n  // Get API\n  return {};\n};\n```\n\nWhich creates quite a lot of JavaScript:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\nconst getAPI = async (url: string) => {\n  // Get API\n  return {};\n};\n```\n\nWhich can be switched out with your own globals via this flag:\n\n```ts twoslash\n// @showEmit\n// @target: ES5\n// @noEmitHelpers\nconst getAPI = async (url: string) => {\n  // Get API\n  return {};\n};\n```",
              "x-intellij-html-description": "<p>Instead of importing helpers with <a href=\"https://typescriptlang.org/tsconfig/#importHelpers\"><code>importHelpers</code></a>, you can provide implementations in the global scope for the helpers you use and completely turn off emitting of helper functions.</p>\n<p>For example, using this <code>async</code> function in ES5 requires a <code>await</code>-like function and <code>generator</code>-like function to run:</p>\n<pre><code class=\"language-ts\">const getAPI = async (url: string) =&gt; {\n  // Get API\n  return {};\n};\n</code></pre>\n<p>Which creates quite a lot of JavaScript:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @target: ES5\nconst getAPI = async (url: string) =&gt; {\n  // Get API\n  return {};\n};\n</code></pre>\n<p>Which can be switched out with your own globals via this flag:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @target: ES5\n// @noEmitHelpers\nconst getAPI = async (url: string) =&gt; {\n  // Get API\n  return {};\n};\n</code></pre>\n"
            },
            "noEmitOnError": {
              "description": "Do not emit compiler output files like JavaScript source code, source-maps or declarations if any errors were reported.\n\nThis defaults to `false`, making it easier to work with TypeScript in a watch-like environment where you may want to see results of changes to your code in another environment before making sure all errors are resolved.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Do not emit compiler output files like JavaScript source code, source-maps or declarations if any errors were reported.\n\nThis defaults to `false`, making it easier to work with TypeScript in a watch-like environment where you may want to see results of changes to your code in another environment before making sure all errors are resolved.",
              "x-intellij-html-description": "<p>Do not emit compiler output files like JavaScript source code, source-maps or declarations if any errors were reported.</p>\n<p>This defaults to <code>false</code>, making it easier to work with TypeScript in a watch-like environment where you may want to see results of changes to your code in another environment before making sure all errors are resolved.</p>\n"
            },
            "noImplicitAny": {
              "description": "In some cases where no type annotations are present, TypeScript will fall back to a type of `any` for a variable when it cannot infer the type.\n\nThis can cause some errors to be missed, for example:\n\n```ts twoslash\n// @noImplicitAny: false\nfunction fn(s) {\n  // No error?\n  console.log(s.subtr(3));\n}\nfn(42);\n```\n\nTurning on `noImplicitAny` however TypeScript will issue an error whenever it would have inferred `any`:\n\n```ts twoslash\n// @errors: 7006\nfunction fn(s) {\n  console.log(s.subtr(3));\n}\n```",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "In some cases where no type annotations are present, TypeScript will fall back to a type of `any` for a variable when it cannot infer the type.\n\nThis can cause some errors to be missed, for example:\n\n```ts twoslash\n// @noImplicitAny: false\nfunction fn(s) {\n  // No error?\n  console.log(s.subtr(3));\n}\nfn(42);\n```\n\nTurning on `noImplicitAny` however TypeScript will issue an error whenever it would have inferred `any`:\n\n```ts twoslash\n// @errors: 7006\nfunction fn(s) {\n  console.log(s.subtr(3));\n}\n```",
              "x-intellij-html-description": "<p>In some cases where no type annotations are present, TypeScript will fall back to a type of <code>any</code> for a variable when it cannot infer the type.</p>\n<p>This can cause some errors to be missed, for example:</p>\n<pre><code class=\"language-ts\">// @noImplicitAny: false\nfunction fn(s) {\n  // No error?\n  console.log(s.subtr(3));\n}\nfn(42);\n</code></pre>\n<p>Turning on <code>noImplicitAny</code> however TypeScript will issue an error whenever it would have inferred <code>any</code>:</p>\n<pre><code class=\"language-ts\">// @errors: 7006\nfunction fn(s) {\n  console.log(s.subtr(3));\n}\n</code></pre>\n"
            },
            "noImplicitThis": {
              "description": "Raise error on 'this' expressions with an implied 'any' type.\n\nFor example, the class below returns a function which tries to access `this.width` and `this.height` – but the context\nfor `this` inside the function inside `getAreaFunction` is not the instance of the Rectangle.\n\n```ts twoslash\n// @errors: 2683\nclass Rectangle {\n  width: number;\n  height: number;\n\n  constructor(width: number, height: number) {\n    this.width = width;\n    this.height = height;\n  }\n\n  getAreaFunction() {\n    return function () {\n      return this.width * this.height;\n    };\n  }\n}\n```",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "Raise error on 'this' expressions with an implied 'any' type.\n\nFor example, the class below returns a function which tries to access `this.width` and `this.height` – but the context\nfor `this` inside the function inside `getAreaFunction` is not the instance of the Rectangle.\n\n```ts twoslash\n// @errors: 2683\nclass Rectangle {\n  width: number;\n  height: number;\n\n  constructor(width: number, height: number) {\n    this.width = width;\n    this.height = height;\n  }\n\n  getAreaFunction() {\n    return function () {\n      return this.width * this.height;\n    };\n  }\n}\n```",
              "x-intellij-html-description": "<p>Raise error on &#39;this&#39; expressions with an implied &#39;any&#39; type.</p>\n<p>For example, the class below returns a function which tries to access <code>this.width</code> and <code>this.height</code> – but the context\nfor <code>this</code> inside the function inside <code>getAreaFunction</code> is not the instance of the Rectangle.</p>\n<pre><code class=\"language-ts\">// @errors: 2683\nclass Rectangle {\n  width: number;\n  height: number;\n\n  constructor(width: number, height: number) {\n    this.width = width;\n    this.height = height;\n  }\n\n  getAreaFunction() {\n    return function () {\n      return this.width * this.height;\n    };\n  }\n}\n</code></pre>\n"
            },
            "noUnusedLocals": {
              "description": "Report errors on unused local variables.\n\n```ts twoslash\n// @noUnusedLocals\n// @errors: 6133\nconst createKeyboard = (modelID: number) => {\n  const defaultModelID = 23;\n  return { type: \"keyboard\", modelID };\n};\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Report errors on unused local variables.\n\n```ts twoslash\n// @noUnusedLocals\n// @errors: 6133\nconst createKeyboard = (modelID: number) => {\n  const defaultModelID = 23;\n  return { type: \"keyboard\", modelID };\n};\n```",
              "x-intellij-html-description": "<p>Report errors on unused local variables.</p>\n<pre><code class=\"language-ts\">// @noUnusedLocals\n// @errors: 6133\nconst createKeyboard = (modelID: number) =&gt; {\n  const defaultModelID = 23;\n  return { type: &quot;keyboard&quot;, modelID };\n};\n</code></pre>\n"
            },
            "noUnusedParameters": {
              "description": "Report errors on unused parameters in functions.\n\n```ts twoslash\n// @noUnusedParameters\n// @errors: 6133\nconst createDefaultKeyboard = (modelID: number) => {\n  const defaultModelID = 23;\n  return { type: \"keyboard\", modelID: defaultModelID };\n};\n```\n\nParameters declaration with names starting with an underscore (`_`) are exempt from the unused parameter checking. e.g.:\n\n```ts twoslash\n// @noUnusedParameters\nconst createDefaultKeyboard = (_modelID: number) => {\n  return { type: \"keyboard\" };\n};\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Report errors on unused parameters in functions.\n\n```ts twoslash\n// @noUnusedParameters\n// @errors: 6133\nconst createDefaultKeyboard = (modelID: number) => {\n  const defaultModelID = 23;\n  return { type: \"keyboard\", modelID: defaultModelID };\n};\n```\n\nParameters declaration with names starting with an underscore (`_`) are exempt from the unused parameter checking. e.g.:\n\n```ts twoslash\n// @noUnusedParameters\nconst createDefaultKeyboard = (_modelID: number) => {\n  return { type: \"keyboard\" };\n};\n```",
              "x-intellij-html-description": "<p>Report errors on unused parameters in functions.</p>\n<pre><code class=\"language-ts\">// @noUnusedParameters\n// @errors: 6133\nconst createDefaultKeyboard = (modelID: number) =&gt; {\n  const defaultModelID = 23;\n  return { type: &quot;keyboard&quot;, modelID: defaultModelID };\n};\n</code></pre>\n<p>Parameters declaration with names starting with an underscore (<code>_</code>) are exempt from the unused parameter checking. e.g.:</p>\n<pre><code class=\"language-ts\">// @noUnusedParameters\nconst createDefaultKeyboard = (_modelID: number) =&gt; {\n  return { type: &quot;keyboard&quot; };\n};\n</code></pre>\n"
            },
            "noLib": {
              "description": "Disables the automatic inclusion of any library files.\nIf this option is set, `lib` is ignored.\n\nTypeScript _cannot_ compile anything without a set of interfaces for key primitives like: `Array`, `Boolean`, `Function`, `IArguments`, `Number`, `Object`, `RegExp`, and `String`. It is expected that if you use `noLib` you will be including your own type definitions for these.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Disables the automatic inclusion of any library files.\nIf this option is set, `lib` is ignored.\n\nTypeScript _cannot_ compile anything without a set of interfaces for key primitives like: `Array`, `Boolean`, `Function`, `IArguments`, `Number`, `Object`, `RegExp`, and `String`. It is expected that if you use `noLib` you will be including your own type definitions for these.",
              "x-intellij-html-description": "<p>Disables the automatic inclusion of any library files.\nIf this option is set, <code>lib</code> is ignored.</p>\n<p>TypeScript <em>cannot</em> compile anything without a set of interfaces for key primitives like: <code>Array</code>, <code>Boolean</code>, <code>Function</code>, <code>IArguments</code>, <code>Number</code>, <code>Object</code>, <code>RegExp</code>, and <code>String</code>. It is expected that if you use <code>noLib</code> you will be including your own type definitions for these.</p>\n"
            },
            "noResolve": {
              "description": "By default, TypeScript will examine the initial set of files for `import` and `<reference` directives and add these resolved files to your program.\n\nIf `noResolve` is set, this process doesn't happen.\nHowever, `import` statements are still checked to see if they resolve to a valid module, so you'll need to make sure this is satisfied by some other means.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "By default, TypeScript will examine the initial set of files for `import` and `<reference` directives and add these resolved files to your program.\n\nIf `noResolve` is set, this process doesn't happen.\nHowever, `import` statements are still checked to see if they resolve to a valid module, so you'll need to make sure this is satisfied by some other means.",
              "x-intellij-html-description": "<p>By default, TypeScript will examine the initial set of files for <code>import</code> and <code>&lt;reference</code> directives and add these resolved files to your program.</p>\n<p>If <code>noResolve</code> is set, this process doesn&#39;t happen.\nHowever, <code>import</code> statements are still checked to see if they resolve to a valid module, so you&#39;ll need to make sure this is satisfied by some other means.</p>\n"
            },
            "noStrictGenericChecks": {
              "description": "TypeScript will unify type parameters when comparing two generic functions.\n\n```ts twoslash\n// @errors: 2322\n\ntype A = <T, U>(x: T, y: U) => [T, U];\ntype B = <S>(x: S, y: S) => [S, S];\n\nfunction f(a: A, b: B) {\n  b = a; // Ok\n  a = b; // Error\n}\n```\n\nThis flag can be used to remove that check.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "TypeScript will unify type parameters when comparing two generic functions.\n\n```ts twoslash\n// @errors: 2322\n\ntype A = <T, U>(x: T, y: U) => [T, U];\ntype B = <S>(x: S, y: S) => [S, S];\n\nfunction f(a: A, b: B) {\n  b = a; // Ok\n  a = b; // Error\n}\n```\n\nThis flag can be used to remove that check.",
              "x-intellij-html-description": "<p>TypeScript will unify type parameters when comparing two generic functions.</p>\n<pre><code class=\"language-ts\">// @errors: 2322\n\ntype A = &lt;T, U&gt;(x: T, y: U) =&gt; [T, U];\ntype B = &lt;S&gt;(x: S, y: S) =&gt; [S, S];\n\nfunction f(a: A, b: B) {\n  b = a; // Ok\n  a = b; // Error\n}\n</code></pre>\n<p>This flag can be used to remove that check.</p>\n"
            },
            "out": {
              "description": "Deprecated setting. Use `outFile` instead.",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "Deprecated setting. Use `outFile` instead.\n\nSee more: https://www.typescriptlang.org/tsconfig#out"
            },
            "skipDefaultLibCheck": {
              "description": "Use [`skipLibCheck`](https://typescriptlang.org/tsconfig/#skipLibCheck) instead. Skip type checking of default library declaration files.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Use [`skipLibCheck`](https://typescriptlang.org/tsconfig/#skipLibCheck) instead. Skip type checking of default library declaration files.",
              "x-intellij-html-description": "<p>Use <a href=\"https://typescriptlang.org/tsconfig/#skipLibCheck\"><code>skipLibCheck</code></a> instead. Skip type checking of default library declaration files.</p>\n"
            },
            "skipLibCheck": {
              "description": "Skip type checking of declaration files.\n\nThis can save time during compilation at the expense of type-system accuracy. For example, two libraries could\ndefine two copies of the same `type` in an inconsistent way. Rather than doing a full check of all `d.ts` files, TypeScript\nwill type check the code you specifically refer to in your app's source code.\n\nA common case where you might think to use `skipLibCheck` is when there are two copies of a library's types in\nyour `node_modules`. In these cases, you should consider using a feature like [yarn's resolutions](https://yarnpkg.com/lang/en/docs/selective-version-resolutions/)\nto ensure there is only one copy of that dependency in your tree or investigate how to ensure there is\nonly one copy by understanding the dependency resolution to fix the issue without additional tooling.\n\nAnother possibility is when you are migrating between TypeScript releases and the changes cause breakages in node_modules and the JS standard libraries which you do not want to deal with during the TypeScript update. \n\nNote, that if these issues come from the TypeScript standard library you can replace the library using [TypeScript 4.5's lib replacement](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#supporting-lib-from-node_modules) technique.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Skip type checking of declaration files.\n\nThis can save time during compilation at the expense of type-system accuracy. For example, two libraries could\ndefine two copies of the same `type` in an inconsistent way. Rather than doing a full check of all `d.ts` files, TypeScript\nwill type check the code you specifically refer to in your app's source code.\n\nA common case where you might think to use `skipLibCheck` is when there are two copies of a library's types in\nyour `node_modules`. In these cases, you should consider using a feature like [yarn's resolutions](https://yarnpkg.com/lang/en/docs/selective-version-resolutions/)\nto ensure there is only one copy of that dependency in your tree or investigate how to ensure there is\nonly one copy by understanding the dependency resolution to fix the issue without additional tooling.\n\nAnother possibility is when you are migrating between TypeScript releases and the changes cause breakages in node_modules and the JS standard libraries which you do not want to deal with during the TypeScript update. \n\nNote, that if these issues come from the TypeScript standard library you can replace the library using [TypeScript 4.5's lib replacement](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#supporting-lib-from-node_modules) technique.",
              "x-intellij-html-description": "<p>Skip type checking of declaration files.</p>\n<p>This can save time during compilation at the expense of type-system accuracy. For example, two libraries could\ndefine two copies of the same <code>type</code> in an inconsistent way. Rather than doing a full check of all <code>d.ts</code> files, TypeScript\nwill type check the code you specifically refer to in your app&#39;s source code.</p>\n<p>A common case where you might think to use <code>skipLibCheck</code> is when there are two copies of a library&#39;s types in\nyour <code>node_modules</code>. In these cases, you should consider using a feature like <a href=\"https://yarnpkg.com/lang/en/docs/selective-version-resolutions/\">yarn&#39;s resolutions</a>\nto ensure there is only one copy of that dependency in your tree or investigate how to ensure there is\nonly one copy by understanding the dependency resolution to fix the issue without additional tooling.</p>\n<p>Another possibility is when you are migrating between TypeScript releases and the changes cause breakages in node_modules and the JS standard libraries which you do not want to deal with during the TypeScript update. </p>\n<p>Note, that if these issues come from the TypeScript standard library you can replace the library using <a href=\"https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#supporting-lib-from-node_modules\">TypeScript 4.5&#39;s lib replacement</a> technique.</p>\n"
            },
            "outFile": {
              "description": "If specified, all _global_ (non-module) files will be concatenated into the single output file specified.\n\nIf `module` is `system` or `amd`, all module files will also be concatenated into this file after all global content.\n\nNote: `outFile` cannot be used unless `module` is `None`, `System`, or `AMD`.\nThis option _cannot_ be used to bundle CommonJS or ES6 modules.",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "If specified, all _global_ (non-module) files will be concatenated into the single output file specified.\n\nIf `module` is `system` or `amd`, all module files will also be concatenated into this file after all global content.\n\nNote: `outFile` cannot be used unless `module` is `None`, `System`, or `AMD`.\nThis option _cannot_ be used to bundle CommonJS or ES6 modules.",
              "x-intellij-html-description": "<p>If specified, all <em>global</em> (non-module) files will be concatenated into the single output file specified.</p>\n<p>If <code>module</code> is <code>system</code> or <code>amd</code>, all module files will also be concatenated into this file after all global content.</p>\n<p>Note: <code>outFile</code> cannot be used unless <code>module</code> is <code>None</code>, <code>System</code>, or <code>AMD</code>.\nThis option <em>cannot</em> be used to bundle CommonJS or ES6 modules.</p>\n"
            },
            "outDir": {
              "description": "If specified, `.js` (as well as `.d.ts`, `.js.map`, etc.) files will be emitted into this directory.\nThe directory structure of the original source files is preserved; see [`rootDir`](https://typescriptlang.org/tsconfig/#rootDir) if the computed root is not what you intended.\n\nIf not specified, `.js` files will be emitted in the same directory as the `.ts` files they were generated from:\n\n```sh\n$ tsc\n\nexample\n├── index.js\n└── index.ts\n```\n\nWith a `tsconfig.json` like this:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"outDir\": \"dist\"\n  }\n}\n```\n\nRunning `tsc` with these settings moves the files into the specified `dist` folder:\n\n```sh\n$ tsc\n\nexample\n├── dist\n│   └── index.js\n├── index.ts\n└── tsconfig.json\n```",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "If specified, `.js` (as well as `.d.ts`, `.js.map`, etc.) files will be emitted into this directory.\nThe directory structure of the original source files is preserved; see [`rootDir`](https://typescriptlang.org/tsconfig/#rootDir) if the computed root is not what you intended.\n\nIf not specified, `.js` files will be emitted in the same directory as the `.ts` files they were generated from:\n\n```sh\n$ tsc\n\nexample\n├── index.js\n└── index.ts\n```\n\nWith a `tsconfig.json` like this:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"outDir\": \"dist\"\n  }\n}\n```\n\nRunning `tsc` with these settings moves the files into the specified `dist` folder:\n\n```sh\n$ tsc\n\nexample\n├── dist\n│   └── index.js\n├── index.ts\n└── tsconfig.json\n```",
              "x-intellij-html-description": "<p>If specified, <code>.js</code> (as well as <code>.d.ts</code>, <code>.js.map</code>, etc.) files will be emitted into this directory.\nThe directory structure of the original source files is preserved; see <a href=\"https://typescriptlang.org/tsconfig/#rootDir\"><code>rootDir</code></a> if the computed root is not what you intended.</p>\n<p>If not specified, <code>.js</code> files will be emitted in the same directory as the <code>.ts</code> files they were generated from:</p>\n<pre><code class=\"language-sh\">$ tsc\n\nexample\n├── index.js\n└── index.ts\n</code></pre>\n<p>With a <code>tsconfig.json</code> like this:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;outDir&quot;: &quot;dist&quot;\n  }\n}\n</code></pre>\n<p>Running <code>tsc</code> with these settings moves the files into the specified <code>dist</code> folder:</p>\n<pre><code class=\"language-sh\">$ tsc\n\nexample\n├── dist\n│   └── index.js\n├── index.ts\n└── tsconfig.json\n</code></pre>\n"
            },
            "preserveConstEnums": {
              "description": "Do not erase `const enum` declarations in generated code. `const enum`s provide a way to reduce the overall memory footprint\nof your application at runtime by emitting the enum value instead of a reference.\n\nFor example with this TypeScript:\n\n```ts twoslash\nconst enum Album {\n  JimmyEatWorldFutures = 1,\n  TubRingZooHypothesis = 2,\n  DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n  console.log(\"That is a great choice.\");\n}\n```\n\nThe default `const enum` behavior is to convert any `Album.Something` to the corresponding number literal, and to remove a reference\nto the enum from the JavaScript completely.\n\n```ts twoslash\n// @showEmit\nconst enum Album {\n  JimmyEatWorldFutures = 1,\n  TubRingZooHypothesis = 2,\n  DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n  console.log(\"That is a great choice.\");\n}\n```\n\nWith `preserveConstEnums` set to `true`, the `enum` exists at runtime and the numbers are still emitted.\n\n```ts twoslash\n// @preserveConstEnums: true\n// @showEmit\nconst enum Album {\n  JimmyEatWorldFutures = 1,\n  TubRingZooHypothesis = 2,\n  DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n  console.log(\"That is a great choice.\");\n}\n```\n\nThis essentially makes such `const enums` a source-code feature only, with no runtime traces.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Do not erase `const enum` declarations in generated code. `const enum`s provide a way to reduce the overall memory footprint\nof your application at runtime by emitting the enum value instead of a reference.\n\nFor example with this TypeScript:\n\n```ts twoslash\nconst enum Album {\n  JimmyEatWorldFutures = 1,\n  TubRingZooHypothesis = 2,\n  DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n  console.log(\"That is a great choice.\");\n}\n```\n\nThe default `const enum` behavior is to convert any `Album.Something` to the corresponding number literal, and to remove a reference\nto the enum from the JavaScript completely.\n\n```ts twoslash\n// @showEmit\nconst enum Album {\n  JimmyEatWorldFutures = 1,\n  TubRingZooHypothesis = 2,\n  DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n  console.log(\"That is a great choice.\");\n}\n```\n\nWith `preserveConstEnums` set to `true`, the `enum` exists at runtime and the numbers are still emitted.\n\n```ts twoslash\n// @preserveConstEnums: true\n// @showEmit\nconst enum Album {\n  JimmyEatWorldFutures = 1,\n  TubRingZooHypothesis = 2,\n  DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n  console.log(\"That is a great choice.\");\n}\n```\n\nThis essentially makes such `const enums` a source-code feature only, with no runtime traces.",
              "x-intellij-html-description": "<p>Do not erase <code>const enum</code> declarations in generated code. <code>const enum</code>s provide a way to reduce the overall memory footprint\nof your application at runtime by emitting the enum value instead of a reference.</p>\n<p>For example with this TypeScript:</p>\n<pre><code class=\"language-ts\">const enum Album {\n  JimmyEatWorldFutures = 1,\n  TubRingZooHypothesis = 2,\n  DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n  console.log(&quot;That is a great choice.&quot;);\n}\n</code></pre>\n<p>The default <code>const enum</code> behavior is to convert any <code>Album.Something</code> to the corresponding number literal, and to remove a reference\nto the enum from the JavaScript completely.</p>\n<pre><code class=\"language-ts\">// @showEmit\nconst enum Album {\n  JimmyEatWorldFutures = 1,\n  TubRingZooHypothesis = 2,\n  DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n  console.log(&quot;That is a great choice.&quot;);\n}\n</code></pre>\n<p>With <code>preserveConstEnums</code> set to <code>true</code>, the <code>enum</code> exists at runtime and the numbers are still emitted.</p>\n<pre><code class=\"language-ts\">// @preserveConstEnums: true\n// @showEmit\nconst enum Album {\n  JimmyEatWorldFutures = 1,\n  TubRingZooHypothesis = 2,\n  DogFashionDiscoAdultery = 3,\n}\n\nconst selectedAlbum = Album.JimmyEatWorldFutures;\nif (selectedAlbum === Album.JimmyEatWorldFutures) {\n  console.log(&quot;That is a great choice.&quot;);\n}\n</code></pre>\n<p>This essentially makes such <code>const enums</code> a source-code feature only, with no runtime traces.</p>\n"
            },
            "preserveSymlinks": {
              "description": "This is to reflect the same flag in Node.js; which does not resolve the real path of symlinks.\n\nThis flag also exhibits the opposite behavior to Webpack’s `resolve.symlinks` option (i.e. setting TypeScript’s `preserveSymlinks` to true parallels setting Webpack’s `resolve.symlinks` to false, and vice-versa).\n\nWith this enabled, references to modules and packages (e.g. `import`s and `/// <reference type=\"...\" />` directives) are all resolved relative to the location of the symbolic link file, rather than relative to the path that the symbolic link resolves to.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "This is to reflect the same flag in Node.js; which does not resolve the real path of symlinks.\n\nThis flag also exhibits the opposite behavior to Webpack’s `resolve.symlinks` option (i.e. setting TypeScript’s `preserveSymlinks` to true parallels setting Webpack’s `resolve.symlinks` to false, and vice-versa).\n\nWith this enabled, references to modules and packages (e.g. `import`s and `/// <reference type=\"...\" />` directives) are all resolved relative to the location of the symbolic link file, rather than relative to the path that the symbolic link resolves to.",
              "x-intellij-html-description": "<p>This is to reflect the same flag in Node.js; which does not resolve the real path of symlinks.</p>\n<p>This flag also exhibits the opposite behavior to Webpack’s <code>resolve.symlinks</code> option (i.e. setting TypeScript’s <code>preserveSymlinks</code> to true parallels setting Webpack’s <code>resolve.symlinks</code> to false, and vice-versa).</p>\n<p>With this enabled, references to modules and packages (e.g. <code>import</code>s and <code>/// &lt;reference type=&quot;...&quot; /&gt;</code> directives) are all resolved relative to the location of the symbolic link file, rather than relative to the path that the symbolic link resolves to.</p>\n"
            },
            "preserveValueImports": {
              "description": "Deprecated in favor of [`verbatimModuleSyntax`](https://typescriptlang.org/tsconfig/#verbatimModuleSyntax).\n\nThere are some cases where TypeScript can't detect that you're using an import. For example, take the following code:\n\n```ts\nimport { Animal } from \"./animal.js\";\n\neval(\"console.log(new Animal().isDangerous())\");\n```\n\nor code using 'Compiles to HTML' languages like Svelte or Vue. `preserveValueImports` will prevent TypeScript from removing the import, even if it appears unused.\n\nWhen combined with [`isolatedModules`](https://typescriptlang.org/tsconfig/#isolatedModules): imported types _must_ be marked as type-only because compilers that process single files at a time have no way of knowing whether imports are values that appear unused, or a type that must be removed in order to avoid a runtime crash.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Deprecated in favor of [`verbatimModuleSyntax`](https://typescriptlang.org/tsconfig/#verbatimModuleSyntax).\n\nThere are some cases where TypeScript can't detect that you're using an import. For example, take the following code:\n\n```ts\nimport { Animal } from \"./animal.js\";\n\neval(\"console.log(new Animal().isDangerous())\");\n```\n\nor code using 'Compiles to HTML' languages like Svelte or Vue. `preserveValueImports` will prevent TypeScript from removing the import, even if it appears unused.\n\nWhen combined with [`isolatedModules`](https://typescriptlang.org/tsconfig/#isolatedModules): imported types _must_ be marked as type-only because compilers that process single files at a time have no way of knowing whether imports are values that appear unused, or a type that must be removed in order to avoid a runtime crash.",
              "x-intellij-html-description": "<p>Deprecated in favor of <a href=\"https://typescriptlang.org/tsconfig/#verbatimModuleSyntax\"><code>verbatimModuleSyntax</code></a>.</p>\n<p>There are some cases where TypeScript can&#39;t detect that you&#39;re using an import. For example, take the following code:</p>\n<pre><code class=\"language-ts\">import { Animal } from &quot;./animal.js&quot;;\n\neval(&quot;console.log(new Animal().isDangerous())&quot;);\n</code></pre>\n<p>or code using &#39;Compiles to HTML&#39; languages like Svelte or Vue. <code>preserveValueImports</code> will prevent TypeScript from removing the import, even if it appears unused.</p>\n<p>When combined with <a href=\"https://typescriptlang.org/tsconfig/#isolatedModules\"><code>isolatedModules</code></a>: imported types <em>must</em> be marked as type-only because compilers that process single files at a time have no way of knowing whether imports are values that appear unused, or a type that must be removed in order to avoid a runtime crash.</p>\n"
            },
            "preserveWatchOutput": {
              "description": "Whether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "Whether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.",
              "x-intellij-html-description": "<p>Whether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.</p>\n"
            },
            "pretty": {
              "description": "Stylize errors and messages using color and context, this is on by default &mdash; offers you a chance to have less terse,\nsingle colored messages from the compiler.",
              "type": [
                "boolean",
                "null"
              ],
              "default": true,
              "markdownDescription": "Stylize errors and messages using color and context, this is on by default &mdash; offers you a chance to have less terse,\nsingle colored messages from the compiler.",
              "x-intellij-html-description": "<p>Stylize errors and messages using color and context, this is on by default &mdash; offers you a chance to have less terse,\nsingle colored messages from the compiler.</p>\n"
            },
            "removeComments": {
              "description": "Strips all comments from TypeScript files when converting into JavaScript. Defaults to `false`.\n\nFor example, this is a TypeScript file which has a JSDoc comment:\n\n```ts\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nWhen `removeComments` is set to `true`:\n\n```ts twoslash\n// @showEmit\n// @removeComments: true\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nWithout setting `removeComments` or having it as `false`:\n\n```ts twoslash\n// @showEmit\n// @removeComments: false\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nThis means that your comments will show up in the JavaScript code.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Strips all comments from TypeScript files when converting into JavaScript. Defaults to `false`.\n\nFor example, this is a TypeScript file which has a JSDoc comment:\n\n```ts\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nWhen `removeComments` is set to `true`:\n\n```ts twoslash\n// @showEmit\n// @removeComments: true\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nWithout setting `removeComments` or having it as `false`:\n\n```ts twoslash\n// @showEmit\n// @removeComments: false\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = \"Olá Mundo\";\n```\n\nThis means that your comments will show up in the JavaScript code.",
              "x-intellij-html-description": "<p>Strips all comments from TypeScript files when converting into JavaScript. Defaults to <code>false</code>.</p>\n<p>For example, this is a TypeScript file which has a JSDoc comment:</p>\n<pre><code class=\"language-ts\">/** The translation of &#39;Hello world&#39; into Portuguese */\nexport const helloWorldPTBR = &quot;Olá Mundo&quot;;\n</code></pre>\n<p>When <code>removeComments</code> is set to <code>true</code>:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @removeComments: true\n/** The translation of &#39;Hello world&#39; into Portuguese */\nexport const helloWorldPTBR = &quot;Olá Mundo&quot;;\n</code></pre>\n<p>Without setting <code>removeComments</code> or having it as <code>false</code>:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @removeComments: false\n/** The translation of &#39;Hello world&#39; into Portuguese */\nexport const helloWorldPTBR = &quot;Olá Mundo&quot;;\n</code></pre>\n<p>This means that your comments will show up in the JavaScript code.</p>\n"
            },
            "rewriteRelativeImportExtensions": {
              "description": "Rewrite `.ts`, `.tsx`, `.mts`, and `.cts` file extensions in relative import paths to their JavaScript equivalent in output files.\n \nFor more information, see the [TypeScript 5.7 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-5-7.html#path-rewriting-for-relative-paths).",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Rewrite `.ts`, `.tsx`, `.mts`, and `.cts` file extensions in relative import paths to their JavaScript equivalent in output files.\n \nFor more information, see the [TypeScript 5.7 release notes](https://typescriptlang.org/docs/handbook/release-notes/typescript-5-7.html#path-rewriting-for-relative-paths).",
              "x-intellij-html-description": "<p>Rewrite <code>.ts</code>, <code>.tsx</code>, <code>.mts</code>, and <code>.cts</code> file extensions in relative import paths to their JavaScript equivalent in output files.</p>\n<p>For more information, see the <a href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-5-7.html#path-rewriting-for-relative-paths\">TypeScript 5.7 release notes</a>.</p>\n"
            },
            "rootDir": {
              "description": "**Default**: The longest common path of all non-declaration input files. If [`composite`](https://typescriptlang.org/tsconfig/#composite) is set, the default is instead the directory containing the `tsconfig.json` file.\n\nWhen TypeScript compiles files, it keeps the same directory structure in the output directory as exists in the input directory.\n\nFor example, let's say you have some input files:\n\n```\nMyProj\n├── tsconfig.json\n├── core\n│   ├── a.ts\n│   ├── b.ts\n│   ├── sub\n│   │   ├── c.ts\n├── types.d.ts\n```\n\nThe inferred value for `rootDir` is the longest common path of all non-declaration input files, which in this case is `core/`.\n\nIf your [`outDir`](https://typescriptlang.org/tsconfig/#outDir) was `dist`, TypeScript would write this tree:\n\n```\nMyProj\n├── dist\n│   ├── a.js\n│   ├── b.js\n│   ├── sub\n│   │   ├── c.js\n```\n\nHowever, you may have intended for `core` to be part of the output directory structure.\nBy setting `rootDir: \".\"` in `tsconfig.json`, TypeScript would write this tree:\n\n```\nMyProj\n├── dist\n│   ├── core\n│   │   ├── a.js\n│   │   ├── b.js\n│   │   ├── sub\n│   │   │   ├── c.js\n```\n\nImportantly, `rootDir` **does not affect which files become part of the compilation**.\nIt has no interaction with the [`include`](https://typescriptlang.org/tsconfig/#include), [`exclude`](https://typescriptlang.org/tsconfig/#exclude), or [`files`](https://typescriptlang.org/tsconfig/#files) `tsconfig.json` settings.\n\nNote that TypeScript will never write an output file to a directory outside of [`outDir`](https://typescriptlang.org/tsconfig/#outDir), and will never skip emitting a file.\nFor this reason, `rootDir` also enforces that all files which need to be emitted are underneath the `rootDir` path.\n\nFor example, let's say you had this tree:\n\n```\nMyProj\n├── tsconfig.json\n├── core\n│   ├── a.ts\n│   ├── b.ts\n├── helpers.ts\n```\n\nIt would be an error to specify `rootDir` as `core` _and_ [`include`](https://typescriptlang.org/tsconfig/#include) as `*` because it creates a file (`helpers.ts`) that would need to be emitted _outside_ the [`outDir`](https://typescriptlang.org/tsconfig/#outDir) (i.e. `../helpers.js`).",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "**Default**: The longest common path of all non-declaration input files. If [`composite`](https://typescriptlang.org/tsconfig/#composite) is set, the default is instead the directory containing the `tsconfig.json` file.\n\nWhen TypeScript compiles files, it keeps the same directory structure in the output directory as exists in the input directory.\n\nFor example, let's say you have some input files:\n\n```\nMyProj\n├── tsconfig.json\n├── core\n│   ├── a.ts\n│   ├── b.ts\n│   ├── sub\n│   │   ├── c.ts\n├── types.d.ts\n```\n\nThe inferred value for `rootDir` is the longest common path of all non-declaration input files, which in this case is `core/`.\n\nIf your [`outDir`](https://typescriptlang.org/tsconfig/#outDir) was `dist`, TypeScript would write this tree:\n\n```\nMyProj\n├── dist\n│   ├── a.js\n│   ├── b.js\n│   ├── sub\n│   │   ├── c.js\n```\n\nHowever, you may have intended for `core` to be part of the output directory structure.\nBy setting `rootDir: \".\"` in `tsconfig.json`, TypeScript would write this tree:\n\n```\nMyProj\n├── dist\n│   ├── core\n│   │   ├── a.js\n│   │   ├── b.js\n│   │   ├── sub\n│   │   │   ├── c.js\n```\n\nImportantly, `rootDir` **does not affect which files become part of the compilation**.\nIt has no interaction with the [`include`](https://typescriptlang.org/tsconfig/#include), [`exclude`](https://typescriptlang.org/tsconfig/#exclude), or [`files`](https://typescriptlang.org/tsconfig/#files) `tsconfig.json` settings.\n\nNote that TypeScript will never write an output file to a directory outside of [`outDir`](https://typescriptlang.org/tsconfig/#outDir), and will never skip emitting a file.\nFor this reason, `rootDir` also enforces that all files which need to be emitted are underneath the `rootDir` path.\n\nFor example, let's say you had this tree:\n\n```\nMyProj\n├── tsconfig.json\n├── core\n│   ├── a.ts\n│   ├── b.ts\n├── helpers.ts\n```\n\nIt would be an error to specify `rootDir` as `core` _and_ [`include`](https://typescriptlang.org/tsconfig/#include) as `*` because it creates a file (`helpers.ts`) that would need to be emitted _outside_ the [`outDir`](https://typescriptlang.org/tsconfig/#outDir) (i.e. `../helpers.js`).",
              "x-intellij-html-description": "<p><strong>Default</strong>: The longest common path of all non-declaration input files. If <a href=\"https://typescriptlang.org/tsconfig/#composite\"><code>composite</code></a> is set, the default is instead the directory containing the <code>tsconfig.json</code> file.</p>\n<p>When TypeScript compiles files, it keeps the same directory structure in the output directory as exists in the input directory.</p>\n<p>For example, let&#39;s say you have some input files:</p>\n<pre><code>MyProj\n├── tsconfig.json\n├── core\n│   ├── a.ts\n│   ├── b.ts\n│   ├── sub\n│   │   ├── c.ts\n├── types.d.ts\n</code></pre>\n<p>The inferred value for <code>rootDir</code> is the longest common path of all non-declaration input files, which in this case is <code>core/</code>.</p>\n<p>If your <a href=\"https://typescriptlang.org/tsconfig/#outDir\"><code>outDir</code></a> was <code>dist</code>, TypeScript would write this tree:</p>\n<pre><code>MyProj\n├── dist\n│   ├── a.js\n│   ├── b.js\n│   ├── sub\n│   │   ├── c.js\n</code></pre>\n<p>However, you may have intended for <code>core</code> to be part of the output directory structure.\nBy setting <code>rootDir: &quot;.&quot;</code> in <code>tsconfig.json</code>, TypeScript would write this tree:</p>\n<pre><code>MyProj\n├── dist\n│   ├── core\n│   │   ├── a.js\n│   │   ├── b.js\n│   │   ├── sub\n│   │   │   ├── c.js\n</code></pre>\n<p>Importantly, <code>rootDir</code> <strong>does not affect which files become part of the compilation</strong>.\nIt has no interaction with the <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a>, <a href=\"https://typescriptlang.org/tsconfig/#exclude\"><code>exclude</code></a>, or <a href=\"https://typescriptlang.org/tsconfig/#files\"><code>files</code></a> <code>tsconfig.json</code> settings.</p>\n<p>Note that TypeScript will never write an output file to a directory outside of <a href=\"https://typescriptlang.org/tsconfig/#outDir\"><code>outDir</code></a>, and will never skip emitting a file.\nFor this reason, <code>rootDir</code> also enforces that all files which need to be emitted are underneath the <code>rootDir</code> path.</p>\n<p>For example, let&#39;s say you had this tree:</p>\n<pre><code>MyProj\n├── tsconfig.json\n├── core\n│   ├── a.ts\n│   ├── b.ts\n├── helpers.ts\n</code></pre>\n<p>It would be an error to specify <code>rootDir</code> as <code>core</code> <em>and</em> <a href=\"https://typescriptlang.org/tsconfig/#include\"><code>include</code></a> as <code>*</code> because it creates a file (<code>helpers.ts</code>) that would need to be emitted <em>outside</em> the <a href=\"https://typescriptlang.org/tsconfig/#outDir\"><code>outDir</code></a> (i.e. <code>../helpers.js</code>).</p>\n"
            },
            "isolatedModules": {
              "description": "While you can use TypeScript to produce JavaScript code from TypeScript code, it's also common to use other transpilers such as [Babel](https://babeljs.io/) to do this.\nHowever, other transpilers only operate on a single file at a time, which means they can't apply code transforms that depend on understanding the full type system.\nThis restriction also applies to TypeScript's `ts.transpileModule` API which is used by some build tools.\n\nThese limitations can cause runtime problems with some TypeScript features like `const enum`s and `namespace`s.\nSetting the `isolatedModules` flag tells TypeScript to warn you if you write certain code that can't be correctly interpreted by a single-file transpilation process.\n\nIt does not change the behavior of your code, or otherwise change the behavior of TypeScript's checking and emitting process.\n\nSome examples of code which does not work when `isolatedModules` is enabled.\n\n#### Exports of Non-Value Identifiers\n\nIn TypeScript, you can import a _type_ and then subsequently export it:\n\n```ts twoslash\n// @noErrors\nimport { someType, someFunction } from \"someModule\";\n\nsomeFunction();\n\nexport { someType, someFunction };\n```\n\nBecause there's no value for `someType`, the emitted `export` will not try to export it (this would be a runtime error in JavaScript):\n\n```js\nexport { someFunction };\n```\n\nSingle-file transpilers don't know whether `someType` produces a value or not, so it's an error to export a name that only refers to a type.\n\n#### Non-Module Files\n\nIf `isolatedModules` is set, namespaces are only allowed in _modules_ (which means it has some form of `import`/`export`). An error occurs if a namespace is found in a non-module file:\n\n```ts twoslash\n// @errors: 1277\n// @isolatedModules\nnamespace Instantiated {\n export const x = 1;\n}\n```\n\nThis restriction doesn't apply to `.d.ts` files.\n\n#### References to `const enum` members\n\nIn TypeScript, when you reference a `const enum` member, the reference is replaced by its actual value in the emitted JavaScript. Changing this TypeScript:\n\n```ts twoslash\ndeclare const enum Numbers {\n  Zero = 0,\n  One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n```\n\nTo this JavaScript:\n\n```ts twoslash\n// @showEmit\n// @removeComments\ndeclare const enum Numbers {\n  Zero = 0,\n  One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n```\n\nWithout knowledge of the values of these members, other transpilers can't replace the references to `Numbers`, which would be a runtime error if left alone (since there are no `Numbers` object at runtime).\nBecause of this, when `isolatedModules` is set, it is an error to reference an ambient `const enum` member.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "While you can use TypeScript to produce JavaScript code from TypeScript code, it's also common to use other transpilers such as [Babel](https://babeljs.io/) to do this.\nHowever, other transpilers only operate on a single file at a time, which means they can't apply code transforms that depend on understanding the full type system.\nThis restriction also applies to TypeScript's `ts.transpileModule` API which is used by some build tools.\n\nThese limitations can cause runtime problems with some TypeScript features like `const enum`s and `namespace`s.\nSetting the `isolatedModules` flag tells TypeScript to warn you if you write certain code that can't be correctly interpreted by a single-file transpilation process.\n\nIt does not change the behavior of your code, or otherwise change the behavior of TypeScript's checking and emitting process.\n\nSome examples of code which does not work when `isolatedModules` is enabled.\n\n#### Exports of Non-Value Identifiers\n\nIn TypeScript, you can import a _type_ and then subsequently export it:\n\n```ts twoslash\n// @noErrors\nimport { someType, someFunction } from \"someModule\";\n\nsomeFunction();\n\nexport { someType, someFunction };\n```\n\nBecause there's no value for `someType`, the emitted `export` will not try to export it (this would be a runtime error in JavaScript):\n\n```js\nexport { someFunction };\n```\n\nSingle-file transpilers don't know whether `someType` produces a value or not, so it's an error to export a name that only refers to a type.\n\n#### Non-Module Files\n\nIf `isolatedModules` is set, namespaces are only allowed in _modules_ (which means it has some form of `import`/`export`). An error occurs if a namespace is found in a non-module file:\n\n```ts twoslash\n// @errors: 1277\n// @isolatedModules\nnamespace Instantiated {\n export const x = 1;\n}\n```\n\nThis restriction doesn't apply to `.d.ts` files.\n\n#### References to `const enum` members\n\nIn TypeScript, when you reference a `const enum` member, the reference is replaced by its actual value in the emitted JavaScript. Changing this TypeScript:\n\n```ts twoslash\ndeclare const enum Numbers {\n  Zero = 0,\n  One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n```\n\nTo this JavaScript:\n\n```ts twoslash\n// @showEmit\n// @removeComments\ndeclare const enum Numbers {\n  Zero = 0,\n  One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n```\n\nWithout knowledge of the values of these members, other transpilers can't replace the references to `Numbers`, which would be a runtime error if left alone (since there are no `Numbers` object at runtime).\nBecause of this, when `isolatedModules` is set, it is an error to reference an ambient `const enum` member.",
              "x-intellij-html-description": "<p>While you can use TypeScript to produce JavaScript code from TypeScript code, it&#39;s also common to use other transpilers such as <a href=\"https://babeljs.io/\">Babel</a> to do this.\nHowever, other transpilers only operate on a single file at a time, which means they can&#39;t apply code transforms that depend on understanding the full type system.\nThis restriction also applies to TypeScript&#39;s <code>ts.transpileModule</code> API which is used by some build tools.</p>\n<p>These limitations can cause runtime problems with some TypeScript features like <code>const enum</code>s and <code>namespace</code>s.\nSetting the <code>isolatedModules</code> flag tells TypeScript to warn you if you write certain code that can&#39;t be correctly interpreted by a single-file transpilation process.</p>\n<p>It does not change the behavior of your code, or otherwise change the behavior of TypeScript&#39;s checking and emitting process.</p>\n<p>Some examples of code which does not work when <code>isolatedModules</code> is enabled.</p>\n<h4>Exports of Non-Value Identifiers</h4>\n<p>In TypeScript, you can import a <em>type</em> and then subsequently export it:</p>\n<pre><code class=\"language-ts\">// @noErrors\nimport { someType, someFunction } from &quot;someModule&quot;;\n\nsomeFunction();\n\nexport { someType, someFunction };\n</code></pre>\n<p>Because there&#39;s no value for <code>someType</code>, the emitted <code>export</code> will not try to export it (this would be a runtime error in JavaScript):</p>\n<pre><code class=\"language-js\">export { someFunction };\n</code></pre>\n<p>Single-file transpilers don&#39;t know whether <code>someType</code> produces a value or not, so it&#39;s an error to export a name that only refers to a type.</p>\n<h4>Non-Module Files</h4>\n<p>If <code>isolatedModules</code> is set, namespaces are only allowed in <em>modules</em> (which means it has some form of <code>import</code>/<code>export</code>). An error occurs if a namespace is found in a non-module file:</p>\n<pre><code class=\"language-ts\">// @errors: 1277\n// @isolatedModules\nnamespace Instantiated {\n export const x = 1;\n}\n</code></pre>\n<p>This restriction doesn&#39;t apply to <code>.d.ts</code> files.</p>\n<h4>References to <code>const enum</code> members</h4>\n<p>In TypeScript, when you reference a <code>const enum</code> member, the reference is replaced by its actual value in the emitted JavaScript. Changing this TypeScript:</p>\n<pre><code class=\"language-ts\">declare const enum Numbers {\n  Zero = 0,\n  One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n</code></pre>\n<p>To this JavaScript:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @removeComments\ndeclare const enum Numbers {\n  Zero = 0,\n  One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n</code></pre>\n<p>Without knowledge of the values of these members, other transpilers can&#39;t replace the references to <code>Numbers</code>, which would be a runtime error if left alone (since there are no <code>Numbers</code> object at runtime).\nBecause of this, when <code>isolatedModules</code> is set, it is an error to reference an ambient <code>const enum</code> member.</p>\n"
            },
            "sourceMap": {
              "description": "Enables the generation of [sourcemap files](https://developer.mozilla.org/docs/Tools/Debugger/How_to/Use_a_source_map).\nThese files allow debuggers and other tools to display the original TypeScript source code when actually working with the emitted JavaScript files.\nSource map files are emitted as `.js.map` (or `.jsx.map`) files next to the corresponding `.js` output file.\n\nThe `.js` files will in turn contain a sourcemap comment to indicate where the files are to external tools, for example:\n\n```ts\n// helloWorld.ts\nexport declare const helloWorld = \"hi\";\n```\n\nCompiling with `sourceMap` set to `true` creates the following JavaScript file:\n\n```js\n// helloWorld.js\n\"use strict\";\nObject.defineProperty(exports, \"__esModule\", { value: true });\nexports.helloWorld = \"hi\";\n//# sourceMappingURL=// helloWorld.js.map\n```\n\nAnd this also generates this json map:\n\n```json\n// helloWorld.js.map\n{\n  \"version\": 3,\n  \"file\": \"ex.js\",\n  \"sourceRoot\": \"\",\n  \"sources\": [\"../ex.ts\"],\n  \"names\": [],\n  \"mappings\": \";;AAAa,QAAA,UAAU,GAAG,IAAI,CAAA\"\n}\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Enables the generation of [sourcemap files](https://developer.mozilla.org/docs/Tools/Debugger/How_to/Use_a_source_map).\nThese files allow debuggers and other tools to display the original TypeScript source code when actually working with the emitted JavaScript files.\nSource map files are emitted as `.js.map` (or `.jsx.map`) files next to the corresponding `.js` output file.\n\nThe `.js` files will in turn contain a sourcemap comment to indicate where the files are to external tools, for example:\n\n```ts\n// helloWorld.ts\nexport declare const helloWorld = \"hi\";\n```\n\nCompiling with `sourceMap` set to `true` creates the following JavaScript file:\n\n```js\n// helloWorld.js\n\"use strict\";\nObject.defineProperty(exports, \"__esModule\", { value: true });\nexports.helloWorld = \"hi\";\n//# sourceMappingURL=// helloWorld.js.map\n```\n\nAnd this also generates this json map:\n\n```json\n// helloWorld.js.map\n{\n  \"version\": 3,\n  \"file\": \"ex.js\",\n  \"sourceRoot\": \"\",\n  \"sources\": [\"../ex.ts\"],\n  \"names\": [],\n  \"mappings\": \";;AAAa,QAAA,UAAU,GAAG,IAAI,CAAA\"\n}\n```",
              "x-intellij-html-description": "<p>Enables the generation of <a href=\"https://developer.mozilla.org/docs/Tools/Debugger/How_to/Use_a_source_map\">sourcemap files</a>.\nThese files allow debuggers and other tools to display the original TypeScript source code when actually working with the emitted JavaScript files.\nSource map files are emitted as <code>.js.map</code> (or <code>.jsx.map</code>) files next to the corresponding <code>.js</code> output file.</p>\n<p>The <code>.js</code> files will in turn contain a sourcemap comment to indicate where the files are to external tools, for example:</p>\n<pre><code class=\"language-ts\">// helloWorld.ts\nexport declare const helloWorld = &quot;hi&quot;;\n</code></pre>\n<p>Compiling with <code>sourceMap</code> set to <code>true</code> creates the following JavaScript file:</p>\n<pre><code class=\"language-js\">// helloWorld.js\n&quot;use strict&quot;;\nObject.defineProperty(exports, &quot;__esModule&quot;, { value: true });\nexports.helloWorld = &quot;hi&quot;;\n//# sourceMappingURL=// helloWorld.js.map\n</code></pre>\n<p>And this also generates this json map:</p>\n<pre><code class=\"language-json\">// helloWorld.js.map\n{\n  &quot;version&quot;: 3,\n  &quot;file&quot;: &quot;ex.js&quot;,\n  &quot;sourceRoot&quot;: &quot;&quot;,\n  &quot;sources&quot;: [&quot;../ex.ts&quot;],\n  &quot;names&quot;: [],\n  &quot;mappings&quot;: &quot;;;AAAa,QAAA,UAAU,GAAG,IAAI,CAAA&quot;\n}\n</code></pre>\n"
            },
            "sourceRoot": {
              "description": "Specify the location where a debugger should locate TypeScript files instead of relative source locations.\nThis string is treated verbatim inside the source-map where you can use a path or a URL:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"sourceMap\": true,\n    \"sourceRoot\": \"https://my-website.com/debug/source/\"\n  }\n}\n```\n\nWould declare that `index.js` will have a source file at `https://my-website.com/debug/source/index.ts`.",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "Specify the location where a debugger should locate TypeScript files instead of relative source locations.\nThis string is treated verbatim inside the source-map where you can use a path or a URL:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"sourceMap\": true,\n    \"sourceRoot\": \"https://my-website.com/debug/source/\"\n  }\n}\n```\n\nWould declare that `index.js` will have a source file at `https://my-website.com/debug/source/index.ts`.",
              "x-intellij-html-description": "<p>Specify the location where a debugger should locate TypeScript files instead of relative source locations.\nThis string is treated verbatim inside the source-map where you can use a path or a URL:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;sourceMap&quot;: true,\n    &quot;sourceRoot&quot;: &quot;https://my-website.com/debug/source/&quot;\n  }\n}\n</code></pre>\n<p>Would declare that <code>index.js</code> will have a source file at <code>https://my-website.com/debug/source/index.ts</code>.</p>\n"
            },
            "suppressExcessPropertyErrors": {
              "description": "This disables reporting of excess property errors, such as the one shown in the following example:\n\n```ts twoslash\n// @errors: 2322\ntype Point = { x: number; y: number };\nconst p: Point = { x: 1, y: 3, m: 10 };\n```\n\nThis flag was added to help people migrate to the stricter checking of new object literals in [TypeScript 1.6](https://typescriptlang.org/docs/handbook/release-notes/typescript-1-6.html#stricter-object-literal-assignment-checks).\n\nWe don't recommend using this flag in a modern codebase, you can suppress one-off cases where you need it using `// @ts-ignore`.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "This disables reporting of excess property errors, such as the one shown in the following example:\n\n```ts twoslash\n// @errors: 2322\ntype Point = { x: number; y: number };\nconst p: Point = { x: 1, y: 3, m: 10 };\n```\n\nThis flag was added to help people migrate to the stricter checking of new object literals in [TypeScript 1.6](https://typescriptlang.org/docs/handbook/release-notes/typescript-1-6.html#stricter-object-literal-assignment-checks).\n\nWe don't recommend using this flag in a modern codebase, you can suppress one-off cases where you need it using `// @ts-ignore`.",
              "x-intellij-html-description": "<p>This disables reporting of excess property errors, such as the one shown in the following example:</p>\n<pre><code class=\"language-ts\">// @errors: 2322\ntype Point = { x: number; y: number };\nconst p: Point = { x: 1, y: 3, m: 10 };\n</code></pre>\n<p>This flag was added to help people migrate to the stricter checking of new object literals in <a href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-1-6.html#stricter-object-literal-assignment-checks\">TypeScript 1.6</a>.</p>\n<p>We don&#39;t recommend using this flag in a modern codebase, you can suppress one-off cases where you need it using <code>// @ts-ignore</code>.</p>\n"
            },
            "suppressImplicitAnyIndexErrors": {
              "description": "Turning `suppressImplicitAnyIndexErrors` on suppresses reporting the error about implicit anys when indexing into objects, as shown in the following example:\n\n```ts twoslash\n// @noImplicitAny: true\n// @suppressImplicitAnyIndexErrors: false\n// @strict: true\n// @errors: 7053\nconst obj = { x: 10 };\nconsole.log(obj[\"foo\"]);\n```\n\nUsing `suppressImplicitAnyIndexErrors` is quite a drastic approach. It is recommended to use a `@ts-ignore` comment instead:\n\n```ts twoslash\n// @noImplicitAny: true\n// @strict: true\nconst obj = { x: 10 };\n// @ts-ignore\nconsole.log(obj[\"foo\"]);\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Turning `suppressImplicitAnyIndexErrors` on suppresses reporting the error about implicit anys when indexing into objects, as shown in the following example:\n\n```ts twoslash\n// @noImplicitAny: true\n// @suppressImplicitAnyIndexErrors: false\n// @strict: true\n// @errors: 7053\nconst obj = { x: 10 };\nconsole.log(obj[\"foo\"]);\n```\n\nUsing `suppressImplicitAnyIndexErrors` is quite a drastic approach. It is recommended to use a `@ts-ignore` comment instead:\n\n```ts twoslash\n// @noImplicitAny: true\n// @strict: true\nconst obj = { x: 10 };\n// @ts-ignore\nconsole.log(obj[\"foo\"]);\n```",
              "x-intellij-html-description": "<p>Turning <code>suppressImplicitAnyIndexErrors</code> on suppresses reporting the error about implicit anys when indexing into objects, as shown in the following example:</p>\n<pre><code class=\"language-ts\">// @noImplicitAny: true\n// @suppressImplicitAnyIndexErrors: false\n// @strict: true\n// @errors: 7053\nconst obj = { x: 10 };\nconsole.log(obj[&quot;foo&quot;]);\n</code></pre>\n<p>Using <code>suppressImplicitAnyIndexErrors</code> is quite a drastic approach. It is recommended to use a <code>@ts-ignore</code> comment instead:</p>\n<pre><code class=\"language-ts\">// @noImplicitAny: true\n// @strict: true\nconst obj = { x: 10 };\n// @ts-ignore\nconsole.log(obj[&quot;foo&quot;]);\n</code></pre>\n"
            },
            "stripInternal": {
              "description": "Do not emit declarations for code that has an `@internal` annotation in its JSDoc comment.\nThis is an internal compiler option; use at your own risk, because the compiler does not check that the result is valid.\nIf you are searching for a tool to handle additional levels of visibility within your `d.ts` files, look at [api-extractor](https://api-extractor.com/).\n\n```ts twoslash\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n  return daysInAWeek * dayRate;\n}\n```\n\nWith the flag set to `false` (default):\n\n```ts twoslash\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n  return daysInAWeek * dayRate;\n}\n```\n\nWith `stripInternal` set to `true` the `d.ts` emitted will be redacted.\n\n```ts twoslash\n// @stripinternal\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n  return daysInAWeek * dayRate;\n}\n```\n\nThe JavaScript output is still the same.",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "Do not emit declarations for code that has an `@internal` annotation in its JSDoc comment.\nThis is an internal compiler option; use at your own risk, because the compiler does not check that the result is valid.\nIf you are searching for a tool to handle additional levels of visibility within your `d.ts` files, look at [api-extractor](https://api-extractor.com/).\n\n```ts twoslash\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n  return daysInAWeek * dayRate;\n}\n```\n\nWith the flag set to `false` (default):\n\n```ts twoslash\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n  return daysInAWeek * dayRate;\n}\n```\n\nWith `stripInternal` set to `true` the `d.ts` emitted will be redacted.\n\n```ts twoslash\n// @stripinternal\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n  return daysInAWeek * dayRate;\n}\n```\n\nThe JavaScript output is still the same.",
              "x-intellij-html-description": "<p>Do not emit declarations for code that has an <code>@internal</code> annotation in its JSDoc comment.\nThis is an internal compiler option; use at your own risk, because the compiler does not check that the result is valid.\nIf you are searching for a tool to handle additional levels of visibility within your <code>d.ts</code> files, look at <a href=\"https://api-extractor.com/\">api-extractor</a>.</p>\n<pre><code class=\"language-ts\">/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n  return daysInAWeek * dayRate;\n}\n</code></pre>\n<p>With the flag set to <code>false</code> (default):</p>\n<pre><code class=\"language-ts\">// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n  return daysInAWeek * dayRate;\n}\n</code></pre>\n<p>With <code>stripInternal</code> set to <code>true</code> the <code>d.ts</code> emitted will be redacted.</p>\n<pre><code class=\"language-ts\">// @stripinternal\n// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\n/**\n * Days available in a week\n * @internal\n */\nexport const daysInAWeek = 7;\n\n/** Calculate how much someone earns in a week */\nexport function weeklySalary(dayRate: number) {\n  return daysInAWeek * dayRate;\n}\n</code></pre>\n<p>The JavaScript output is still the same.</p>\n"
            },
            "target": {
              "description": "Modern browsers support all ES6 features, so `ES6` is a good choice.\nYou might choose to set a lower target if your code is deployed to older environments, or a higher target if your code is guaranteed to run in newer environments.\n\nThe `target` setting changes which JS features are downleveled and which are left intact.\nFor example, an arrow function `() => this` will be turned into an equivalent `function` expression if `target` is ES5 or lower.\n\nChanging `target` also changes the default value of [`lib`](https://typescriptlang.org/tsconfig/#lib).\nYou may \"mix and match\" `target` and `lib` settings as desired, but you could just set `target` for convenience.\n\nFor developer platforms like Node there are baselines for the `target`, depending on the type of platform and its version. You can find a set of community organized TSConfigs at [tsconfig/bases](https://github.com/tsconfig/bases#centralized-recommendations-for-tsconfig-bases), which has configurations for common platforms and their versions.\n\nThe special `ESNext` value refers to the highest version your version of TypeScript supports.\nThis setting should be used with caution, since it doesn't mean the same thing between different TypeScript versions and can make upgrades less predictable.",
              "type": [
                "string",
                "null"
              ],
              "default": "es5",
              "anyOf": [
                {
                  "enum": [
                    "es3",
                    "es5",
                    "es6",
                    "es2015",
                    "es2016",
                    "es2017",
                    "es2018",
                    "es2019",
                    "es2020",
                    "es2021",
                    "es2022",
                    "es2023",
                    "es2024",
                    "es2025",
                    "esnext"
                  ]
                },
                {
                  "pattern": "^([Ee][Ss]([356]|(20(1[56789]|2[012345]))|[Nn][Ee][Xx][Tt]))$"
                }
              ],
              "markdownDescription": "Modern browsers support all ES6 features, so `ES6` is a good choice.\nYou might choose to set a lower target if your code is deployed to older environments, or a higher target if your code is guaranteed to run in newer environments.\n\nThe `target` setting changes which JS features are downleveled and which are left intact.\nFor example, an arrow function `() => this` will be turned into an equivalent `function` expression if `target` is ES5 or lower.\n\nChanging `target` also changes the default value of [`lib`](https://typescriptlang.org/tsconfig/#lib).\nYou may \"mix and match\" `target` and `lib` settings as desired, but you could just set `target` for convenience.\n\nFor developer platforms like Node there are baselines for the `target`, depending on the type of platform and its version. You can find a set of community organized TSConfigs at [tsconfig/bases](https://github.com/tsconfig/bases#centralized-recommendations-for-tsconfig-bases), which has configurations for common platforms and their versions.\n\nThe special `ESNext` value refers to the highest version your version of TypeScript supports.\nThis setting should be used with caution, since it doesn't mean the same thing between different TypeScript versions and can make upgrades less predictable.",
              "x-intellij-html-description": "<p>Modern browsers support all ES6 features, so <code>ES6</code> is a good choice.\nYou might choose to set a lower target if your code is deployed to older environments, or a higher target if your code is guaranteed to run in newer environments.</p>\n<p>The <code>target</code> setting changes which JS features are downleveled and which are left intact.\nFor example, an arrow function <code>() =&gt; this</code> will be turned into an equivalent <code>function</code> expression if <code>target</code> is ES5 or lower.</p>\n<p>Changing <code>target</code> also changes the default value of <a href=\"https://typescriptlang.org/tsconfig/#lib\"><code>lib</code></a>.\nYou may &quot;mix and match&quot; <code>target</code> and <code>lib</code> settings as desired, but you could just set <code>target</code> for convenience.</p>\n<p>For developer platforms like Node there are baselines for the <code>target</code>, depending on the type of platform and its version. You can find a set of community organized TSConfigs at <a href=\"https://github.com/tsconfig/bases#centralized-recommendations-for-tsconfig-bases\">tsconfig/bases</a>, which has configurations for common platforms and their versions.</p>\n<p>The special <code>ESNext</code> value refers to the highest version your version of TypeScript supports.\nThis setting should be used with caution, since it doesn&#39;t mean the same thing between different TypeScript versions and can make upgrades less predictable.</p>\n"
            },
            "useUnknownInCatchVariables": {
              "description": "In TypeScript 4.0, support was added to allow changing the type of the variable in a catch clause from `any` to `unknown`. Allowing for code like:\n\n```ts twoslash\n// @useUnknownInCatchVariables\ntry {\n  // ...\n} catch (err: unknown) {\n  // We have to verify err is an\n  // error before using it as one.\n  if (err instanceof Error) {\n    console.log(err.message);\n  }\n}\n```\n\nThis pattern ensures that error handling code becomes more comprehensive because you cannot guarantee that the object being thrown _is_ a Error subclass ahead of time. With the flag `useUnknownInCatchVariables` enabled, then you do not need the additional syntax (`: unknown`) nor a linter rule to try enforce this behavior.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "In TypeScript 4.0, support was added to allow changing the type of the variable in a catch clause from `any` to `unknown`. Allowing for code like:\n\n```ts twoslash\n// @useUnknownInCatchVariables\ntry {\n  // ...\n} catch (err: unknown) {\n  // We have to verify err is an\n  // error before using it as one.\n  if (err instanceof Error) {\n    console.log(err.message);\n  }\n}\n```\n\nThis pattern ensures that error handling code becomes more comprehensive because you cannot guarantee that the object being thrown _is_ a Error subclass ahead of time. With the flag `useUnknownInCatchVariables` enabled, then you do not need the additional syntax (`: unknown`) nor a linter rule to try enforce this behavior.",
              "x-intellij-html-description": "<p>In TypeScript 4.0, support was added to allow changing the type of the variable in a catch clause from <code>any</code> to <code>unknown</code>. Allowing for code like:</p>\n<pre><code class=\"language-ts\">// @useUnknownInCatchVariables\ntry {\n  // ...\n} catch (err: unknown) {\n  // We have to verify err is an\n  // error before using it as one.\n  if (err instanceof Error) {\n    console.log(err.message);\n  }\n}\n</code></pre>\n<p>This pattern ensures that error handling code becomes more comprehensive because you cannot guarantee that the object being thrown <em>is</em> a Error subclass ahead of time. With the flag <code>useUnknownInCatchVariables</code> enabled, then you do not need the additional syntax (<code>: unknown</code>) nor a linter rule to try enforce this behavior.</p>\n"
            },
            "watch": {
              "description": "Watch input files.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "fallbackPolling": {
              "description": "Specify the polling strategy to use when the system runs out of or doesn't support native file watchers. Requires TypeScript version 3.8 or later.",
              "enum": [
                "fixedPollingInterval",
                "priorityPollingInterval",
                "dynamicPriorityPolling",
                "fixedInterval",
                "priorityInterval",
                "dynamicPriority",
                "fixedChunkSize"
              ]
            },
            "watchDirectory": {
              "description": "Specify the strategy for watching directories under systems that lack recursive file-watching functionality. Requires TypeScript version 3.8 or later.",
              "enum": [
                "useFsEvents",
                "fixedPollingInterval",
                "dynamicPriorityPolling",
                "fixedChunkSizePolling"
              ],
              "default": "useFsEvents"
            },
            "watchFile": {
              "description": "Specify the strategy for watching individual files. Requires TypeScript version 3.8 or later.",
              "enum": [
                "fixedPollingInterval",
                "priorityPollingInterval",
                "dynamicPriorityPolling",
                "useFsEvents",
                "useFsEventsOnParentDirectory",
                "fixedChunkSizePolling"
              ],
              "default": "useFsEvents"
            },
            "experimentalDecorators": {
              "description": "Enables [experimental support for decorators](https://github.com/tc39/proposal-decorators), which is a version of decorators that predates the TC39 standardization process.\n\nDecorators are a language feature which hasn't yet been fully ratified into the JavaScript specification.\nThis means that the implementation version in TypeScript may differ from the implementation in JavaScript when it is decided by TC39.\n\nYou can find out more about decorator support in TypeScript in [the handbook](https://typescriptlang.org/docs/handbook/decorators.html).",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "Enables [experimental support for decorators](https://github.com/tc39/proposal-decorators), which is a version of decorators that predates the TC39 standardization process.\n\nDecorators are a language feature which hasn't yet been fully ratified into the JavaScript specification.\nThis means that the implementation version in TypeScript may differ from the implementation in JavaScript when it is decided by TC39.\n\nYou can find out more about decorator support in TypeScript in [the handbook](https://typescriptlang.org/docs/handbook/decorators.html).",
              "x-intellij-html-description": "<p>Enables <a href=\"https://github.com/tc39/proposal-decorators\">experimental support for decorators</a>, which is a version of decorators that predates the TC39 standardization process.</p>\n<p>Decorators are a language feature which hasn&#39;t yet been fully ratified into the JavaScript specification.\nThis means that the implementation version in TypeScript may differ from the implementation in JavaScript when it is decided by TC39.</p>\n<p>You can find out more about decorator support in TypeScript in <a href=\"https://typescriptlang.org/docs/handbook/decorators.html\">the handbook</a>.</p>\n"
            },
            "emitDecoratorMetadata": {
              "description": "Enables experimental support for emitting type metadata for decorators which works with the module [`reflect-metadata`](https://www.npmjs.com/package/reflect-metadata).\n\nFor example, here is the TypeScript\n\n```ts twoslash\n// @experimentalDecorators\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n  console.log(target);\n  console.log(propertyKey);\n  console.log(descriptor);\n}\n\nclass Demo {\n  @LogMethod\n  public foo(bar: number) {\n    // do nothing\n  }\n}\n\nconst demo = new Demo();\n```\n\nWith `emitDecoratorMetadata` not set to true (default) the emitted JavaScript is:\n\n```ts twoslash\n// @experimentalDecorators\n// @showEmit\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n  console.log(target);\n  console.log(propertyKey);\n  console.log(descriptor);\n}\n\nclass Demo {\n  @LogMethod\n  public foo(bar: number) {\n    // do nothing\n  }\n}\n\nconst demo = new Demo();\n```\n\nWith `emitDecoratorMetadata` set to true the emitted JavaScript is:\n\n```ts twoslash\n// @experimentalDecorators\n// @showEmit\n// @emitDecoratorMetadata\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n  console.log(target);\n  console.log(propertyKey);\n  console.log(descriptor);\n}\n\nclass Demo {\n  @LogMethod\n  public foo(bar: number) {\n    // do nothing\n  }\n}\n\nconst demo = new Demo();\n```",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "Enables experimental support for emitting type metadata for decorators which works with the module [`reflect-metadata`](https://www.npmjs.com/package/reflect-metadata).\n\nFor example, here is the TypeScript\n\n```ts twoslash\n// @experimentalDecorators\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n  console.log(target);\n  console.log(propertyKey);\n  console.log(descriptor);\n}\n\nclass Demo {\n  @LogMethod\n  public foo(bar: number) {\n    // do nothing\n  }\n}\n\nconst demo = new Demo();\n```\n\nWith `emitDecoratorMetadata` not set to true (default) the emitted JavaScript is:\n\n```ts twoslash\n// @experimentalDecorators\n// @showEmit\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n  console.log(target);\n  console.log(propertyKey);\n  console.log(descriptor);\n}\n\nclass Demo {\n  @LogMethod\n  public foo(bar: number) {\n    // do nothing\n  }\n}\n\nconst demo = new Demo();\n```\n\nWith `emitDecoratorMetadata` set to true the emitted JavaScript is:\n\n```ts twoslash\n// @experimentalDecorators\n// @showEmit\n// @emitDecoratorMetadata\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n  console.log(target);\n  console.log(propertyKey);\n  console.log(descriptor);\n}\n\nclass Demo {\n  @LogMethod\n  public foo(bar: number) {\n    // do nothing\n  }\n}\n\nconst demo = new Demo();\n```",
              "x-intellij-html-description": "<p>Enables experimental support for emitting type metadata for decorators which works with the module <a href=\"https://www.npmjs.com/package/reflect-metadata\"><code>reflect-metadata</code></a>.</p>\n<p>For example, here is the TypeScript</p>\n<pre><code class=\"language-ts\">// @experimentalDecorators\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n  console.log(target);\n  console.log(propertyKey);\n  console.log(descriptor);\n}\n\nclass Demo {\n  @LogMethod\n  public foo(bar: number) {\n    // do nothing\n  }\n}\n\nconst demo = new Demo();\n</code></pre>\n<p>With <code>emitDecoratorMetadata</code> not set to true (default) the emitted JavaScript is:</p>\n<pre><code class=\"language-ts\">// @experimentalDecorators\n// @showEmit\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n  console.log(target);\n  console.log(propertyKey);\n  console.log(descriptor);\n}\n\nclass Demo {\n  @LogMethod\n  public foo(bar: number) {\n    // do nothing\n  }\n}\n\nconst demo = new Demo();\n</code></pre>\n<p>With <code>emitDecoratorMetadata</code> set to true the emitted JavaScript is:</p>\n<pre><code class=\"language-ts\">// @experimentalDecorators\n// @showEmit\n// @emitDecoratorMetadata\nfunction LogMethod(target: any, propertyKey: string | symbol, descriptor: PropertyDescriptor) {\n  console.log(target);\n  console.log(propertyKey);\n  console.log(descriptor);\n}\n\nclass Demo {\n  @LogMethod\n  public foo(bar: number) {\n    // do nothing\n  }\n}\n\nconst demo = new Demo();\n</code></pre>\n"
            },
            "allowUnusedLabels": {
              "description": "When:\n\n- `undefined` (default) provide suggestions as warnings to editors\n- `true` unused labels are ignored\n- `false` raises compiler errors about unused labels\n\nLabels are very rare in JavaScript and typically indicate an attempt to write an object literal:\n\n```ts twoslash\n// @errors: 7028\n// @allowUnusedLabels: false\nfunction verifyAge(age: number) {\n  // Forgot 'return' statement\n  if (age > 18) {\n    verified: true;\n  }\n}\n```",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "When:\n\n- `undefined` (default) provide suggestions as warnings to editors\n- `true` unused labels are ignored\n- `false` raises compiler errors about unused labels\n\nLabels are very rare in JavaScript and typically indicate an attempt to write an object literal:\n\n```ts twoslash\n// @errors: 7028\n// @allowUnusedLabels: false\nfunction verifyAge(age: number) {\n  // Forgot 'return' statement\n  if (age > 18) {\n    verified: true;\n  }\n}\n```",
              "x-intellij-html-description": "<p>When:</p>\n<ul>\n<li><code>undefined</code> (default) provide suggestions as warnings to editors</li>\n<li><code>true</code> unused labels are ignored</li>\n<li><code>false</code> raises compiler errors about unused labels</li>\n</ul>\n<p>Labels are very rare in JavaScript and typically indicate an attempt to write an object literal:</p>\n<pre><code class=\"language-ts\">// @errors: 7028\n// @allowUnusedLabels: false\nfunction verifyAge(age: number) {\n  // Forgot &#39;return&#39; statement\n  if (age &gt; 18) {\n    verified: true;\n  }\n}\n</code></pre>\n"
            },
            "noImplicitReturns": {
              "description": "When enabled, TypeScript will check all code paths in a function to ensure they return a value.\n\n```ts twoslash\n// @errors: 2366 2322\nfunction lookupHeadphonesManufacturer(color: \"blue\" | \"black\"): string {\n  if (color === \"blue\") {\n    return \"beats\";\n  } else {\n    \"bose\";\n  }\n}\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "When enabled, TypeScript will check all code paths in a function to ensure they return a value.\n\n```ts twoslash\n// @errors: 2366 2322\nfunction lookupHeadphonesManufacturer(color: \"blue\" | \"black\"): string {\n  if (color === \"blue\") {\n    return \"beats\";\n  } else {\n    \"bose\";\n  }\n}\n```",
              "x-intellij-html-description": "<p>When enabled, TypeScript will check all code paths in a function to ensure they return a value.</p>\n<pre><code class=\"language-ts\">// @errors: 2366 2322\nfunction lookupHeadphonesManufacturer(color: &quot;blue&quot; | &quot;black&quot;): string {\n  if (color === &quot;blue&quot;) {\n    return &quot;beats&quot;;\n  } else {\n    &quot;bose&quot;;\n  }\n}\n</code></pre>\n"
            },
            "noUncheckedIndexedAccess": {
              "description": "TypeScript has a way to describe objects which have unknown keys but known values on an object, via index signatures.\n\n```ts twoslash\ninterface EnvironmentVars {\n  NAME: string;\n  OS: string;\n\n  // Unknown properties are covered by this index signature.\n  [propName: string]: string;\n}\n\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n//    ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n//    ^?\n```\n\nTurning on `noUncheckedIndexedAccess` will add `undefined` to any un-declared field in the type.\n\n```ts twoslash\ninterface EnvironmentVars {\n  NAME: string;\n  OS: string;\n\n  // Unknown properties are covered by this index signature.\n  [propName: string]: string;\n}\n// @noUncheckedIndexedAccess\n// ---cut---\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n//    ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n//    ^?\n```",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "TypeScript has a way to describe objects which have unknown keys but known values on an object, via index signatures.\n\n```ts twoslash\ninterface EnvironmentVars {\n  NAME: string;\n  OS: string;\n\n  // Unknown properties are covered by this index signature.\n  [propName: string]: string;\n}\n\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n//    ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n//    ^?\n```\n\nTurning on `noUncheckedIndexedAccess` will add `undefined` to any un-declared field in the type.\n\n```ts twoslash\ninterface EnvironmentVars {\n  NAME: string;\n  OS: string;\n\n  // Unknown properties are covered by this index signature.\n  [propName: string]: string;\n}\n// @noUncheckedIndexedAccess\n// ---cut---\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n//    ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n//    ^?\n```",
              "x-intellij-html-description": "<p>TypeScript has a way to describe objects which have unknown keys but known values on an object, via index signatures.</p>\n<pre><code class=\"language-ts\">interface EnvironmentVars {\n  NAME: string;\n  OS: string;\n\n  // Unknown properties are covered by this index signature.\n  [propName: string]: string;\n}\n\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n//    ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n//    ^?\n</code></pre>\n<p>Turning on <code>noUncheckedIndexedAccess</code> will add <code>undefined</code> to any un-declared field in the type.</p>\n<pre><code class=\"language-ts\">interface EnvironmentVars {\n  NAME: string;\n  OS: string;\n\n  // Unknown properties are covered by this index signature.\n  [propName: string]: string;\n}\n// @noUncheckedIndexedAccess\n// ---cut---\ndeclare const env: EnvironmentVars;\n\n// Declared as existing\nconst sysName = env.NAME;\nconst os = env.OS;\n//    ^?\n\n// Not declared, but because of the index\n// signature, then it is considered a string\nconst nodeEnv = env.NODE_ENV;\n//    ^?\n</code></pre>\n"
            },
            "noFallthroughCasesInSwitch": {
              "description": "Report errors for fallthrough cases in switch statements.\nEnsures that any non-empty case inside a switch statement includes either `break`, `return`, or `throw`.\nThis means you won't accidentally ship a case fallthrough bug.\n\n```ts twoslash\n// @noFallthroughCasesInSwitch\n// @errors: 7029\nconst a: number = 6;\n\nswitch (a) {\n  case 0:\n    console.log(\"even\");\n  case 1:\n    console.log(\"odd\");\n    break;\n}\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Report errors for fallthrough cases in switch statements.\nEnsures that any non-empty case inside a switch statement includes either `break`, `return`, or `throw`.\nThis means you won't accidentally ship a case fallthrough bug.\n\n```ts twoslash\n// @noFallthroughCasesInSwitch\n// @errors: 7029\nconst a: number = 6;\n\nswitch (a) {\n  case 0:\n    console.log(\"even\");\n  case 1:\n    console.log(\"odd\");\n    break;\n}\n```",
              "x-intellij-html-description": "<p>Report errors for fallthrough cases in switch statements.\nEnsures that any non-empty case inside a switch statement includes either <code>break</code>, <code>return</code>, or <code>throw</code>.\nThis means you won&#39;t accidentally ship a case fallthrough bug.</p>\n<pre><code class=\"language-ts\">// @noFallthroughCasesInSwitch\n// @errors: 7029\nconst a: number = 6;\n\nswitch (a) {\n  case 0:\n    console.log(&quot;even&quot;);\n  case 1:\n    console.log(&quot;odd&quot;);\n    break;\n}\n</code></pre>\n"
            },
            "noImplicitOverride": {
              "description": "When working with classes which use inheritance, it's possible for a sub-class to get \"out of sync\" with the functions it overloads when they are renamed in the base class.\n\nFor example, imagine you are modeling a music album syncing system:\n\n```ts twoslash\nclass Album {\n  download() {\n    // Default behavior\n  }\n}\n\nclass SharedAlbum extends Album {\n  download() {\n    // Override to get info from many sources\n  }\n}\n```\n\nThen when you add support for machine-learning generated playlists, you refactor the `Album` class to have a 'setup' function instead:\n\n```ts twoslash\nclass Album {\n  setup() {\n    // Default behavior\n  }\n}\n\nclass MLAlbum extends Album {\n  setup() {\n    // Override to get info from algorithm\n  }\n}\n\nclass SharedAlbum extends Album {\n  download() {\n    // Override to get info from many sources\n  }\n}\n```\n\nIn this case, TypeScript has provided no warning that `download` on `SharedAlbum` _expected_ to override a function in the base class.\n\nUsing `noImplicitOverride` you can ensure that the sub-classes never go out of sync, by ensuring that functions which override include the keyword `override`.\n\nThe following example has `noImplicitOverride` enabled, and you can see the error received when `override` is missing:\n\n```ts twoslash\n// @noImplicitOverride\n// @errors: 4114\nclass Album {\n  setup() {}\n}\n\nclass MLAlbum extends Album {\n  override setup() {}\n}\n\nclass SharedAlbum extends Album {\n  setup() {}\n}\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "When working with classes which use inheritance, it's possible for a sub-class to get \"out of sync\" with the functions it overloads when they are renamed in the base class.\n\nFor example, imagine you are modeling a music album syncing system:\n\n```ts twoslash\nclass Album {\n  download() {\n    // Default behavior\n  }\n}\n\nclass SharedAlbum extends Album {\n  download() {\n    // Override to get info from many sources\n  }\n}\n```\n\nThen when you add support for machine-learning generated playlists, you refactor the `Album` class to have a 'setup' function instead:\n\n```ts twoslash\nclass Album {\n  setup() {\n    // Default behavior\n  }\n}\n\nclass MLAlbum extends Album {\n  setup() {\n    // Override to get info from algorithm\n  }\n}\n\nclass SharedAlbum extends Album {\n  download() {\n    // Override to get info from many sources\n  }\n}\n```\n\nIn this case, TypeScript has provided no warning that `download` on `SharedAlbum` _expected_ to override a function in the base class.\n\nUsing `noImplicitOverride` you can ensure that the sub-classes never go out of sync, by ensuring that functions which override include the keyword `override`.\n\nThe following example has `noImplicitOverride` enabled, and you can see the error received when `override` is missing:\n\n```ts twoslash\n// @noImplicitOverride\n// @errors: 4114\nclass Album {\n  setup() {}\n}\n\nclass MLAlbum extends Album {\n  override setup() {}\n}\n\nclass SharedAlbum extends Album {\n  setup() {}\n}\n```",
              "x-intellij-html-description": "<p>When working with classes which use inheritance, it&#39;s possible for a sub-class to get &quot;out of sync&quot; with the functions it overloads when they are renamed in the base class.</p>\n<p>For example, imagine you are modeling a music album syncing system:</p>\n<pre><code class=\"language-ts\">class Album {\n  download() {\n    // Default behavior\n  }\n}\n\nclass SharedAlbum extends Album {\n  download() {\n    // Override to get info from many sources\n  }\n}\n</code></pre>\n<p>Then when you add support for machine-learning generated playlists, you refactor the <code>Album</code> class to have a &#39;setup&#39; function instead:</p>\n<pre><code class=\"language-ts\">class Album {\n  setup() {\n    // Default behavior\n  }\n}\n\nclass MLAlbum extends Album {\n  setup() {\n    // Override to get info from algorithm\n  }\n}\n\nclass SharedAlbum extends Album {\n  download() {\n    // Override to get info from many sources\n  }\n}\n</code></pre>\n<p>In this case, TypeScript has provided no warning that <code>download</code> on <code>SharedAlbum</code> <em>expected</em> to override a function in the base class.</p>\n<p>Using <code>noImplicitOverride</code> you can ensure that the sub-classes never go out of sync, by ensuring that functions which override include the keyword <code>override</code>.</p>\n<p>The following example has <code>noImplicitOverride</code> enabled, and you can see the error received when <code>override</code> is missing:</p>\n<pre><code class=\"language-ts\">// @noImplicitOverride\n// @errors: 4114\nclass Album {\n  setup() {}\n}\n\nclass MLAlbum extends Album {\n  override setup() {}\n}\n\nclass SharedAlbum extends Album {\n  setup() {}\n}\n</code></pre>\n"
            },
            "allowUnreachableCode": {
              "description": "When:\n\n- `undefined` (default) provide suggestions as warnings to editors\n- `true` unreachable code is ignored\n- `false` raises compiler errors about unreachable code\n\nThese warnings are only about code which is provably unreachable due to the use of JavaScript syntax, for example:\n\n```ts\nfunction fn(n: number) {\n  if (n > 5) {\n    return true;\n  } else {\n    return false;\n  }\n  return true;\n}\n```\n\nWith `\"allowUnreachableCode\": false`:\n\n```ts twoslash\n// @errors: 7027\n// @allowUnreachableCode: false\nfunction fn(n: number) {\n  if (n > 5) {\n    return true;\n  } else {\n    return false;\n  }\n  return true;\n}\n```\n\nThis does not affect errors on the basis of code which _appears_ to be unreachable due to type analysis.",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "When:\n\n- `undefined` (default) provide suggestions as warnings to editors\n- `true` unreachable code is ignored\n- `false` raises compiler errors about unreachable code\n\nThese warnings are only about code which is provably unreachable due to the use of JavaScript syntax, for example:\n\n```ts\nfunction fn(n: number) {\n  if (n > 5) {\n    return true;\n  } else {\n    return false;\n  }\n  return true;\n}\n```\n\nWith `\"allowUnreachableCode\": false`:\n\n```ts twoslash\n// @errors: 7027\n// @allowUnreachableCode: false\nfunction fn(n: number) {\n  if (n > 5) {\n    return true;\n  } else {\n    return false;\n  }\n  return true;\n}\n```\n\nThis does not affect errors on the basis of code which _appears_ to be unreachable due to type analysis.",
              "x-intellij-html-description": "<p>When:</p>\n<ul>\n<li><code>undefined</code> (default) provide suggestions as warnings to editors</li>\n<li><code>true</code> unreachable code is ignored</li>\n<li><code>false</code> raises compiler errors about unreachable code</li>\n</ul>\n<p>These warnings are only about code which is provably unreachable due to the use of JavaScript syntax, for example:</p>\n<pre><code class=\"language-ts\">function fn(n: number) {\n  if (n &gt; 5) {\n    return true;\n  } else {\n    return false;\n  }\n  return true;\n}\n</code></pre>\n<p>With <code>&quot;allowUnreachableCode&quot;: false</code>:</p>\n<pre><code class=\"language-ts\">// @errors: 7027\n// @allowUnreachableCode: false\nfunction fn(n: number) {\n  if (n &gt; 5) {\n    return true;\n  } else {\n    return false;\n  }\n  return true;\n}\n</code></pre>\n<p>This does not affect errors on the basis of code which <em>appears</em> to be unreachable due to type analysis.</p>\n"
            },
            "forceConsistentCasingInFileNames": {
              "description": "TypeScript follows the case sensitivity rules of the file system it's running on.\nThis can be problematic if some developers are working in a case-sensitive file system and others aren't.\nIf a file attempts to import `fileManager.ts` by specifying `./FileManager.ts` the file will be found in a case-insensitive file system, but not on a case-sensitive file system.\n\nWhen this option is set, TypeScript will issue an error if a program tries to include a file by a casing different from the casing on disk.",
              "type": [
                "boolean",
                "null"
              ],
              "default": true,
              "markdownDescription": "TypeScript follows the case sensitivity rules of the file system it's running on.\nThis can be problematic if some developers are working in a case-sensitive file system and others aren't.\nIf a file attempts to import `fileManager.ts` by specifying `./FileManager.ts` the file will be found in a case-insensitive file system, but not on a case-sensitive file system.\n\nWhen this option is set, TypeScript will issue an error if a program tries to include a file by a casing different from the casing on disk.",
              "x-intellij-html-description": "<p>TypeScript follows the case sensitivity rules of the file system it&#39;s running on.\nThis can be problematic if some developers are working in a case-sensitive file system and others aren&#39;t.\nIf a file attempts to import <code>fileManager.ts</code> by specifying <code>./FileManager.ts</code> the file will be found in a case-insensitive file system, but not on a case-sensitive file system.</p>\n<p>When this option is set, TypeScript will issue an error if a program tries to include a file by a casing different from the casing on disk.</p>\n"
            },
            "generateCpuProfile": {
              "description": "This option gives you the chance to have TypeScript emit a v8 CPU profile during the compiler run. The CPU profile can provide insight into why your builds may be slow.\n\nThis option can only be used from the CLI via: `--generateCpuProfile tsc-output.cpuprofile`.\n\n```sh\nnpm run tsc --generateCpuProfile tsc-output.cpuprofile\n```\n\nThis file can be opened in a chromium based browser like Chrome or Edge Developer in [the CPU profiler](https://developers.google.com/web/tools/chrome-devtools/rendering-tools/js-execution) section.\nYou can learn more about understanding the compilers performance in the [TypeScript wiki section on performance](https://github.com/microsoft/TypeScript/wiki/Performance).",
              "type": [
                "string",
                "null"
              ],
              "default": "profile.cpuprofile",
              "markdownDescription": "This option gives you the chance to have TypeScript emit a v8 CPU profile during the compiler run. The CPU profile can provide insight into why your builds may be slow.\n\nThis option can only be used from the CLI via: `--generateCpuProfile tsc-output.cpuprofile`.\n\n```sh\nnpm run tsc --generateCpuProfile tsc-output.cpuprofile\n```\n\nThis file can be opened in a chromium based browser like Chrome or Edge Developer in [the CPU profiler](https://developers.google.com/web/tools/chrome-devtools/rendering-tools/js-execution) section.\nYou can learn more about understanding the compilers performance in the [TypeScript wiki section on performance](https://github.com/microsoft/TypeScript/wiki/Performance).",
              "x-intellij-html-description": "<p>This option gives you the chance to have TypeScript emit a v8 CPU profile during the compiler run. The CPU profile can provide insight into why your builds may be slow.</p>\n<p>This option can only be used from the CLI via: <code>--generateCpuProfile tsc-output.cpuprofile</code>.</p>\n<pre><code class=\"language-sh\">npm run tsc --generateCpuProfile tsc-output.cpuprofile\n</code></pre>\n<p>This file can be opened in a chromium based browser like Chrome or Edge Developer in <a href=\"https://developers.google.com/web/tools/chrome-devtools/rendering-tools/js-execution\">the CPU profiler</a> section.\nYou can learn more about understanding the compilers performance in the <a href=\"https://github.com/microsoft/TypeScript/wiki/Performance\">TypeScript wiki section on performance</a>.</p>\n"
            },
            "baseUrl": {
              "description": "Sets a base directory from which to resolve bare specifier module names. For example, in the directory structure:\n\n```\nproject\n├── ex.ts\n├── hello\n│   └── world.ts\n└── tsconfig.json\n```\n\nWith `\"baseUrl\": \"./\"`, TypeScript will look for files starting at the same folder as the `tsconfig.json`:\n\n```ts\nimport { helloWorld } from \"hello/world\";\n\nconsole.log(helloWorld);\n```\n\nThis resolution has higher priority than lookups from `node_modules`.\n\nThis feature was designed for use in conjunction with AMD module loaders in the browser, and is not recommended in any other context. As of TypeScript 4.1, `baseUrl` is no longer required to be set when using [`paths`](https://typescriptlang.org/tsconfig/#paths).",
              "type": [
                "string",
                "null"
              ],
              "markdownDescription": "Sets a base directory from which to resolve bare specifier module names. For example, in the directory structure:\n\n```\nproject\n├── ex.ts\n├── hello\n│   └── world.ts\n└── tsconfig.json\n```\n\nWith `\"baseUrl\": \"./\"`, TypeScript will look for files starting at the same folder as the `tsconfig.json`:\n\n```ts\nimport { helloWorld } from \"hello/world\";\n\nconsole.log(helloWorld);\n```\n\nThis resolution has higher priority than lookups from `node_modules`.\n\nThis feature was designed for use in conjunction with AMD module loaders in the browser, and is not recommended in any other context. As of TypeScript 4.1, `baseUrl` is no longer required to be set when using [`paths`](https://typescriptlang.org/tsconfig/#paths).",
              "x-intellij-html-description": "<p>Sets a base directory from which to resolve bare specifier module names. For example, in the directory structure:</p>\n<pre><code>project\n├── ex.ts\n├── hello\n│   └── world.ts\n└── tsconfig.json\n</code></pre>\n<p>With <code>&quot;baseUrl&quot;: &quot;./&quot;</code>, TypeScript will look for files starting at the same folder as the <code>tsconfig.json</code>:</p>\n<pre><code class=\"language-ts\">import { helloWorld } from &quot;hello/world&quot;;\n\nconsole.log(helloWorld);\n</code></pre>\n<p>This resolution has higher priority than lookups from <code>node_modules</code>.</p>\n<p>This feature was designed for use in conjunction with AMD module loaders in the browser, and is not recommended in any other context. As of TypeScript 4.1, <code>baseUrl</code> is no longer required to be set when using <a href=\"https://typescriptlang.org/tsconfig/#paths\"><code>paths</code></a>.</p>\n"
            },
            "paths": {
              "description": "A series of entries which re-map imports to lookup locations relative to the [`baseUrl`](https://typescriptlang.org/tsconfig/#baseUrl) if set, or to the tsconfig file itself otherwise. There is a larger coverage of `paths` in [the `moduleResolution` reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#paths).\n\n`paths` lets you declare how TypeScript should resolve an import in your `require`/`import`s.\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"paths\": {\n      \"jquery\": [\"./vendor/jquery/dist/jquery\"]\n    }\n  }\n}\n```\n\nThis would allow you to be able to write `import \"jquery\"`, and get all of the correct typing locally.\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"paths\": {\n        \"app/*\": [\"./src/app/*\"],\n        \"config/*\": [\"./src/app/_config/*\"],\n        \"environment/*\": [\"./src/environments/*\"],\n        \"shared/*\": [\"./src/app/_shared/*\"],\n        \"helpers/*\": [\"./src/helpers/*\"],\n        \"tests/*\": [\"./src/tests/*\"]\n    }\n  }\n}\n```\n\nIn this case, you can tell the TypeScript file resolver to support a number of custom prefixes to find code.\n\nNote that this feature does not change how import paths are emitted by `tsc`, so `paths` should only be used to inform TypeScript that another tool has this mapping and will use it at runtime or when bundling.",
              "type": [
                "object",
                "null"
              ],
              "additionalProperties": {
                "type": [
                  "array",
                  "null"
                ],
                "uniqueItems": true,
                "items": {
                  "type": "string",
                  "description": "An array of paths to use as alternatives when resolving this module import."
                }
              },
              "markdownDescription": "A series of entries which re-map imports to lookup locations relative to the [`baseUrl`](https://typescriptlang.org/tsconfig/#baseUrl) if set, or to the tsconfig file itself otherwise. There is a larger coverage of `paths` in [the `moduleResolution` reference page](https://typescriptlang.org/docs/handbook/modules/reference.html#paths).\n\n`paths` lets you declare how TypeScript should resolve an import in your `require`/`import`s.\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"paths\": {\n      \"jquery\": [\"./vendor/jquery/dist/jquery\"]\n    }\n  }\n}\n```\n\nThis would allow you to be able to write `import \"jquery\"`, and get all of the correct typing locally.\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"paths\": {\n        \"app/*\": [\"./src/app/*\"],\n        \"config/*\": [\"./src/app/_config/*\"],\n        \"environment/*\": [\"./src/environments/*\"],\n        \"shared/*\": [\"./src/app/_shared/*\"],\n        \"helpers/*\": [\"./src/helpers/*\"],\n        \"tests/*\": [\"./src/tests/*\"]\n    }\n  }\n}\n```\n\nIn this case, you can tell the TypeScript file resolver to support a number of custom prefixes to find code.\n\nNote that this feature does not change how import paths are emitted by `tsc`, so `paths` should only be used to inform TypeScript that another tool has this mapping and will use it at runtime or when bundling.",
              "x-intellij-html-description": "<p>A series of entries which re-map imports to lookup locations relative to the <a href=\"https://typescriptlang.org/tsconfig/#baseUrl\"><code>baseUrl</code></a> if set, or to the tsconfig file itself otherwise. There is a larger coverage of <code>paths</code> in <a href=\"https://typescriptlang.org/docs/handbook/modules/reference.html#paths\">the <code>moduleResolution</code> reference page</a>.</p>\n<p><code>paths</code> lets you declare how TypeScript should resolve an import in your <code>require</code>/<code>import</code>s.</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;paths&quot;: {\n      &quot;jquery&quot;: [&quot;./vendor/jquery/dist/jquery&quot;]\n    }\n  }\n}\n</code></pre>\n<p>This would allow you to be able to write <code>import &quot;jquery&quot;</code>, and get all of the correct typing locally.</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;paths&quot;: {\n        &quot;app/*&quot;: [&quot;./src/app/*&quot;],\n        &quot;config/*&quot;: [&quot;./src/app/_config/*&quot;],\n        &quot;environment/*&quot;: [&quot;./src/environments/*&quot;],\n        &quot;shared/*&quot;: [&quot;./src/app/_shared/*&quot;],\n        &quot;helpers/*&quot;: [&quot;./src/helpers/*&quot;],\n        &quot;tests/*&quot;: [&quot;./src/tests/*&quot;]\n    }\n  }\n}\n</code></pre>\n<p>In this case, you can tell the TypeScript file resolver to support a number of custom prefixes to find code.</p>\n<p>Note that this feature does not change how import paths are emitted by <code>tsc</code>, so <code>paths</code> should only be used to inform TypeScript that another tool has this mapping and will use it at runtime or when bundling.</p>\n"
            },
            "plugins": {
              "description": "List of language service plugins to run inside the editor.\n\nLanguage service plugins are a way to provide additional information to a user based on existing TypeScript files. They can enhance existing messages between TypeScript and an editor, or to provide their own error messages.\n\nFor example:\n\n- [ts-sql-plugin](https://github.com/xialvjun/ts-sql-plugin#readme) &mdash; Adds SQL linting with a template strings SQL builder.\n- [typescript-styled-plugin](https://github.com/Microsoft/typescript-styled-plugin) &mdash; Provides CSS linting inside template strings .\n- [typescript-eslint-language-service](https://github.com/Quramy/typescript-eslint-language-service) &mdash; Provides eslint error messaging and fix-its inside the compiler's output.\n- [ts-graphql-plugin](https://github.com/Quramy/ts-graphql-plugin) &mdash; Provides validation and auto-completion inside GraphQL query template strings.\n\nVS Code has the ability for a extension to [automatically include language service plugins](https://code.visualstudio.com/api/references/contribution-points#contributes.typescriptServerPlugins), and so you may have some running in your editor without needing to define them in your `tsconfig.json`.",
              "type": [
                "array",
                "null"
              ],
              "items": {
                "anyOf": [
                  {
                    "type": "object",
                    "required": [
                      "name"
                    ],
                    "properties": {
                      "name": {
                        "type": "string",
                        "enum": [
                          "@effect/language-service"
                        ],
                        "description": "Plugin name."
                      },
                      "refactors": {
                        "type": "boolean",
                        "description": "Controls Effect refactors.",
                        "default": true
                      },
                      "diagnostics": {
                        "type": "boolean",
                        "description": "Controls Effect diagnostics.",
                        "default": true
                      },
                      "diagnosticsName": {
                        "type": "boolean",
                        "description": "Controls whether to include the rule name in diagnostic messages.",
                        "default": true
                      },
                      "missingDiagnosticNextLine": {
                        "type": "string",
                        "description": "Controls the severity of warnings for unused @effect-diagnostics-next-line comments.",
                        "enum": [
                          "off",
                          "error",
                          "warning",
                          "message",
                          "suggestion"
                        ],
                        "default": "warning"
                      },
                      "includeSuggestionsInTsc": {
                        "type": "boolean",
                        "description": "When patch mode is enabled, reports suggestion diagnostics as messages in TSC with a [suggestion] prefix.",
                        "default": true
                      },
                      "ignoreEffectWarningsInTscExitCode": {
                        "type": "boolean",
                        "description": "When enabled, Effect warnings do not affect the patched tsc exit code.",
                        "default": false
                      },
                      "ignoreEffectErrorsInTscExitCode": {
                        "type": "boolean",
                        "description": "When enabled, Effect errors do not affect the patched tsc exit code.",
                        "default": false
                      },
                      "ignoreEffectSuggestionsInTscExitCode": {
                        "type": "boolean",
                        "description": "When enabled, Effect suggestions do not affect the patched tsc exit code.",
                        "default": true
                      },
                      "quickinfoEffectParameters": {
                        "type": "string",
                        "description": "Controls when Effect quickinfo should include full type parameters.",
                        "enum": [
                          "always",
                          "never",
                          "whentruncated"
                        ],
                        "default": "whentruncated"
                      },
                      "quickinfo": {
                        "type": "boolean",
                        "description": "Controls Effect quickinfo.",
                        "default": true
                      },
                      "quickinfoMaximumLength": {
                        "type": "number",
                        "description": "Controls the maximum quickinfo length. Use -1 to disable truncation.",
                        "default": -1
                      },
                      "keyPatterns": {
                        "type": "array",
                        "description": "Configures key patterns used for generated Effect service and error keys.",
                        "default": [
                          {
                            "target": "service",
                            "pattern": "default",
                            "skipLeadingPath": [
                              "src/"
                            ]
                          },
                          {
                            "target": "custom",
                            "pattern": "default",
                            "skipLeadingPath": [
                              "src/"
                            ]
                          }
                        ],
                        "items": {
                          "type": "object",
                          "properties": {
                            "target": {
                              "type": "string",
                              "description": "The key builder target.",
                              "enum": [
                                "service",
                                "error",
                                "custom"
                              ],
                              "default": "service"
                            },
                            "pattern": {
                              "type": "string",
                              "description": "The key generation pattern.",
                              "enum": [
                                "package-identifier",
                                "default",
                                "default-hashed"
                              ],
                              "default": "default"
                            },
                            "skipLeadingPath": {
                              "type": "array",
                              "description": "Path prefixes to strip before generating keys.",
                              "default": [
                                "src/"
                              ],
                              "items": {
                                "type": "string"
                              }
                            }
                          }
                        }
                      },
                      "extendedKeyDetection": {
                        "type": "boolean",
                        "description": "Enables extended heuristics when detecting key sources.",
                        "default": false
                      },
                      "completions": {
                        "type": "boolean",
                        "description": "Controls Effect completions.",
                        "default": true
                      },
                      "goto": {
                        "type": "boolean",
                        "description": "Controls Effect goto references support.",
                        "default": true
                      },
                      "inlays": {
                        "type": "boolean",
                        "description": "Controls Effect inlay hints.",
                        "default": true
                      },
                      "allowedDuplicatedPackages": {
                        "type": "array",
                        "description": "Package names that are allowed to duplicate Effect as a peer dependency.",
                        "default": [],
                        "items": {
                          "type": "string"
                        }
                      },
                      "namespaceImportPackages": {
                        "type": "array",
                        "description": "Package names that should prefer namespace imports.",
                        "default": [],
                        "items": {
                          "type": "string"
                        }
                      },
                      "topLevelNamedReexports": {
                        "type": "string",
                        "description": "For namespaceImportPackages, controls how top-level named re-exports are handled.",
                        "enum": [
                          "ignore",
                          "follow"
                        ],
                        "default": "ignore"
                      },
                      "barrelImportPackages": {
                        "type": "array",
                        "description": "Package names that should prefer imports from their top-level barrel file.",
                        "default": [],
                        "items": {
                          "type": "string"
                        }
                      },
                      "importAliases": {
                        "type": "object",
                        "description": "Custom aliases to use for imported identifiers.",
                        "default": {},
                        "additionalProperties": {
                          "type": "string"
                        }
                      },
                      "renames": {
                        "type": "boolean",
                        "description": "Controls Effect rename helpers.",
                        "default": true
                      },
                      "noExternal": {
                        "type": "boolean",
                        "description": "Disables features that link to external websites.",
                        "default": false
                      },
                      "pipeableMinArgCount": {
                        "type": "number",
                        "description": "Minimum argument count required before pipeable suggestions are emitted.",
                        "default": 2
                      },
                      "effectFn": {
                        "type": "array",
                        "description": "Configures which Effect.fn variants should be suggested.",
                        "default": [
                          "span"
                        ],
                        "items": {
                          "type": "string",
                          "enum": [
                            "untraced",
                            "span",
                            "suggested-span",
                            "inferred-span",
                            "no-span"
                          ]
                        }
                      },
                      "layerGraphFollowDepth": {
                        "type": "number",
                        "description": "Controls how deeply layer graph analysis follows dependencies.",
                        "default": 0
                      },
                      "mermaidProvider": {
                        "type": "string",
                        "description": "Controls which Mermaid renderer is used for layer graphs.",
                        "default": "mermaid.live"
                      },
                      "skipDisabledOptimization": {
                        "type": "boolean",
                        "description": "When enabled, disabled diagnostics are still processed so comment-based overrides can be honored.",
                        "default": false
                      },
                      "excludeExternalLibrariesWhenSkipLibCheck": {
                        "type": "boolean",
                        "description": "When enabled with skipLibCheck, external library files are skipped by patched tsc diagnostics.",
                        "default": true
                      },
                      "diagnosticSeverity": {
                        "$ref": "#/definitions/effectLanguageServicePluginDiagnosticSeverityDefinition"
                      }
                    },
                    "additionalProperties": true
                  },
                  {
                    "type": "object",
                    "properties": {
                      "name": {
                        "description": "Plugin name.",
                        "type": "string",
                        "not": {
                          "enum": [
                            "@effect/language-service"
                          ]
                        }
                      }
                    }
                  }
                ]
              },
              "markdownDescription": "List of language service plugins to run inside the editor.\n\nLanguage service plugins are a way to provide additional information to a user based on existing TypeScript files. They can enhance existing messages between TypeScript and an editor, or to provide their own error messages.\n\nFor example:\n\n- [ts-sql-plugin](https://github.com/xialvjun/ts-sql-plugin#readme) &mdash; Adds SQL linting with a template strings SQL builder.\n- [typescript-styled-plugin](https://github.com/Microsoft/typescript-styled-plugin) &mdash; Provides CSS linting inside template strings .\n- [typescript-eslint-language-service](https://github.com/Quramy/typescript-eslint-language-service) &mdash; Provides eslint error messaging and fix-its inside the compiler's output.\n- [ts-graphql-plugin](https://github.com/Quramy/ts-graphql-plugin) &mdash; Provides validation and auto-completion inside GraphQL query template strings.\n\nVS Code has the ability for a extension to [automatically include language service plugins](https://code.visualstudio.com/api/references/contribution-points#contributes.typescriptServerPlugins), and so you may have some running in your editor without needing to define them in your `tsconfig.json`.",
              "x-intellij-html-description": "<p>List of language service plugins to run inside the editor.</p>\n<p>Language service plugins are a way to provide additional information to a user based on existing TypeScript files. They can enhance existing messages between TypeScript and an editor, or to provide their own error messages.</p>\n<p>For example:</p>\n<ul>\n<li><a href=\"https://github.com/xialvjun/ts-sql-plugin#readme\">ts-sql-plugin</a> &mdash; Adds SQL linting with a template strings SQL builder.</li>\n<li><a href=\"https://github.com/Microsoft/typescript-styled-plugin\">typescript-styled-plugin</a> &mdash; Provides CSS linting inside template strings .</li>\n<li><a href=\"https://github.com/Quramy/typescript-eslint-language-service\">typescript-eslint-language-service</a> &mdash; Provides eslint error messaging and fix-its inside the compiler&#39;s output.</li>\n<li><a href=\"https://github.com/Quramy/ts-graphql-plugin\">ts-graphql-plugin</a> &mdash; Provides validation and auto-completion inside GraphQL query template strings.</li>\n</ul>\n<p>VS Code has the ability for a extension to <a href=\"https://code.visualstudio.com/api/references/contribution-points#contributes.typescriptServerPlugins\">automatically include language service plugins</a>, and so you may have some running in your editor without needing to define them in your <code>tsconfig.json</code>.</p>\n"
            },
            "rootDirs": {
              "description": "Using `rootDirs`, you can inform the compiler that there are many \"virtual\" directories acting as a single root.\nThis allows the compiler to resolve relative module imports within these \"virtual\" directories, as if they were merged in to one directory.\n\nFor example:\n\n```\n src\n └── views\n     └── view1.ts (can import \"./template1\", \"./view2`)\n     └── view2.ts (can import \"./template1\", \"./view1`)\n\n generated\n └── templates\n         └── views\n             └── template1.ts (can import \"./view1\", \"./view2\")\n```\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"rootDirs\": [\"src/views\", \"generated/templates/views\"]\n  }\n}\n```\n\nThis does not affect how TypeScript emits JavaScript, it only emulates the assumption that they will be able to\nwork via those relative paths at runtime.\n\n`rootDirs` can be used to provide a separate \"type layer\" to files that are not TypeScript or JavaScript by providing a home for generated `.d.ts` files in another folder. This technique is useful for bundled applications where you use `import` of files that aren't necessarily code:\n\n```sh\n src\n └── index.ts\n └── css\n     └── main.css\n     └── navigation.css\n\n generated\n └── css\n     └── main.css.d.ts\n     └── navigation.css.d.ts\n```\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"rootDirs\": [\"src\", \"generated\"]\n  }\n}\n```\n\nThis technique lets you generate types ahead of time for the non-code source files. Imports then work naturally based off the source file's location.\nFor example `./src/index.ts` can import the file `./src/css/main.css` and TypeScript will be aware of the bundler's behavior for that filetype via the corresponding generated declaration file.\n\n```ts twoslash\n// @filename: main.css.d.ts\nexport const appClass = \"mainClassF3EC2\";\n// ---cut---\n// @filename: index.ts\nimport { appClass } from \"./main.css\";\n```",
              "type": [
                "array",
                "null"
              ],
              "uniqueItems": true,
              "items": {
                "type": "string"
              },
              "markdownDescription": "Using `rootDirs`, you can inform the compiler that there are many \"virtual\" directories acting as a single root.\nThis allows the compiler to resolve relative module imports within these \"virtual\" directories, as if they were merged in to one directory.\n\nFor example:\n\n```\n src\n └── views\n     └── view1.ts (can import \"./template1\", \"./view2`)\n     └── view2.ts (can import \"./template1\", \"./view1`)\n\n generated\n └── templates\n         └── views\n             └── template1.ts (can import \"./view1\", \"./view2\")\n```\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"rootDirs\": [\"src/views\", \"generated/templates/views\"]\n  }\n}\n```\n\nThis does not affect how TypeScript emits JavaScript, it only emulates the assumption that they will be able to\nwork via those relative paths at runtime.\n\n`rootDirs` can be used to provide a separate \"type layer\" to files that are not TypeScript or JavaScript by providing a home for generated `.d.ts` files in another folder. This technique is useful for bundled applications where you use `import` of files that aren't necessarily code:\n\n```sh\n src\n └── index.ts\n └── css\n     └── main.css\n     └── navigation.css\n\n generated\n └── css\n     └── main.css.d.ts\n     └── navigation.css.d.ts\n```\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"rootDirs\": [\"src\", \"generated\"]\n  }\n}\n```\n\nThis technique lets you generate types ahead of time for the non-code source files. Imports then work naturally based off the source file's location.\nFor example `./src/index.ts` can import the file `./src/css/main.css` and TypeScript will be aware of the bundler's behavior for that filetype via the corresponding generated declaration file.\n\n```ts twoslash\n// @filename: main.css.d.ts\nexport const appClass = \"mainClassF3EC2\";\n// ---cut---\n// @filename: index.ts\nimport { appClass } from \"./main.css\";\n```",
              "x-intellij-html-description": "<p>Using <code>rootDirs</code>, you can inform the compiler that there are many &quot;virtual&quot; directories acting as a single root.\nThis allows the compiler to resolve relative module imports within these &quot;virtual&quot; directories, as if they were merged in to one directory.</p>\n<p>For example:</p>\n<pre><code> src\n └── views\n     └── view1.ts (can import &quot;./template1&quot;, &quot;./view2`)\n     └── view2.ts (can import &quot;./template1&quot;, &quot;./view1`)\n\n generated\n └── templates\n         └── views\n             └── template1.ts (can import &quot;./view1&quot;, &quot;./view2&quot;)\n</code></pre>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;rootDirs&quot;: [&quot;src/views&quot;, &quot;generated/templates/views&quot;]\n  }\n}\n</code></pre>\n<p>This does not affect how TypeScript emits JavaScript, it only emulates the assumption that they will be able to\nwork via those relative paths at runtime.</p>\n<p><code>rootDirs</code> can be used to provide a separate &quot;type layer&quot; to files that are not TypeScript or JavaScript by providing a home for generated <code>.d.ts</code> files in another folder. This technique is useful for bundled applications where you use <code>import</code> of files that aren&#39;t necessarily code:</p>\n<pre><code class=\"language-sh\"> src\n └── index.ts\n └── css\n     └── main.css\n     └── navigation.css\n\n generated\n └── css\n     └── main.css.d.ts\n     └── navigation.css.d.ts\n</code></pre>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;rootDirs&quot;: [&quot;src&quot;, &quot;generated&quot;]\n  }\n}\n</code></pre>\n<p>This technique lets you generate types ahead of time for the non-code source files. Imports then work naturally based off the source file&#39;s location.\nFor example <code>./src/index.ts</code> can import the file <code>./src/css/main.css</code> and TypeScript will be aware of the bundler&#39;s behavior for that filetype via the corresponding generated declaration file.</p>\n<pre><code class=\"language-ts\">// @filename: main.css.d.ts\nexport const appClass = &quot;mainClassF3EC2&quot;;\n// ---cut---\n// @filename: index.ts\nimport { appClass } from &quot;./main.css&quot;;\n</code></pre>\n"
            },
            "typeRoots": {
              "description": "By default all _visible_ \"`@types`\" packages are included in your compilation.\nPackages in `node_modules/@types` of any enclosing folder are considered _visible_.\nFor example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.\n\nIf `typeRoots` is specified, _only_ packages under `typeRoots` will be included. For example:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"typeRoots\": [\"./typings\", \"./vendor/types\"]\n  }\n}\n```\n\nThis config file will include _all_ packages under `./typings` and `./vendor/types`, and no packages from `./node_modules/@types`.\nAll paths are relative to the `tsconfig.json`.",
              "type": [
                "array",
                "null"
              ],
              "uniqueItems": true,
              "items": {
                "type": "string"
              },
              "markdownDescription": "By default all _visible_ \"`@types`\" packages are included in your compilation.\nPackages in `node_modules/@types` of any enclosing folder are considered _visible_.\nFor example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.\n\nIf `typeRoots` is specified, _only_ packages under `typeRoots` will be included. For example:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"typeRoots\": [\"./typings\", \"./vendor/types\"]\n  }\n}\n```\n\nThis config file will include _all_ packages under `./typings` and `./vendor/types`, and no packages from `./node_modules/@types`.\nAll paths are relative to the `tsconfig.json`.",
              "x-intellij-html-description": "<p>By default all <em>visible</em> &quot;<code>@types</code>&quot; packages are included in your compilation.\nPackages in <code>node_modules/@types</code> of any enclosing folder are considered <em>visible</em>.\nFor example, that means packages within <code>./node_modules/@types/</code>, <code>../node_modules/@types/</code>, <code>../../node_modules/@types/</code>, and so on.</p>\n<p>If <code>typeRoots</code> is specified, <em>only</em> packages under <code>typeRoots</code> will be included. For example:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;typeRoots&quot;: [&quot;./typings&quot;, &quot;./vendor/types&quot;]\n  }\n}\n</code></pre>\n<p>This config file will include <em>all</em> packages under <code>./typings</code> and <code>./vendor/types</code>, and no packages from <code>./node_modules/@types</code>.\nAll paths are relative to the <code>tsconfig.json</code>.</p>\n"
            },
            "types": {
              "description": "By default all _visible_ \"`@types`\" packages are included in your compilation.\nPackages in `node_modules/@types` of any enclosing folder are considered _visible_.\nFor example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.\n\nIf `types` is specified, only packages listed will be included in the global scope. For instance:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"types\": [\"node\", \"jest\", \"express\"]\n  }\n}\n```\n\nThis `tsconfig.json` file will _only_ include `./node_modules/@types/node`, `./node_modules/@types/jest` and `./node_modules/@types/express`.\nOther packages under `node_modules/@types/*` will not be included.\n\n### What does this affect?\n\nThis option does not affect how `@types/*` are included in your application code, for example if you had the above `compilerOptions` example with code like:\n\n```ts\nimport * as moment from \"moment\";\n\nmoment().format(\"MMMM Do YYYY, h:mm:ss a\");\n```\n\nThe `moment` import would be fully typed.\n\nWhen you have this option set, by not including a module in the `types` array it:\n\n- Will not add globals to your project (e.g `process` in node, or `expect` in Jest)\n- Will not have exports appear as auto-import recommendations\n\nThis feature differs from [`typeRoots`](https://typescriptlang.org/tsconfig/#typeRoots) in that it is about specifying only the exact types you want included, whereas [`typeRoots`](https://typescriptlang.org/tsconfig/#typeRoots) supports saying you want particular folders.",
              "type": [
                "array",
                "null"
              ],
              "uniqueItems": true,
              "items": {
                "type": "string"
              },
              "markdownDescription": "By default all _visible_ \"`@types`\" packages are included in your compilation.\nPackages in `node_modules/@types` of any enclosing folder are considered _visible_.\nFor example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.\n\nIf `types` is specified, only packages listed will be included in the global scope. For instance:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"types\": [\"node\", \"jest\", \"express\"]\n  }\n}\n```\n\nThis `tsconfig.json` file will _only_ include `./node_modules/@types/node`, `./node_modules/@types/jest` and `./node_modules/@types/express`.\nOther packages under `node_modules/@types/*` will not be included.\n\n### What does this affect?\n\nThis option does not affect how `@types/*` are included in your application code, for example if you had the above `compilerOptions` example with code like:\n\n```ts\nimport * as moment from \"moment\";\n\nmoment().format(\"MMMM Do YYYY, h:mm:ss a\");\n```\n\nThe `moment` import would be fully typed.\n\nWhen you have this option set, by not including a module in the `types` array it:\n\n- Will not add globals to your project (e.g `process` in node, or `expect` in Jest)\n- Will not have exports appear as auto-import recommendations\n\nThis feature differs from [`typeRoots`](https://typescriptlang.org/tsconfig/#typeRoots) in that it is about specifying only the exact types you want included, whereas [`typeRoots`](https://typescriptlang.org/tsconfig/#typeRoots) supports saying you want particular folders.",
              "x-intellij-html-description": "<p>By default all <em>visible</em> &quot;<code>@types</code>&quot; packages are included in your compilation.\nPackages in <code>node_modules/@types</code> of any enclosing folder are considered <em>visible</em>.\nFor example, that means packages within <code>./node_modules/@types/</code>, <code>../node_modules/@types/</code>, <code>../../node_modules/@types/</code>, and so on.</p>\n<p>If <code>types</code> is specified, only packages listed will be included in the global scope. For instance:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;types&quot;: [&quot;node&quot;, &quot;jest&quot;, &quot;express&quot;]\n  }\n}\n</code></pre>\n<p>This <code>tsconfig.json</code> file will <em>only</em> include <code>./node_modules/@types/node</code>, <code>./node_modules/@types/jest</code> and <code>./node_modules/@types/express</code>.\nOther packages under <code>node_modules/@types/*</code> will not be included.</p>\n<h3>What does this affect?</h3>\n<p>This option does not affect how <code>@types/*</code> are included in your application code, for example if you had the above <code>compilerOptions</code> example with code like:</p>\n<pre><code class=\"language-ts\">import * as moment from &quot;moment&quot;;\n\nmoment().format(&quot;MMMM Do YYYY, h:mm:ss a&quot;);\n</code></pre>\n<p>The <code>moment</code> import would be fully typed.</p>\n<p>When you have this option set, by not including a module in the <code>types</code> array it:</p>\n<ul>\n<li>Will not add globals to your project (e.g <code>process</code> in node, or <code>expect</code> in Jest)</li>\n<li>Will not have exports appear as auto-import recommendations</li>\n</ul>\n<p>This feature differs from <a href=\"https://typescriptlang.org/tsconfig/#typeRoots\"><code>typeRoots</code></a> in that it is about specifying only the exact types you want included, whereas <a href=\"https://typescriptlang.org/tsconfig/#typeRoots\"><code>typeRoots</code></a> supports saying you want particular folders.</p>\n"
            },
            "traceResolution": {
              "description": "Enable tracing of the name resolution process. Requires TypeScript version 2.0 or later.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false
            },
            "allowJs": {
              "description": "Allow JavaScript files to be imported inside your project, instead of just `.ts` and `.tsx` files. For example, this JS file:\n\n```js twoslash\n// @filename: card.js\nexport const defaultCardDeck = \"Heart\";\n```\n\nWhen imported into a TypeScript file will raise an error:\n\n```ts twoslash\n// @errors: 2307\n// @filename: card.js\nmodule.exports.defaultCardDeck = \"Heart\";\n// ---cut---\n// @filename: index.ts\nimport { defaultCardDeck } from \"./card\";\n\nconsole.log(defaultCardDeck);\n```\n\nImports fine with `allowJs` enabled:\n\n```ts twoslash\n// @filename: card.js\nmodule.exports.defaultCardDeck = \"Heart\";\n// ---cut---\n// @allowJs\n// @filename: index.ts\nimport { defaultCardDeck } from \"./card\";\n\nconsole.log(defaultCardDeck);\n```\n\nThis flag can be used as a way to incrementally add TypeScript files into JS projects by allowing the `.ts` and `.tsx` files to live along-side existing JavaScript files.\n\nIt can also be used along-side [`declaration`](https://typescriptlang.org/tsconfig/#declaration) and [`emitDeclarationOnly`](https://typescriptlang.org/tsconfig/#emitDeclarationOnly) to [create declarations for JS files](https://typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html).",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Allow JavaScript files to be imported inside your project, instead of just `.ts` and `.tsx` files. For example, this JS file:\n\n```js twoslash\n// @filename: card.js\nexport const defaultCardDeck = \"Heart\";\n```\n\nWhen imported into a TypeScript file will raise an error:\n\n```ts twoslash\n// @errors: 2307\n// @filename: card.js\nmodule.exports.defaultCardDeck = \"Heart\";\n// ---cut---\n// @filename: index.ts\nimport { defaultCardDeck } from \"./card\";\n\nconsole.log(defaultCardDeck);\n```\n\nImports fine with `allowJs` enabled:\n\n```ts twoslash\n// @filename: card.js\nmodule.exports.defaultCardDeck = \"Heart\";\n// ---cut---\n// @allowJs\n// @filename: index.ts\nimport { defaultCardDeck } from \"./card\";\n\nconsole.log(defaultCardDeck);\n```\n\nThis flag can be used as a way to incrementally add TypeScript files into JS projects by allowing the `.ts` and `.tsx` files to live along-side existing JavaScript files.\n\nIt can also be used along-side [`declaration`](https://typescriptlang.org/tsconfig/#declaration) and [`emitDeclarationOnly`](https://typescriptlang.org/tsconfig/#emitDeclarationOnly) to [create declarations for JS files](https://typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html).",
              "x-intellij-html-description": "<p>Allow JavaScript files to be imported inside your project, instead of just <code>.ts</code> and <code>.tsx</code> files. For example, this JS file:</p>\n<pre><code class=\"language-js\">// @filename: card.js\nexport const defaultCardDeck = &quot;Heart&quot;;\n</code></pre>\n<p>When imported into a TypeScript file will raise an error:</p>\n<pre><code class=\"language-ts\">// @errors: 2307\n// @filename: card.js\nmodule.exports.defaultCardDeck = &quot;Heart&quot;;\n// ---cut---\n// @filename: index.ts\nimport { defaultCardDeck } from &quot;./card&quot;;\n\nconsole.log(defaultCardDeck);\n</code></pre>\n<p>Imports fine with <code>allowJs</code> enabled:</p>\n<pre><code class=\"language-ts\">// @filename: card.js\nmodule.exports.defaultCardDeck = &quot;Heart&quot;;\n// ---cut---\n// @allowJs\n// @filename: index.ts\nimport { defaultCardDeck } from &quot;./card&quot;;\n\nconsole.log(defaultCardDeck);\n</code></pre>\n<p>This flag can be used as a way to incrementally add TypeScript files into JS projects by allowing the <code>.ts</code> and <code>.tsx</code> files to live along-side existing JavaScript files.</p>\n<p>It can also be used along-side <a href=\"https://typescriptlang.org/tsconfig/#declaration\"><code>declaration</code></a> and <a href=\"https://typescriptlang.org/tsconfig/#emitDeclarationOnly\"><code>emitDeclarationOnly</code></a> to <a href=\"https://typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html\">create declarations for JS files</a>.</p>\n"
            },
            "noErrorTruncation": {
              "description": "Do not truncate error messages.\n\nWith `false`, the default.\n\n```ts twoslash\n// @errors: 2322 2454\nvar x: {\n  propertyWithAnExceedinglyLongName1: string;\n  propertyWithAnExceedinglyLongName2: string;\n  propertyWithAnExceedinglyLongName3: string;\n  propertyWithAnExceedinglyLongName4: string;\n  propertyWithAnExceedinglyLongName5: string;\n  propertyWithAnExceedinglyLongName6: string;\n  propertyWithAnExceedinglyLongName7: string;\n  propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of 'x' should be truncated in error message\nvar s: string = x;\n```\n\nWith `true`\n\n```ts twoslash\n// @errors: 2322 2454\n// @noErrorTruncation: true\nvar x: {\n  propertyWithAnExceedinglyLongName1: string;\n  propertyWithAnExceedinglyLongName2: string;\n  propertyWithAnExceedinglyLongName3: string;\n  propertyWithAnExceedinglyLongName4: string;\n  propertyWithAnExceedinglyLongName5: string;\n  propertyWithAnExceedinglyLongName6: string;\n  propertyWithAnExceedinglyLongName7: string;\n  propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of 'x' should be truncated in error message\nvar s: string = x;\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Do not truncate error messages.\n\nWith `false`, the default.\n\n```ts twoslash\n// @errors: 2322 2454\nvar x: {\n  propertyWithAnExceedinglyLongName1: string;\n  propertyWithAnExceedinglyLongName2: string;\n  propertyWithAnExceedinglyLongName3: string;\n  propertyWithAnExceedinglyLongName4: string;\n  propertyWithAnExceedinglyLongName5: string;\n  propertyWithAnExceedinglyLongName6: string;\n  propertyWithAnExceedinglyLongName7: string;\n  propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of 'x' should be truncated in error message\nvar s: string = x;\n```\n\nWith `true`\n\n```ts twoslash\n// @errors: 2322 2454\n// @noErrorTruncation: true\nvar x: {\n  propertyWithAnExceedinglyLongName1: string;\n  propertyWithAnExceedinglyLongName2: string;\n  propertyWithAnExceedinglyLongName3: string;\n  propertyWithAnExceedinglyLongName4: string;\n  propertyWithAnExceedinglyLongName5: string;\n  propertyWithAnExceedinglyLongName6: string;\n  propertyWithAnExceedinglyLongName7: string;\n  propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of 'x' should be truncated in error message\nvar s: string = x;\n```",
              "x-intellij-html-description": "<p>Do not truncate error messages.</p>\n<p>With <code>false</code>, the default.</p>\n<pre><code class=\"language-ts\">// @errors: 2322 2454\nvar x: {\n  propertyWithAnExceedinglyLongName1: string;\n  propertyWithAnExceedinglyLongName2: string;\n  propertyWithAnExceedinglyLongName3: string;\n  propertyWithAnExceedinglyLongName4: string;\n  propertyWithAnExceedinglyLongName5: string;\n  propertyWithAnExceedinglyLongName6: string;\n  propertyWithAnExceedinglyLongName7: string;\n  propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of &#39;x&#39; should be truncated in error message\nvar s: string = x;\n</code></pre>\n<p>With <code>true</code></p>\n<pre><code class=\"language-ts\">// @errors: 2322 2454\n// @noErrorTruncation: true\nvar x: {\n  propertyWithAnExceedinglyLongName1: string;\n  propertyWithAnExceedinglyLongName2: string;\n  propertyWithAnExceedinglyLongName3: string;\n  propertyWithAnExceedinglyLongName4: string;\n  propertyWithAnExceedinglyLongName5: string;\n  propertyWithAnExceedinglyLongName6: string;\n  propertyWithAnExceedinglyLongName7: string;\n  propertyWithAnExceedinglyLongName8: string;\n};\n\n// String representation of type of &#39;x&#39; should be truncated in error message\nvar s: string = x;\n</code></pre>\n"
            },
            "allowSyntheticDefaultImports": {
              "description": "When set to true, `allowSyntheticDefaultImports` allows you to write an import like:\n\n```ts\nimport React from \"react\";\n```\n\ninstead of:\n\n```ts\nimport * as React from \"react\";\n```\n\nWhen the module **does not** explicitly specify a default export.\n\nFor example, without `allowSyntheticDefaultImports` as true:\n\n```ts twoslash\n// @errors: 1259 1192\n// @checkJs\n// @allowJs\n// @esModuleInterop: false\n// @filename: utilFunctions.js\n// @noImplicitAny: false\nconst getStringLength = (str) => str.length;\n\nmodule.exports = {\n  getStringLength,\n};\n\n// @filename: index.ts\nimport utils from \"./utilFunctions\";\n\nconst count = utils.getStringLength(\"Check JS\");\n```\n\nThis code raises an error because there isn't a `default` object which you can import. Even though it feels like it should.\nFor convenience, transpilers like Babel will automatically create a default if one isn't created. Making the module look a bit more like:\n\n```js\n// @filename: utilFunctions.js\nconst getStringLength = (str) => str.length;\nconst allFunctions = {\n  getStringLength,\n};\n\nmodule.exports = allFunctions;\nmodule.exports.default = allFunctions;\n```\n\nThis flag does not affect the JavaScript emitted by TypeScript, it's only for the type checking.\nThis option brings the behavior of TypeScript in-line with Babel, where extra code is emitted to make using a default export of a module more ergonomic.",
              "type": [
                "boolean",
                "null"
              ],
              "markdownDescription": "When set to true, `allowSyntheticDefaultImports` allows you to write an import like:\n\n```ts\nimport React from \"react\";\n```\n\ninstead of:\n\n```ts\nimport * as React from \"react\";\n```\n\nWhen the module **does not** explicitly specify a default export.\n\nFor example, without `allowSyntheticDefaultImports` as true:\n\n```ts twoslash\n// @errors: 1259 1192\n// @checkJs\n// @allowJs\n// @esModuleInterop: false\n// @filename: utilFunctions.js\n// @noImplicitAny: false\nconst getStringLength = (str) => str.length;\n\nmodule.exports = {\n  getStringLength,\n};\n\n// @filename: index.ts\nimport utils from \"./utilFunctions\";\n\nconst count = utils.getStringLength(\"Check JS\");\n```\n\nThis code raises an error because there isn't a `default` object which you can import. Even though it feels like it should.\nFor convenience, transpilers like Babel will automatically create a default if one isn't created. Making the module look a bit more like:\n\n```js\n// @filename: utilFunctions.js\nconst getStringLength = (str) => str.length;\nconst allFunctions = {\n  getStringLength,\n};\n\nmodule.exports = allFunctions;\nmodule.exports.default = allFunctions;\n```\n\nThis flag does not affect the JavaScript emitted by TypeScript, it's only for the type checking.\nThis option brings the behavior of TypeScript in-line with Babel, where extra code is emitted to make using a default export of a module more ergonomic.",
              "x-intellij-html-description": "<p>When set to true, <code>allowSyntheticDefaultImports</code> allows you to write an import like:</p>\n<pre><code class=\"language-ts\">import React from &quot;react&quot;;\n</code></pre>\n<p>instead of:</p>\n<pre><code class=\"language-ts\">import * as React from &quot;react&quot;;\n</code></pre>\n<p>When the module <strong>does not</strong> explicitly specify a default export.</p>\n<p>For example, without <code>allowSyntheticDefaultImports</code> as true:</p>\n<pre><code class=\"language-ts\">// @errors: 1259 1192\n// @checkJs\n// @allowJs\n// @esModuleInterop: false\n// @filename: utilFunctions.js\n// @noImplicitAny: false\nconst getStringLength = (str) =&gt; str.length;\n\nmodule.exports = {\n  getStringLength,\n};\n\n// @filename: index.ts\nimport utils from &quot;./utilFunctions&quot;;\n\nconst count = utils.getStringLength(&quot;Check JS&quot;);\n</code></pre>\n<p>This code raises an error because there isn&#39;t a <code>default</code> object which you can import. Even though it feels like it should.\nFor convenience, transpilers like Babel will automatically create a default if one isn&#39;t created. Making the module look a bit more like:</p>\n<pre><code class=\"language-js\">// @filename: utilFunctions.js\nconst getStringLength = (str) =&gt; str.length;\nconst allFunctions = {\n  getStringLength,\n};\n\nmodule.exports = allFunctions;\nmodule.exports.default = allFunctions;\n</code></pre>\n<p>This flag does not affect the JavaScript emitted by TypeScript, it&#39;s only for the type checking.\nThis option brings the behavior of TypeScript in-line with Babel, where extra code is emitted to make using a default export of a module more ergonomic.</p>\n"
            },
            "noImplicitUseStrict": {
              "description": "You shouldn't need this. By default, when emitting a module file to a non-ES6 target, TypeScript emits a `\"use strict\";` prologue at the top of the file.\nThis setting disables the prologue.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "You shouldn't need this. By default, when emitting a module file to a non-ES6 target, TypeScript emits a `\"use strict\";` prologue at the top of the file.\nThis setting disables the prologue.",
              "x-intellij-html-description": "<p>You shouldn&#39;t need this. By default, when emitting a module file to a non-ES6 target, TypeScript emits a <code>&quot;use strict&quot;;</code> prologue at the top of the file.\nThis setting disables the prologue.</p>\n"
            },
            "listEmittedFiles": {
              "description": "Print names of generated files part of the compilation to the terminal.\n\nThis flag is useful in two cases:\n\n- You want to transpile TypeScript as a part of a build chain in the terminal where the filenames are processed in the next command.\n- You are not sure that TypeScript has included a file you expected, as a part of debugging the [file inclusion settings](https://typescriptlang.org/tsconfig/#Project_Files_0).\n\nFor example:\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nWith:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"declaration\": true,\n    \"listEmittedFiles\": true\n  }\n}\n```\n\nWould echo paths like:\n\n```\n$ npm run tsc\n\npath/to/example/index.js\npath/to/example/index.d.ts\n```\n\nNormally, TypeScript would return silently on success.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Print names of generated files part of the compilation to the terminal.\n\nThis flag is useful in two cases:\n\n- You want to transpile TypeScript as a part of a build chain in the terminal where the filenames are processed in the next command.\n- You are not sure that TypeScript has included a file you expected, as a part of debugging the [file inclusion settings](https://typescriptlang.org/tsconfig/#Project_Files_0).\n\nFor example:\n\n```\nexample\n├── index.ts\n├── package.json\n└── tsconfig.json\n```\n\nWith:\n\n```json tsconfig\n{\n  \"compilerOptions\": {\n    \"declaration\": true,\n    \"listEmittedFiles\": true\n  }\n}\n```\n\nWould echo paths like:\n\n```\n$ npm run tsc\n\npath/to/example/index.js\npath/to/example/index.d.ts\n```\n\nNormally, TypeScript would return silently on success.",
              "x-intellij-html-description": "<p>Print names of generated files part of the compilation to the terminal.</p>\n<p>This flag is useful in two cases:</p>\n<ul>\n<li>You want to transpile TypeScript as a part of a build chain in the terminal where the filenames are processed in the next command.</li>\n<li>You are not sure that TypeScript has included a file you expected, as a part of debugging the <a href=\"https://typescriptlang.org/tsconfig/#Project_Files_0\">file inclusion settings</a>.</li>\n</ul>\n<p>For example:</p>\n<pre><code>example\n├── index.ts\n├── package.json\n└── tsconfig.json\n</code></pre>\n<p>With:</p>\n<pre><code class=\"language-json\">{\n  &quot;compilerOptions&quot;: {\n    &quot;declaration&quot;: true,\n    &quot;listEmittedFiles&quot;: true\n  }\n}\n</code></pre>\n<p>Would echo paths like:</p>\n<pre><code>$ npm run tsc\n\npath/to/example/index.js\npath/to/example/index.d.ts\n</code></pre>\n<p>Normally, TypeScript would return silently on success.</p>\n"
            },
            "disableSizeLimit": {
              "description": "To avoid a possible memory bloat issues when working with very large JavaScript projects, there is an upper limit to the amount of memory TypeScript will allocate. Turning this flag on will remove the limit.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "To avoid a possible memory bloat issues when working with very large JavaScript projects, there is an upper limit to the amount of memory TypeScript will allocate. Turning this flag on will remove the limit.",
              "x-intellij-html-description": "<p>To avoid a possible memory bloat issues when working with very large JavaScript projects, there is an upper limit to the amount of memory TypeScript will allocate. Turning this flag on will remove the limit.</p>\n"
            },
            "lib": {
              "description": "TypeScript includes a default set of type definitions for built-in JS APIs (like `Math`), as well as type definitions for things found in browser environments (like `document`).\nTypeScript also includes APIs for newer JS features matching the [`target`](https://typescriptlang.org/tsconfig/#target) you specify; for example the definition for `Map` is available if [`target`](https://typescriptlang.org/tsconfig/#target) is `ES6` or newer.\n\nYou may want to change these for a few reasons:\n\n- Your program doesn't run in a browser, so you don't want the `\"dom\"` type definitions\n- Your runtime platform provides certain JavaScript API objects (maybe through polyfills), but doesn't yet support the full syntax of a given ECMAScript version\n- You have polyfills or native implementations for some, but not all, of a higher level ECMAScript version\n\nIn TypeScript 4.5, lib files can be overridden by npm modules, find out more [in the blog](https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#supporting-lib-from-node_modules).\n\n### High Level libraries\n\n| Name         | Contents                                                                                                                                          |\n| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `ES5`        | Core definitions for all ES5 functionality                                                                                                        |\n| `ES2015`     | Additional APIs available in ES2015 (also known as ES6) - `array.find`, `Promise`, `Proxy`, `Symbol`, `Map`, `Set`, `Reflect`, etc.               |\n| `ES6`        | Alias for \"ES2015\"                                                                                                                                |\n| `ES2016`     | Additional APIs available in ES2016 - `array.include`, etc.                                                                                       |\n| `ES7`        | Alias for \"ES2016\"                                                                                                                                |\n| `ES2017`     | Additional APIs available in ES2017 - `Object.entries`, `Object.values`, `Atomics`, `SharedArrayBuffer`, `date.formatToParts`, typed arrays, etc. |\n| `ES2018`     | Additional APIs available in ES2018 - `async` iterables, `promise.finally`, `Intl.PluralRules`, `regexp.groups`, etc.                             |\n| `ES2019`     | Additional APIs available in ES2019 - `array.flat`, `array.flatMap`, `Object.fromEntries`, `string.trimStart`, `string.trimEnd`, etc.             |\n| `ES2020`     | Additional APIs available in ES2020 - `string.matchAll`, etc.                                                                                     |\n| `ES2021`     | Additional APIs available in ES2021 - `promise.any`, `string.replaceAll` etc.                                                                     |\n| `ES2022`     | Additional APIs available in ES2022 - `array.at`, `RegExp.hasIndices`, etc.                                                                       |\n| `ES2023`     | Additional APIs available in ES2023 - `array.with`, `array.findLast`, `array.findLastIndex`, `array.toSorted`, `array.toReversed`, etc.           |\n| `ESNext`     | Additional APIs available in ESNext - This changes as the JavaScript specification evolves                                                        |\n| `DOM`        | [DOM](https://developer.mozilla.org/docs/Glossary/DOM) definitions - `window`, `document`, etc.                                                   |\n| `WebWorker`  | APIs available in [WebWorker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API/Using_web_workers) contexts                              |\n| `ScriptHost` | APIs for the [Windows Script Hosting System](https://wikipedia.org/wiki/Windows_Script_Host)                                                      |\n\n### Individual library components\n\n| Name                      |\n| ------------------------- |\n| `DOM.Iterable`            |\n| `ES2015.Core`             |\n| `ES2015.Collection`       |\n| `ES2015.Generator`        |\n| `ES2015.Iterable`         |\n| `ES2015.Promise`          |\n| `ES2015.Proxy`            |\n| `ES2015.Reflect`          |\n| `ES2015.Symbol`           |\n| `ES2015.Symbol.WellKnown` |\n| `ES2016.Array.Include`    |\n| `ES2017.object`           |\n| `ES2017.Intl`             |\n| `ES2017.SharedMemory`     |\n| `ES2017.String`           |\n| `ES2017.TypedArrays`      |\n| `ES2018.Intl`             |\n| `ES2018.Promise`          |\n| `ES2018.RegExp`           |\n| `ES2019.Array`            |\n| `ES2019.Object`           |\n| `ES2019.String`           |\n| `ES2019.Symbol`           |\n| `ES2020.String`           |\n| `ES2020.Symbol.wellknown` |\n| `ES2021.Promise`          |\n| `ES2021.String`           |\n| `ES2021.WeakRef`          |\n| `ESNext.AsyncIterable`    |\n| `ESNext.Array`            |\n| `ESNext.Intl`             |\n| `ESNext.Symbol`           |\n\nThis list may be out of date, you can see the full list in the [TypeScript source code](https://github.com/microsoft/TypeScript/tree/main/src/lib).",
              "type": [
                "array",
                "null"
              ],
              "uniqueItems": true,
              "items": {
                "type": "string",
                "anyOf": [
                  {
                    "enum": [
                      "ES5",
                      "ES6",
                      "ES2015",
                      "ES2015.Collection",
                      "ES2015.Core",
                      "ES2015.Generator",
                      "ES2015.Iterable",
                      "ES2015.Promise",
                      "ES2015.Proxy",
                      "ES2015.Reflect",
                      "ES2015.Symbol.WellKnown",
                      "ES2015.Symbol",
                      "ES2016",
                      "ES2016.Array.Include",
                      "ES2017",
                      "ES2017.Intl",
                      "ES2017.Object",
                      "ES2017.SharedMemory",
                      "ES2017.String",
                      "ES2017.TypedArrays",
                      "ES2017.ArrayBuffer",
                      "ES2018",
                      "ES2018.AsyncGenerator",
                      "ES2018.AsyncIterable",
                      "ES2018.Intl",
                      "ES2018.Promise",
                      "ES2018.Regexp",
                      "ES2019",
                      "ES2019.Array",
                      "ES2019.Intl",
                      "ES2019.Object",
                      "ES2019.String",
                      "ES2019.Symbol",
                      "ES2020",
                      "ES2020.BigInt",
                      "ES2020.Promise",
                      "ES2020.String",
                      "ES2020.Symbol.WellKnown",
                      "ESNext",
                      "ESNext.Array",
                      "ESNext.AsyncIterable",
                      "ESNext.BigInt",
                      "ESNext.Collection",
                      "ESNext.Intl",
                      "ESNext.Iterator",
                      "ESNext.Object",
                      "ESNext.Promise",
                      "ESNext.Regexp",
                      "ESNext.String",
                      "ESNext.Symbol",
                      "DOM",
                      "DOM.AsyncIterable",
                      "DOM.Iterable",
                      "ScriptHost",
                      "WebWorker",
                      "WebWorker.AsyncIterable",
                      "WebWorker.ImportScripts",
                      "Webworker.Iterable",
                      "ES7",
                      "ES2021",
                      "ES2020.SharedMemory",
                      "ES2020.Intl",
                      "ES2020.Date",
                      "ES2020.Number",
                      "ES2021.Promise",
                      "ES2021.String",
                      "ES2021.WeakRef",
                      "ESNext.WeakRef",
                      "ES2021.Intl",
                      "ES2022",
                      "ES2022.Array",
                      "ES2022.Error",
                      "ES2022.Intl",
                      "ES2022.Object",
                      "ES2022.Regexp",
                      "ES2022.String",
                      "ES2022.SharedMemory",
                      "ES2022.RegExp",
                      "ES2023",
                      "ES2023.Array",
                      "ES2024",
                      "ES2024.ArrayBuffer",
                      "ES2024.Collection",
                      "ES2024.Object",
                      "ES2024.Promise",
                      "ES2024.Regexp",
                      "ES2024.SharedMemory",
                      "ES2024.String",
                      "ES2025",
                      "ES2025.Collection",
                      "ES2025.Float16",
                      "ES2025.Intl",
                      "ES2025.Iterator",
                      "ES2025.Promise",
                      "ES2025.Regexp",
                      "Decorators",
                      "Decorators.Legacy",
                      "ES2017.Date",
                      "ES2023.Collection",
                      "ES2023.Intl",
                      "ESNext.Decorators",
                      "ESNext.Disposable",
                      "ESNext.Error",
                      "ESNext.Sharedmemory"
                    ]
                  },
                  {
                    "pattern": "^[Ee][Ss]5|[Ee][Ss]6|[Ee][Ss]7$"
                  },
                  {
                    "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]))?$"
                  },
                  {
                    "pattern": "^[Ee][Ss]2016(\\.[Aa][Rr][Rr][Aa][Yy]\\.[Ii][Nn][Cc][Ll][Uu][Dd][Ee])?$"
                  },
                  {
                    "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]))?$"
                  },
                  {
                    "pattern": "^[Ee][Ss]2018(\\.([Aa][Ss][Yy][Nn][Cc][Gg][Ee][Nn][Ee][Rr][Aa][Tt][Oo][Rr]|[Aa][Ss][Yy][Nn][Cc][Ii][Tt][Ee][Rr][Aa][Bb][Ll][Ee]|[Ii][Nn][Tt][Ll]|[Pp][Rr][Oo][Mm][Ii][Ss][Ee]|[Rr][Ee][Gg][Ee][Xx][Pp]))?$"
                  },
                  {
                    "pattern": "^[Ee][Ss]2019(\\.([Aa][Rr][Rr][Aa][Yy]|[Ii][Nn][Tt][Ll]|[Oo][Bb][Jj][Ee][Cc][Tt]|[Ss][Tt][Rr][Ii][Nn][Gg]|[Ss][Yy][Mm][Bb][Oo][Ll]))?$"
                  },
                  {
                    "pattern": "^[Ee][Ss]2020(\\.([Bb][Ii][Gg][Ii][Nn][Tt]|[Pp][Rr][Oo][Mm][Ii][Ss][Ee]|[Ss][Tt][Rr][Ii][Nn][Gg]|[Ss][Yy][Mm][Bb][Oo][Ll]\\.[Ww][Ee][Ll][Ll][Kk][Nn][Oo][Ww][Nn]|[Ss][Hh][Aa][Rr][Ee][Dd][Mm][Ee][Mm][Oo][Rr][Yy]|[Ii][Nn][Tt][Ll]|[Dd][Aa][Tt][Ee]|[Nn][Uu][Mm][Bb][Ee][Rr]))?$"
                  },
                  {
                    "pattern": "^[Ee][Ss]2021(\\.([Ii][Nn][Tt][Ll]|[Pp][Rr][Oo][Mm][Ii][Ss][Ee]|[Ss][Tt][Rr][Ii][Nn][Gg]|[Ww][Ee][Aa][Kk][Rr][Ee][Ff]))?$"
                  },
                  {
                    "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]))?$"
                  },
                  {
                    "pattern": "^[Ee][Ss]2023(\\.([Aa][Rr][Rr][Aa][Yy]|[Cc][Oo][Ll][Ll][Ee][Cc][Tt][Ii][Oo][Nn]))?$"
                  },
                  {
                    "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]))?$"
                  },
                  {
                    "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]))?$"
                  },
                  {
                    "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]))?$"
                  },
                  {
                    "pattern": "^[Dd][Oo][Mm](\\.([Aa][Ss][Yy][Nn][Cc])?[Ii][Tt][Ee][Rr][Aa][Bb][Ll][Ee])?$"
                  },
                  {
                    "pattern": "^[Ss][Cc][Rr][Ii][Pp][Tt][Hh][Oo][Ss][Tt]$"
                  },
                  {
                    "pattern": "^[Ww][Ee][Bb][Ww][Oo][Rr][Kk][Ee][Rr](\\.([Ii][Mm][Pp][Oo][Rr][Tt][Ss][Cc][Rr][Ii][Pp][Tt][Ss]|([Aa][Ss][Yy][Nn][Cc])?[Ii][Tt][Ee][Rr][Aa][Bb][Ll][Ee]))?$"
                  },
                  {
                    "pattern": "^[Dd][Ee][Cc][Oo][Rr][Aa][Tt][Oo][Rr][Ss](\\.([Ll][Ee][Gg][Aa][Cc][Yy]))?$"
                  }
                ]
              },
              "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).",
              "x-intellij-html-description": "<p>TypeScript includes a default set of type definitions for built-in JS APIs (like <code>Math</code>), as well as type definitions for things found in browser environments (like <code>document</code>).\nTypeScript also includes APIs for newer JS features matching the <a href=\"https://typescriptlang.org/tsconfig/#target\"><code>target</code></a> you specify; for example the definition for <code>Map</code> is available if <a href=\"https://typescriptlang.org/tsconfig/#target\"><code>target</code></a> is <code>ES6</code> or newer.</p>\n<p>You may want to change these for a few reasons:</p>\n<ul>\n<li>Your program doesn&#39;t run in a browser, so you don&#39;t want the <code>&quot;dom&quot;</code> type definitions</li>\n<li>Your runtime platform provides certain JavaScript API objects (maybe through polyfills), but doesn&#39;t yet support the full syntax of a given ECMAScript version</li>\n<li>You have polyfills or native implementations for some, but not all, of a higher level ECMAScript version</li>\n</ul>\n<p>In TypeScript 4.5, lib files can be overridden by npm modules, find out more <a href=\"https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#supporting-lib-from-node_modules\">in the blog</a>.</p>\n<h3>High Level libraries</h3>\n<table>\n<thead>\n<tr>\n<th>Name</th>\n<th>Contents</th>\n</tr>\n</thead>\n<tbody><tr>\n<td><code>ES5</code></td>\n<td>Core definitions for all ES5 functionality</td>\n</tr>\n<tr>\n<td><code>ES2015</code></td>\n<td>Additional APIs available in ES2015 (also known as ES6) - <code>array.find</code>, <code>Promise</code>, <code>Proxy</code>, <code>Symbol</code>, <code>Map</code>, <code>Set</code>, <code>Reflect</code>, etc.</td>\n</tr>\n<tr>\n<td><code>ES6</code></td>\n<td>Alias for &quot;ES2015&quot;</td>\n</tr>\n<tr>\n<td><code>ES2016</code></td>\n<td>Additional APIs available in ES2016 - <code>array.include</code>, etc.</td>\n</tr>\n<tr>\n<td><code>ES7</code></td>\n<td>Alias for &quot;ES2016&quot;</td>\n</tr>\n<tr>\n<td><code>ES2017</code></td>\n<td>Additional APIs available in ES2017 - <code>Object.entries</code>, <code>Object.values</code>, <code>Atomics</code>, <code>SharedArrayBuffer</code>, <code>date.formatToParts</code>, typed arrays, etc.</td>\n</tr>\n<tr>\n<td><code>ES2018</code></td>\n<td>Additional APIs available in ES2018 - <code>async</code> iterables, <code>promise.finally</code>, <code>Intl.PluralRules</code>, <code>regexp.groups</code>, etc.</td>\n</tr>\n<tr>\n<td><code>ES2019</code></td>\n<td>Additional APIs available in ES2019 - <code>array.flat</code>, <code>array.flatMap</code>, <code>Object.fromEntries</code>, <code>string.trimStart</code>, <code>string.trimEnd</code>, etc.</td>\n</tr>\n<tr>\n<td><code>ES2020</code></td>\n<td>Additional APIs available in ES2020 - <code>string.matchAll</code>, etc.</td>\n</tr>\n<tr>\n<td><code>ES2021</code></td>\n<td>Additional APIs available in ES2021 - <code>promise.any</code>, <code>string.replaceAll</code> etc.</td>\n</tr>\n<tr>\n<td><code>ES2022</code></td>\n<td>Additional APIs available in ES2022 - <code>array.at</code>, <code>RegExp.hasIndices</code>, etc.</td>\n</tr>\n<tr>\n<td><code>ES2023</code></td>\n<td>Additional APIs available in ES2023 - <code>array.with</code>, <code>array.findLast</code>, <code>array.findLastIndex</code>, <code>array.toSorted</code>, <code>array.toReversed</code>, etc.</td>\n</tr>\n<tr>\n<td><code>ESNext</code></td>\n<td>Additional APIs available in ESNext - This changes as the JavaScript specification evolves</td>\n</tr>\n<tr>\n<td><code>DOM</code></td>\n<td><a href=\"https://developer.mozilla.org/docs/Glossary/DOM\">DOM</a> definitions - <code>window</code>, <code>document</code>, etc.</td>\n</tr>\n<tr>\n<td><code>WebWorker</code></td>\n<td>APIs available in <a href=\"https://developer.mozilla.org/docs/Web/API/Web_Workers_API/Using_web_workers\">WebWorker</a> contexts</td>\n</tr>\n<tr>\n<td><code>ScriptHost</code></td>\n<td>APIs for the <a href=\"https://wikipedia.org/wiki/Windows_Script_Host\">Windows Script Hosting System</a></td>\n</tr>\n</tbody></table>\n<h3>Individual library components</h3>\n<table>\n<thead>\n<tr>\n<th>Name</th>\n</tr>\n</thead>\n<tbody><tr>\n<td><code>DOM.Iterable</code></td>\n</tr>\n<tr>\n<td><code>ES2015.Core</code></td>\n</tr>\n<tr>\n<td><code>ES2015.Collection</code></td>\n</tr>\n<tr>\n<td><code>ES2015.Generator</code></td>\n</tr>\n<tr>\n<td><code>ES2015.Iterable</code></td>\n</tr>\n<tr>\n<td><code>ES2015.Promise</code></td>\n</tr>\n<tr>\n<td><code>ES2015.Proxy</code></td>\n</tr>\n<tr>\n<td><code>ES2015.Reflect</code></td>\n</tr>\n<tr>\n<td><code>ES2015.Symbol</code></td>\n</tr>\n<tr>\n<td><code>ES2015.Symbol.WellKnown</code></td>\n</tr>\n<tr>\n<td><code>ES2016.Array.Include</code></td>\n</tr>\n<tr>\n<td><code>ES2017.object</code></td>\n</tr>\n<tr>\n<td><code>ES2017.Intl</code></td>\n</tr>\n<tr>\n<td><code>ES2017.SharedMemory</code></td>\n</tr>\n<tr>\n<td><code>ES2017.String</code></td>\n</tr>\n<tr>\n<td><code>ES2017.TypedArrays</code></td>\n</tr>\n<tr>\n<td><code>ES2018.Intl</code></td>\n</tr>\n<tr>\n<td><code>ES2018.Promise</code></td>\n</tr>\n<tr>\n<td><code>ES2018.RegExp</code></td>\n</tr>\n<tr>\n<td><code>ES2019.Array</code></td>\n</tr>\n<tr>\n<td><code>ES2019.Object</code></td>\n</tr>\n<tr>\n<td><code>ES2019.String</code></td>\n</tr>\n<tr>\n<td><code>ES2019.Symbol</code></td>\n</tr>\n<tr>\n<td><code>ES2020.String</code></td>\n</tr>\n<tr>\n<td><code>ES2020.Symbol.wellknown</code></td>\n</tr>\n<tr>\n<td><code>ES2021.Promise</code></td>\n</tr>\n<tr>\n<td><code>ES2021.String</code></td>\n</tr>\n<tr>\n<td><code>ES2021.WeakRef</code></td>\n</tr>\n<tr>\n<td><code>ESNext.AsyncIterable</code></td>\n</tr>\n<tr>\n<td><code>ESNext.Array</code></td>\n</tr>\n<tr>\n<td><code>ESNext.Intl</code></td>\n</tr>\n<tr>\n<td><code>ESNext.Symbol</code></td>\n</tr>\n</tbody></table>\n<p>This list may be out of date, you can see the full list in the <a href=\"https://github.com/microsoft/TypeScript/tree/main/src/lib\">TypeScript source code</a>.</p>\n"
            },
            "libReplacement": {
              "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`.\nIn the future, `--libReplacement false` may become the default, so if you currently rely on the behavior you should consider explicitly enabling it with `--libReplacement true`.",
              "type": [
                "boolean",
                "null"
              ],
              "default": true,
              "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`.\nIn the future, `--libReplacement false` may become the default, so if you currently rely on the behavior you should consider explicitly enabling it with `--libReplacement true`.",
              "x-intellij-html-description": "<p>TypeScript 4.5 introduced the possibility of substituting the default <code>lib</code> files with custom ones.\nAll built-in library files would first try to be resolved from packages named <code>@typescript/lib-*</code>.\nFor example, you could lock your <code>dom</code> libraries onto a specific version of <a href=\"https://www.npmjs.com/package/@types/web?activeTab=readme\">the <code>@types/web</code> package</a> with the following <code>package.json</code>:</p>\n<pre><code class=\"language-json\">{\n    &quot;devDependencies&quot;: {\n       &quot;@typescript/lib-dom&quot;: &quot;npm:@types/web@0.0.199&quot;\n     }\n}\n</code></pre>\n<p>When installed, a package called <code>@typescript/lib-dom</code> should exist, and TypeScript would always look there when searching for <code>lib.dom.d.ts</code>.</p>\n<p>The <code>--libReplacement</code> flag allows you to disable this behavior.\nIf you&#39;re not using any <code>@typescript/lib-*</code> packages, you can now disable those package lookups with <code>--libReplacement false</code>.\nIn the future, <code>--libReplacement false</code> may become the default, so if you currently rely on the behavior you should consider explicitly enabling it with <code>--libReplacement true</code>.</p>\n"
            },
            "moduleDetection": {
              "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.",
              "enum": [
                "auto",
                "legacy",
                "force"
              ]
            },
            "strictNullChecks": {
              "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) => 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) => 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) => 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) => boolean): S;\n};\n```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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) => 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) => 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) => 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) => boolean): S;\n};\n```",
              "x-intellij-html-description": "<p>When <code>strictNullChecks</code> is <code>false</code>, <code>null</code> and <code>undefined</code> are effectively ignored by the language.\nThis can lead to unexpected errors at runtime.</p>\n<p>When <code>strictNullChecks</code> is <code>true</code>, <code>null</code> and <code>undefined</code> have their own distinct types and you&#39;ll get a type error if you try to use them where a concrete value is expected.</p>\n<p>For example with this TypeScript code, <code>users.find</code> has no guarantee that it will actually find a user, but you can\nwrite code as though it will:</p>\n<pre><code class=\"language-ts\">// @strictNullChecks: false\n// @target: ES2015\ndeclare const loggedInUsername: string;\n\nconst users = [\n  { name: &quot;Oby&quot;, age: 12 },\n  { name: &quot;Heera&quot;, age: 32 },\n];\n\nconst loggedInUser = users.find((u) =&gt; u.name === loggedInUsername);\nconsole.log(loggedInUser.age);\n</code></pre>\n<p>Setting <code>strictNullChecks</code> to <code>true</code> will raise an error that you have not made a guarantee that the <code>loggedInUser</code> exists before trying to use it.</p>\n<pre><code class=\"language-ts\">// @errors: 2339 2532 18048\n// @target: ES2020\n// @strictNullChecks\ndeclare const loggedInUsername: string;\n\nconst users = [\n  { name: &quot;Oby&quot;, age: 12 },\n  { name: &quot;Heera&quot;, age: 32 },\n];\n\nconst loggedInUser = users.find((u) =&gt; u.name === loggedInUsername);\nconsole.log(loggedInUser.age);\n</code></pre>\n<p>The second example failed because the array&#39;s <code>find</code> function looks a bit like this simplification:</p>\n<pre><code class=\"language-ts\">// When strictNullChecks: true\ntype Array = {\n  find(predicate: (value: any, index: number) =&gt; 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) =&gt; boolean): S;\n};\n</code></pre>\n"
            },
            "maxNodeModuleJsDepth": {
              "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.",
              "type": [
                "number",
                "null"
              ],
              "default": 0,
              "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.",
              "x-intellij-html-description": "<p>The maximum dependency depth to search under <code>node_modules</code> and load JavaScript files.</p>\n<p>This flag can only be used when <a href=\"https://typescriptlang.org/tsconfig/#allowJs\"><code>allowJs</code></a> is enabled, and is used if you want to have TypeScript infer types for all of the JavaScript inside your <code>node_modules</code>.</p>\n<p>Ideally this should stay at 0 (the default), and <code>d.ts</code> 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.</p>\n"
            },
            "importHelpers": {
              "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.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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.",
              "x-intellij-html-description": "<p>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.</p>\n<p>If the <code>importHelpers</code> flag is on, these helper functions are instead imported from the <a href=\"https://www.npmjs.com/package/tslib\">tslib</a> module.\nYou will need to ensure that the <code>tslib</code> module is able to be imported at runtime.\nThis only affects modules; global script files will not attempt to import modules.</p>\n<p>For example, with this TypeScript:</p>\n<pre><code class=\"language-ts\">export function fn(arr: number[]) {\n  const arr2 = [1, ...arr];\n}\n</code></pre>\n<p>Turning on <a href=\"https://typescriptlang.org/tsconfig/#downlevelIteration\"><code>downlevelIteration</code></a> and <code>importHelpers</code> is still false:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @target: ES5\n// @downleveliteration\nexport function fn(arr: number[]) {\n  const arr2 = [1, ...arr];\n}\n</code></pre>\n<p>Then turning on both <a href=\"https://typescriptlang.org/tsconfig/#downlevelIteration\"><code>downlevelIteration</code></a> and <code>importHelpers</code>:</p>\n<pre><code class=\"language-ts\">// @showEmit\n// @target: ES5\n// @downleveliteration\n// @importhelpers\n// @noErrors\nexport function fn(arr: number[]) {\n  const arr2 = [1, ...arr];\n}\n</code></pre>\n<p>You can use <a href=\"https://typescriptlang.org/tsconfig/#noEmitHelpers\"><code>noEmitHelpers</code></a> when you provide your own implementations of these functions.</p>\n"
            },
            "importsNotUsedAsValues": {
              "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.",
              "default": "remove",
              "enum": [
                "remove",
                "preserve",
                "error"
              ]
            },
            "alwaysStrict": {
              "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.",
              "type": [
                "boolean",
                "null"
              ],
              "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.",
              "x-intellij-html-description": "<p>Ensures that your files are parsed in the ECMAScript strict mode, and emit &quot;use strict&quot; for each source file.</p>\n<p><a href=\"https://developer.mozilla.org/docs/Web/JavaScript/Reference/Strict_mode\">ECMAScript strict</a> 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.</p>\n"
            },
            "strict": {
              "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.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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.",
              "x-intellij-html-description": "<p>The <code>strict</code> 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 <em>strict mode family</em> options, which are outlined below.\nYou can then turn off individual strict mode family checks as needed.</p>\n<p>Future 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.</p>\n"
            },
            "strictBindCallApply": {
              "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```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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```",
              "x-intellij-html-description": "<p>When set, TypeScript will check that the built-in methods of functions <code>call</code>, <code>bind</code>, and <code>apply</code> are invoked with correct argument for the underlying function:</p>\n<pre><code class=\"language-ts\">// @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, &quot;10&quot;);\n\nconst n2 = fn.call(undefined, false);\n</code></pre>\n<p>Otherwise, these functions accept any arguments and will return <code>any</code>:</p>\n<pre><code class=\"language-ts\">// @strictBindCallApply: false\n\n// With strictBindCallApply off\nfunction fn(x: string) {\n  return parseInt(x);\n}\n\n// Note: No error; return type is &#39;any&#39;\nconst n = fn.call(undefined, false);\n</code></pre>\n"
            },
            "downlevelIteration": {
              "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', <1 empty item>, 'c' ]\nconsole.log(spread)\n// [ 'a', undefined, 'c' ]\nconsole.log(concatenated)\n// [ 'a', <1 empty item>, 'c' ]\n```\n\nJust as with `for / of`, `downlevelIteration` will use `Symbol.iterator` (if present) to more accurately emulate ES 6 behavior.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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', <1 empty item>, 'c' ]\nconsole.log(spread)\n// [ 'a', undefined, 'c' ]\nconsole.log(concatenated)\n// [ 'a', <1 empty item>, 'c' ]\n```\n\nJust as with `for / of`, `downlevelIteration` will use `Symbol.iterator` (if present) to more accurately emulate ES 6 behavior.",
              "x-intellij-html-description": "<p>Downleveling is TypeScript&#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.</p>\n<p>ECMAScript 6 added several new iteration primitives: the <code>for / of</code> loop (<code>for (el of arr)</code>), Array spread (<code>[a, ...b]</code>), argument spread (<code>fn(...args)</code>), and <code>Symbol.iterator</code>.\n<code>downlevelIteration</code> allows for these iteration primitives to be used more accurately in ES5 environments if a <code>Symbol.iterator</code> implementation is present.</p>\n<h4>Example: Effects on <code>for / of</code></h4>\n<p>With this TypeScript code:</p>\n<pre><code class=\"language-ts\">const str = &quot;Hello!&quot;;\nfor (const s of str) {\n  console.log(s);\n}\n</code></pre>\n<p>Without <code>downlevelIteration</code> enabled, a <code>for / of</code> loop on any object is downleveled to a traditional <code>for</code> loop:</p>\n<pre><code class=\"language-ts\">// @target: ES5\n// @showEmit\nconst str = &quot;Hello!&quot;;\nfor (const s of str) {\n  console.log(s);\n}\n</code></pre>\n<p>This is often what people expect, but it&#39;s not 100% compliant with ECMAScript iteration protocol.\nCertain strings, such as emoji (😜), have a <code>.length</code> of 2 (or even more!), but should iterate as 1 unit in a <code>for-of</code> loop.\nSee <a href=\"https://blog.jonnew.com/posts/poo-dot-length-equals-two\">this blog post by Jonathan New</a> for a longer explanation.</p>\n<p>When <code>downlevelIteration</code> is enabled, TypeScript will use a helper function that checks for a <code>Symbol.iterator</code> implementation (either native or polyfill).\nIf this implementation is missing, you&#39;ll fall back to index-based iteration.</p>\n<pre><code class=\"language-ts\">// @target: ES5\n// @downlevelIteration\n// @showEmit\nconst str = &quot;Hello!&quot;;\nfor (const s of str) {\n  console.log(s);\n}\n</code></pre>\n<p>You can use <a href=\"https://www.npmjs.com/package/tslib\">tslib</a> via <a href=\"https://typescriptlang.org/tsconfig/#importHelpers\"><code>importHelpers</code></a> to reduce the amount of inline JavaScript too:</p>\n<pre><code class=\"language-ts\">// @target: ES5\n// @downlevelIteration\n// @importHelpers\n// @showEmit\nconst str = &quot;Hello!&quot;;\nfor (const s of str) {\n  console.log(s);\n}\n</code></pre>\n<p><strong>Note:</strong> enabling <code>downlevelIteration</code> does not improve compliance if <code>Symbol.iterator</code> is not present in the runtime.</p>\n<h4>Example: Effects on Array Spreads</h4>\n<p>This is an array spread:</p>\n<pre><code class=\"language-js\">// Make a new array whose elements are 1 followed by the elements of arr2\nconst arr = [1, ...arr2];\n</code></pre>\n<p>Based on the description, it sounds easy to downlevel to ES5:</p>\n<pre><code class=\"language-js\">// The same, right?\nconst arr = [1].concat(arr2);\n</code></pre>\n<p>However, this is observably different in certain rare cases.</p>\n<p>For example, if a source array is missing one or more items (contains a hole), the spread syntax will replace each empty item with <code>undefined</code>, whereas <code>.concat</code> will leave them intact.</p>\n<pre><code class=\"language-js\">// Make an array where the element at index 1 is missing\nlet arrayWithHole = [&#39;a&#39;, , &#39;c&#39;];\nlet spread = [...arrayWithHole];\nlet concatenated = [].concat(arrayWithHole);\n\nconsole.log(arrayWithHole)\n// [ &#39;a&#39;, &lt;1 empty item&gt;, &#39;c&#39; ]\nconsole.log(spread)\n// [ &#39;a&#39;, undefined, &#39;c&#39; ]\nconsole.log(concatenated)\n// [ &#39;a&#39;, &lt;1 empty item&gt;, &#39;c&#39; ]\n</code></pre>\n<p>Just as with <code>for / of</code>, <code>downlevelIteration</code> will use <code>Symbol.iterator</code> (if present) to more accurately emulate ES 6 behavior.</p>\n"
            },
            "checkJs": {
              "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```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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```",
              "x-intellij-html-description": "<p>Works in tandem with <a href=\"https://typescriptlang.org/tsconfig/#allowJs\"><code>allowJs</code></a>. When <code>checkJs</code> is enabled then errors are reported in JavaScript files. This is\nthe equivalent of including <code>// @ts-check</code> at the top of all JavaScript files which are included in your project.</p>\n<p>For example, this is incorrect JavaScript according to the <code>parseFloat</code> type definition which comes with TypeScript:</p>\n<pre><code class=\"language-js\">// parseFloat only takes a string\nmodule.exports.pi = parseFloat(3.142);\n</code></pre>\n<p>When imported into a TypeScript module:</p>\n<pre><code class=\"language-ts\">// @allowJs\n// @filename: constants.js\nmodule.exports.pi = parseFloat(3.142);\n\n// @filename: index.ts\nimport { pi } from &quot;./constants&quot;;\nconsole.log(pi);\n</code></pre>\n<p>You will not get any errors. However, if you turn on <code>checkJs</code> then you will get error messages from the JavaScript file.</p>\n<pre><code class=\"language-ts\">// @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 &quot;./constants&quot;;\nconsole.log(pi);\n</code></pre>\n"
            },
            "strictFunctionTypes": {
              "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) => 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) => 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```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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) => 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) => 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```",
              "x-intellij-html-description": "<p>When enabled, this flag causes functions parameters to be checked more correctly.</p>\n<p>Here&#39;s a basic example with <code>strictFunctionTypes</code> off:</p>\n<pre><code class=\"language-ts\">// @strictFunctionTypes: false\nfunction fn(x: string) {\n  console.log(&quot;Hello, &quot; + x.toLowerCase());\n}\n\ntype StringOrNumberFunc = (ns: string | number) =&gt; void;\n\n// Unsafe assignment\nlet func: StringOrNumberFunc = fn;\n// Unsafe call - will crash\nfunc(10);\n</code></pre>\n<p>With <code>strictFunctionTypes</code> <em>on</em>, the error is correctly detected:</p>\n<pre><code class=\"language-ts\">// @errors: 2322\nfunction fn(x: string) {\n  console.log(&quot;Hello, &quot; + x.toLowerCase());\n}\n\ntype StringOrNumberFunc = (ns: string | number) =&gt; void;\n\n// Unsafe assignment is prevented\nlet func: StringOrNumberFunc = fn;\n</code></pre>\n<p>During 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 <em>function</em> syntax, not to those in <em>method</em> syntax:</p>\n<pre><code class=\"language-ts\">type Methodish = {\n  func(x: string | number): void;\n};\n\nfunction fn(x: string) {\n  console.log(&quot;Hello, &quot; + x.toLowerCase());\n}\n\n// Ultimately an unsafe assignment, but not detected\nconst m: Methodish = {\n  func: fn,\n};\nm.func(10);\n</code></pre>\n"
            },
            "strictPropertyInitialization": {
              "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.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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.",
              "x-intellij-html-description": "<p>When set to true, TypeScript will raise an error when a class property was declared but not set in the constructor.</p>\n<pre><code class=\"language-ts\">// @errors: 2564\nclass UserAccount {\n  name: string;\n  accountType = &quot;user&quot;;\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</code></pre>\n<p>In the above case:</p>\n<ul>\n<li><code>this.name</code> is set specifically.</li>\n<li><code>this.accountType</code> is set by default.</li>\n<li><code>this.email</code> is not set and raises an error.</li>\n<li><code>this.address</code> is declared as potentially <code>undefined</code> which means it does not have to be set.</li>\n</ul>\n"
            },
            "esModuleInterop": {
              "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).",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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).",
              "x-intellij-html-description": "<p>By default (with <code>esModuleInterop</code> 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:</p>\n<ul>\n<li><p>a namespace import like <code>import * as moment from &quot;moment&quot;</code> acts the same as <code>const moment = require(&quot;moment&quot;)</code></p>\n</li>\n<li><p>a default import like <code>import moment from &quot;moment&quot;</code> acts the same as <code>const moment = require(&quot;moment&quot;).default</code></p>\n</li>\n</ul>\n<p>This mis-match causes these two issues:</p>\n<ul>\n<li><p>the ES6 modules spec states that a namespace import (<code>import * as x</code>) can only be an object, by having TypeScript\ntreating it the same as <code>= require(&quot;x&quot;)</code> then TypeScript allowed for the import to be treated as a function and be callable. That&#39;s not valid according to the spec.</p>\n</li>\n<li><p>while accurate to the ES6 modules spec, most libraries with CommonJS/AMD/UMD modules didn&#39;t conform as strictly as TypeScript&#39;s implementation.</p>\n</li>\n</ul>\n<p>Turning on <code>esModuleInterop</code> 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:</p>\n<pre><code class=\"language-ts\">import * as fs from &quot;fs&quot;;\nimport _ from &quot;lodash&quot;;\n\nfs.readFileSync(&quot;file.txt&quot;, &quot;utf8&quot;);\n_.chunk([&quot;a&quot;, &quot;b&quot;, &quot;c&quot;, &quot;d&quot;], 2);\n</code></pre>\n<p>With <code>esModuleInterop</code> disabled:</p>\n<pre><code class=\"language-ts\">// @noErrors\n// @showEmit\n// @esModuleInterop: false\n// @module: commonjs\nimport * as fs from &quot;fs&quot;;\nimport _ from &quot;lodash&quot;;\n\nfs.readFileSync(&quot;file.txt&quot;, &quot;utf8&quot;);\n_.chunk([&quot;a&quot;, &quot;b&quot;, &quot;c&quot;, &quot;d&quot;], 2);\n</code></pre>\n<p>With <code>esModuleInterop</code> set to <code>true</code>:</p>\n<pre><code class=\"language-ts\">// @noErrors\n// @showEmit\n// @esModuleInterop\n// @module: commonjs\nimport * as fs from &quot;fs&quot;;\nimport _ from &quot;lodash&quot;;\n\nfs.readFileSync(&quot;file.txt&quot;, &quot;utf8&quot;);\n_.chunk([&quot;a&quot;, &quot;b&quot;, &quot;c&quot;, &quot;d&quot;], 2);\n</code></pre>\n<p><em>Note</em>: The namespace import <code>import * as fs from &quot;fs&quot;</code> only accounts for properties which <a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty\">are owned</a> (basically properties set on the object and not via the prototype chain) on the imported object. If the module you&#39;re importing defines its API using inherited properties, you need to use the default import form (<code>import fs from &quot;fs&quot;</code>), or disable <code>esModuleInterop</code>.</p>\n<p><em>Note</em>: You can make JS emit terser by enabling <a href=\"https://typescriptlang.org/tsconfig/#importHelpers\"><code>importHelpers</code></a>:</p>\n<pre><code class=\"language-ts\">// @noErrors\n// @showEmit\n// @esModuleInterop\n// @importHelpers\n// @module: commonjs\nimport * as fs from &quot;fs&quot;;\nimport _ from &quot;lodash&quot;;\n\nfs.readFileSync(&quot;file.txt&quot;, &quot;utf8&quot;);\n_.chunk([&quot;a&quot;, &quot;b&quot;, &quot;c&quot;, &quot;d&quot;], 2);\n</code></pre>\n<p>Enabling <code>esModuleInterop</code> will also enable <a href=\"https://typescriptlang.org/tsconfig/#allowSyntheticDefaultImports\"><code>allowSyntheticDefaultImports</code></a>.</p>\n"
            },
            "allowUmdGlobalAccess": {
              "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.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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.",
              "x-intellij-html-description": "<p>When set to true, <code>allowUmdGlobalAccess</code> 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.</p>\n<p>An 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.</p>\n"
            },
            "keyofStringsOnly": {
              "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).",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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).",
              "x-intellij-html-description": "<p>This flag changes the <code>keyof</code> type operator to return <code>string</code> instead of <code>string | number</code> when applied to a type with a string index signature.</p>\n<p>This flag is used to help people keep this behavior from <a href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html#support-number-and-symbol-named-properties-with-keyof-and-mapped-types\">before TypeScript 2.9&#39;s release</a>.</p>\n"
            },
            "useDefineForClassFields": {
              "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).",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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).",
              "x-intellij-html-description": "<p>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&#39;s implementation but the same syntax.</p>\n<p>This flag switches to the upcoming ECMA runtime behavior.</p>\n<p>You can read more about the transition in <a href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#the-usedefineforclassfields-flag-and-the-declare-property-modifier\">the 3.7 release notes</a>.</p>\n"
            },
            "declarationMap": {
              "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.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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.",
              "x-intellij-html-description": "<p>Generates a source map for <code>.d.ts</code> files which map back to the original <code>.ts</code> source file.\nThis will allow editors such as VS Code to go to the original <code>.ts</code> file when using features like <em>Go to Definition</em>.</p>\n<p>You should strongly consider turning this on if you&#39;re using project references.</p>\n"
            },
            "resolveJsonModule": {
              "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```",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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```",
              "x-intellij-html-description": "<p>Allows importing modules with a <code>.json</code> extension, which is a common practice in node projects. This includes\ngenerating a type for the <code>import</code> based on the static JSON shape.</p>\n<p>TypeScript does not support resolving JSON files by default:</p>\n<pre><code class=\"language-ts\">// @errors: 2732\n// @filename: settings.json\n{\n    &quot;repo&quot;: &quot;TypeScript&quot;,\n    &quot;dry&quot;: false,\n    &quot;debug&quot;: false\n}\n// @filename: index.ts\nimport settings from &quot;./settings.json&quot;;\n\nsettings.debug === true;\nsettings.dry === 2;\n</code></pre>\n<p>Enabling the option allows importing JSON, and validating the types in that JSON file.</p>\n<pre><code class=\"language-ts\">// @errors: 2367\n// @resolveJsonModule\n// @module: commonjs\n// @moduleResolution: node\n// @filename: settings.json\n{\n    &quot;repo&quot;: &quot;TypeScript&quot;,\n    &quot;dry&quot;: false,\n    &quot;debug&quot;: false\n}\n// @filename: index.ts\nimport settings from &quot;./settings.json&quot;;\n\nsettings.debug === true;\nsettings.dry === 2;\n</code></pre>\n"
            },
            "resolvePackageJsonExports": {
              "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).",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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).",
              "x-intellij-html-description": "<p><code>--resolvePackageJsonExports</code> forces TypeScript to consult <a href=\"https://nodejs.org/api/packages.html#exports\">the <code>exports</code> field of <code>package.json</code> files</a> if it ever reads from a package in <code>node_modules</code>.</p>\n<p>This option defaults to <code>true</code> under the <code>node16</code>, <code>nodenext</code>, and <code>bundler</code> options for <a href=\"https://typescriptlang.org/tsconfig/#moduleResolution\"><code>--moduleResolution</code></a>.</p>\n"
            },
            "resolvePackageJsonImports": {
              "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).",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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).",
              "x-intellij-html-description": "<p><code>--resolvePackageJsonImports</code> forces TypeScript to consult <a href=\"https://nodejs.org/api/packages.html#imports\">the <code>imports</code> field of <code>package.json</code> files</a> when performing a lookup that starts with <code>#</code> from a file whose ancestor directory contains a <code>package.json</code>.</p>\n<p>This option defaults to <code>true</code> under the <code>node16</code>, <code>nodenext</code>, and <code>bundler</code> options for <a href=\"https://typescriptlang.org/tsconfig/#moduleResolution\"><code>--moduleResolution</code></a>.</p>\n"
            },
            "assumeChangesOnlyAffectDirectDependencies": {
              "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.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "extendedDiagnostics": {
              "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).",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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).",
              "x-intellij-html-description": "<p>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.</p>\n<p>You can learn more about how to measure and understand the output in the performance <a href=\"https://github.com/microsoft/TypeScript/wiki/Performance\">section of the wiki</a>.</p>\n"
            },
            "listFilesOnly": {
              "description": "Print names of files that are part of the compilation and then stop processing.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "disableSourceOfProjectReferenceRedirect": {
              "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.",
              "type": [
                "boolean",
                "null"
              ],
              "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.",
              "x-intellij-html-description": "<p>When working with <a href=\"https://typescriptlang.org/docs/handbook/project-references.html\">composite TypeScript projects</a>, this option provides a way to go <a href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#build-free-editing-with-project-references\">back to the pre-3.7</a> 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.</p>\n"
            },
            "disableSolutionSearching": {
              "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.",
              "type": [
                "boolean",
                "null"
              ],
              "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.",
              "x-intellij-html-description": "<p>When working with <a href=\"https://typescriptlang.org/docs/handbook/project-references.html\">composite TypeScript projects</a>, this option provides a way to declare that you do not want a project to be included when using features like <em>find all references</em> or <em>jump to definition</em> in an editor.</p>\n<p>This flag is something you can use to increase responsiveness in large composite projects.</p>\n"
            },
            "verbatimModuleSyntax": {
              "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<table>\n<thead>\n    <tr>\n        <th>Input TypeScript</th>\n        <th>Output JavaScript</th>\n    </tr>\n</thead>\n\n<tr>\n<td>\n\n```ts\nimport foo = require(\"foo\");\n```\n\n</td>\n<td>\n\n```js\nconst foo = require(\"foo\");\n```\n\n</td>\n</tr>\n<tr>\n<td>\n\n```ts\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nexport = {\n    foo,\n    bar,\n    baz\n};\n```\n\n</td>\n<td>\n\n```js\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nmodule.exports = {\n    foo,\n    bar,\n    baz\n};\n```\n\n</td>\n</tr>\n</table>\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).",
              "type": [
                "boolean",
                "null"
              ],
              "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<table>\n<thead>\n    <tr>\n        <th>Input TypeScript</th>\n        <th>Output JavaScript</th>\n    </tr>\n</thead>\n\n<tr>\n<td>\n\n```ts\nimport foo = require(\"foo\");\n```\n\n</td>\n<td>\n\n```js\nconst foo = require(\"foo\");\n```\n\n</td>\n</tr>\n<tr>\n<td>\n\n```ts\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nexport = {\n    foo,\n    bar,\n    baz\n};\n```\n\n</td>\n<td>\n\n```js\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nmodule.exports = {\n    foo,\n    bar,\n    baz\n};\n```\n\n</td>\n</tr>\n</table>\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).",
              "x-intellij-html-description": "<p>By default, TypeScript does something called <em>import elision</em>.\nBasically, if you write something like</p>\n<pre><code class=\"language-ts\">import { Car } from &quot;./car&quot;;\n\nexport function drive(car: Car) {\n    // ...\n}\n</code></pre>\n<p>TypeScript detects that you&#39;re only using an import for types and drops the import entirely.\nYour output JavaScript might look something like this:</p>\n<pre><code class=\"language-js\">export function drive(car) {\n    // ...\n}\n</code></pre>\n<p>Most of the time this is good, because if <code>Car</code> isn&#39;t a value that&#39;s exported from <code>./car</code>, we&#39;ll get a runtime error.</p>\n<p>But it does add a layer of complexity for certain edge cases.\nFor example, notice there&#39;s no statement like <code>import &quot;./car&quot;;</code> - the import was dropped entirely.\nThat actually makes a difference for modules that have side-effects or not.</p>\n<p>TypeScript&#39;s emit strategy for JavaScript also has another few layers of complexity - import elision isn&#39;t always just driven by how an import is used - it often consults how a value is declared as well.\nSo it&#39;s not always clear whether code like the following</p>\n<pre><code class=\"language-ts\">export { Car } from &quot;./car&quot;;\n</code></pre>\n<p>should be preserved or dropped.\nIf <code>Car</code> is declared with something like a <code>class</code>, then it can be preserved in the resulting JavaScript file.\nBut if <code>Car</code> is only declared as a <code>type</code> alias or <code>interface</code>, then the JavaScript file shouldn&#39;t export <code>Car</code> at all.</p>\n<p>While TypeScript might be able to make these emit decisions based on information from across files, not every compiler can.</p>\n<p>The <code>type</code> 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 <code>type</code> modifier.</p>\n<pre><code class=\"language-ts\">// This statement can be dropped entirely in JS output\nimport type * as car from &quot;./car&quot;;\n\n// The named import/export &#39;Car&#39; can be dropped in JS output\nimport { type Car } from &quot;./car&quot;;\nexport { type Car } from &quot;./car&quot;;\n</code></pre>\n<p><code>type</code> 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 <code>type</code> and plain imports and exports.\nSo TypeScript has the flag <code>--importsNotUsedAsValues</code> to make sure you use the <code>type</code> modifier, <code>--preserveValueImports</code> to prevent <em>some</em> module elision behavior, and <code>--isolatedModules</code> 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.</p>\n<p>TypeScript 5.0 introduces a new option called <code>--verbatimModuleSyntax</code> to simplify the situation.\nThe rules are much simpler - any imports or exports without a <code>type</code> modifier are left around.\nAnything that uses the <code>type</code> modifier is dropped entirely.</p>\n<pre><code class=\"language-ts\">// Erased away entirely.\nimport type { A } from &quot;a&quot;;\n\n// Rewritten to &#39;import { b } from &quot;bcd&quot;;&#39;\nimport { b, type c, type d } from &quot;bcd&quot;;\n\n// Rewritten to &#39;import {} from &quot;xyz&quot;;&#39;\nimport { type xyz } from &quot;xyz&quot;;\n</code></pre>\n<p>With this new option, what you see is what you get.</p>\n<p>That does have some implications when it comes to module interop though.\nUnder this flag, ECMAScript <code>import</code>s and <code>export</code>s won&#39;t be rewritten to <code>require</code> calls when your settings or file extension implied a different module system.\nInstead, you&#39;ll get an error.\nIf you need to emit code that uses <code>require</code> and <code>module.exports</code>, you&#39;ll have to use TypeScript&#39;s module syntax that predates ES2015:</p>\n<table>\n<thead>\n    <tr>\n        <th>Input TypeScript</th>\n        <th>Output JavaScript</th>\n    </tr>\n</thead><tr>\n<td><pre><code class=\"language-ts\">import foo = require(&quot;foo&quot;);\n</code></pre>\n</td>\n<td><pre><code class=\"language-js\">const foo = require(&quot;foo&quot;);\n</code></pre>\n</td>\n</tr>\n<tr>\n<td><pre><code class=\"language-ts\">function foo() {}\nfunction bar() {}\nfunction baz() {}\n\nexport = {\n    foo,\n    bar,\n    baz\n};\n</code></pre>\n</td>\n<td><pre><code class=\"language-js\">function foo() {}\nfunction bar() {}\nfunction baz() {}\n\nmodule.exports = {\n    foo,\n    bar,\n    baz\n};\n</code></pre>\n</td>\n</tr>\n</table><p>While this is a limitation, it does help make some issues more obvious.\nFor example, it&#39;s very common to forget to set the <a href=\"https://nodejs.org/api/packages.html#type\"><code>type</code> field in <code>package.json</code></a> under <code>--module node16</code>.\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&#39;re intentional about the file type you&#39;re using because the syntax is intentionally different.</p>\n<p>Because <code>--verbatimModuleSyntax</code> provides a more consistent story than <code>--importsNotUsedAsValues</code> and <code>--preserveValueImports</code>, those two existing flags are being deprecated in its favor.</p>\n<p>For more details, read up on <a href=\"https://github.com/microsoft/TypeScript/pull/52203\">the original pull request</a> and <a href=\"https://github.com/microsoft/TypeScript/issues/51479\">its proposal issue</a>.</p>\n"
            },
            "noCheck": {
              "description": "Disable full type checking (only critical parse and emit errors will be reported).",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Disable full type checking (only critical parse and emit errors will be reported).",
              "x-intellij-html-description": "<p>Disable full type checking (only critical parse and emit errors will be reported).</p>\n"
            },
            "isolatedDeclarations": {
              "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)",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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)",
              "x-intellij-html-description": "<p>Require sufficient annotation on exports so other tools can trivially generate declaration files.</p>\n<p>For more information, see the <a href=\"https://typescriptlang.org/docs/handbook/release-notes/typescript-5-5.html#isolated-declarations\">5.5 release notes</a></p>\n"
            },
            "noUncheckedSideEffectImports": {
              "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`.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "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`.",
              "x-intellij-html-description": "<p>In JavaScript it&#39;s possible to <code>import</code> a module without actually importing any values from it.</p>\n<pre><code class=\"language-ts\">import &quot;some-module&quot;;\n</code></pre>\n<p>These imports are often called <em>side effect imports</em> 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).</p>\n<p>By 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.</p>\n<p>This 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 <code>.css</code> files by writing something like the following:</p>\n<pre><code class=\"language-tsx\">import &quot;./button-component.css&quot;;\n\nexport function Button() {\n    // ...\n}\n</code></pre>\n<p>Still, this masks potential typos on side effect imports.</p>\n<p>When <code>--noUncheckedSideEffectImports</code> is enabled, TypeScript will error if it can&#39;t find a source file for a side effect import.</p>\n<pre><code class=\"language-ts\">import &quot;oops-this-module-does-not-exist&quot;;\n//     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n// error: Cannot find module &#39;oops-this-module-does-not-exist&#39; or its corresponding\n//        type declarations.\n</code></pre>\n<p>When 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 <code>import</code>s for assets might be better served by writing what&#39;s called an <em>ambient module declaration</em> with a wildcard specifier.\nIt would go in a global file and look something like the following:</p>\n<pre><code class=\"language-ts\">// ./src/globals.d.ts\n\n// Recognize all CSS files as module imports.\ndeclare module &quot;*.css&quot; {}\n</code></pre>\n<p>In fact, you might already have a file like this in your project!\nFor example, running something like <code>vite init</code> might create a similar <code>vite-env.d.ts</code>.</p>\n"
            },
            "strictBuiltinIteratorReturn": {
              "description": "Built-in iterators are instantiated with a `TReturn` type of undefined instead of `any`.",
              "type": [
                "boolean",
                "null"
              ],
              "default": false,
              "markdownDescription": "Built-in iterators are instantiated with a `TReturn` type of undefined instead of `any`.",
              "x-intellij-html-description": "<p>Built-in iterators are instantiated with a <code>TReturn</code> type of undefined instead of <code>any</code>.</p>\n"
            }
          }
        }
      }
    },
    "typeAcquisitionDefinition": {
      "properties": {
        "typeAcquisition": {
          "type": [
            "object",
            "null"
          ],
          "description": "Auto type (.d.ts) acquisition options for this project. Requires TypeScript version 2.1 or later.",
          "properties": {
            "enable": {
              "description": "Enable auto type acquisition",
              "type": [
                "boolean",
                "null"
              ],
              "default": false
            },
            "include": {
              "description": "Specifies a list of type declarations to be included in auto type acquisition. Ex. [\"jquery\", \"lodash\"]",
              "type": [
                "array",
                "null"
              ],
              "uniqueItems": true,
              "items": {
                "type": "string"
              }
            },
            "exclude": {
              "description": "Specifies a list of type declarations to be excluded from auto type acquisition. Ex. [\"jquery\", \"lodash\"]",
              "type": [
                "array",
                "null"
              ],
              "uniqueItems": true,
              "items": {
                "type": "string"
              }
            }
          }
        }
      }
    },
    "referencesDefinition": {
      "properties": {
        "references": {
          "type": "array",
          "uniqueItems": true,
          "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",
          "items": {
            "type": "object",
            "description": "Project reference.",
            "properties": {
              "path": {
                "type": "string",
                "description": "Path to referenced tsconfig or to folder containing tsconfig."
              }
            }
          },
          "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",
          "x-intellij-html-description": "<p>Referenced projects. Requires TypeScript version 3.0 or later.</p>\n<hr>\n<p>Project 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.</p>\n<p>You can read more about how references works in the <a href=\"https://typescriptlang.org/docs/handbook/project-references.html\">Project References</a> section of the handbook</p>\n"
        }
      }
    },
    "tsNodeModuleTypes": {
      "type": [
        "object",
        "null"
      ]
    },
    "tsNodeDefinition": {
      "properties": {
        "ts-node": {
          "description": "ts-node options.  See also: https://typestrong.org/ts-node/docs/configuration\n\nts-node offers TypeScript execution and REPL for node.js, with source map support.",
          "properties": {
            "compiler": {
              "default": "typescript",
              "description": "Specify a custom TypeScript compiler.",
              "type": [
                "string",
                "null"
              ]
            },
            "compilerHost": {
              "default": false,
              "description": "Use TypeScript's compiler host API instead of the language service API.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "compilerOptions": {
              "additionalProperties": true,
              "allOf": [
                {
                  "$ref": "#/definitions/compilerOptionsDefinition/properties/compilerOptions"
                }
              ],
              "description": "JSON object to merge with TypeScript `compilerOptions`.",
              "properties": {},
              "type": [
                "object",
                "null"
              ]
            },
            "emit": {
              "default": false,
              "description": "Emit output files into `.ts-node` directory.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "esm": {
              "description": "Enable native ESM support.\n\nFor details, see https://typestrong.org/ts-node/docs/imports#native-ecmascript-modules",
              "type": [
                "boolean",
                "null"
              ]
            },
            "experimentalReplAwait": {
              "description": "Allows the usage of top level await in REPL.\n\nUses node's implementation which accomplishes this with an AST syntax transformation.\n\nEnabled by default when tsconfig target is es2018 or above. Set to false to disable.\n\n**Note**: setting to `true` when tsconfig target is too low will throw an Error.  Leave as `undefined`\nto get default, automatic behavior.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "experimentalResolver": {
              "description": "Enable experimental features that re-map imports and require calls to support:\n`baseUrl`, `paths`, `rootDirs`, `.js` to `.ts` file extension mappings,\n`outDir` to `rootDir` mappings for composite projects and monorepos.\n\nFor details, see https://github.com/TypeStrong/ts-node/issues/1514",
              "type": [
                "boolean",
                "null"
              ]
            },
            "experimentalSpecifierResolution": {
              "description": "Like node's `--experimental-specifier-resolution`, , but can also be set in your `tsconfig.json` for convenience.\n\nFor details, see https://nodejs.org/dist/latest-v18.x/docs/api/esm.html#customizing-esm-specifier-resolution-algorithm",
              "enum": [
                "explicit",
                "node"
              ],
              "type": [
                "string",
                "null"
              ]
            },
            "files": {
              "default": false,
              "description": "Load \"files\" and \"include\" from `tsconfig.json` on startup.\n\nDefault is to override `tsconfig.json` \"files\" and \"include\" to only include the entrypoint script.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "ignore": {
              "default": [
                "(?:^|/)node_modules/"
              ],
              "description": "Paths which should not be compiled.\n\nEach string in the array is converted to a regular expression via `new RegExp()` and tested against source paths prior to compilation.\n\nSource paths are normalized to posix-style separators, relative to the directory containing `tsconfig.json` or to cwd if no `tsconfig.json` is loaded.\n\nDefault is to ignore all node_modules subdirectories.",
              "items": {
                "type": "string"
              },
              "type": [
                "array",
                "null"
              ]
            },
            "ignoreDiagnostics": {
              "description": "Ignore TypeScript warnings by diagnostic code.",
              "items": {
                "type": [
                  "string",
                  "number"
                ]
              },
              "type": [
                "array",
                "null"
              ]
            },
            "logError": {
              "default": false,
              "description": "Logs TypeScript errors to stderr instead of throwing exceptions.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "moduleTypes": {
              "$ref": "#/definitions/tsNodeModuleTypes",
              "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."
            },
            "preferTsExts": {
              "default": false,
              "description": "Re-order file extensions so that TypeScript imports are preferred.\n\nFor example, when both `index.js` and `index.ts` exist, enabling this option causes `require('./index')` to resolve to `index.ts` instead of `index.js`",
              "type": [
                "boolean",
                "null"
              ]
            },
            "pretty": {
              "default": false,
              "description": "Use pretty diagnostic formatter.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "require": {
              "description": "Modules to require, like node's `--require` flag.\n\nIf specified in `tsconfig.json`, the modules will be resolved relative to the `tsconfig.json` file.\n\nIf specified programmatically, each input string should be pre-resolved to an absolute path for\nbest results.",
              "items": {
                "type": "string"
              },
              "type": [
                "array",
                "null"
              ]
            },
            "scope": {
              "default": false,
              "description": "Scope compiler to files within `scopeDir`.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "scopeDir": {
              "default": "First of: `tsconfig.json` \"rootDir\" if specified, directory containing `tsconfig.json`, or cwd if no `tsconfig.json` is loaded.",
              "type": [
                "string",
                "null"
              ]
            },
            "skipIgnore": {
              "default": false,
              "description": "Skip ignore check, so that compilation will be attempted for all files with matching extensions.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "swc": {
              "description": "Transpile with swc instead of the TypeScript compiler, and skip typechecking.\n\nEquivalent to setting both `transpileOnly: true` and `transpiler: 'ts-node/transpilers/swc'`\n\nFor complete instructions: https://typestrong.org/ts-node/docs/transpilers",
              "type": [
                "boolean",
                "null"
              ]
            },
            "transpileOnly": {
              "default": false,
              "description": "Use TypeScript's faster `transpileModule`.",
              "type": [
                "boolean",
                "null"
              ]
            },
            "transpiler": {
              "anyOf": [
                {
                  "items": [
                    {
                      "type": [
                        "string",
                        "null"
                      ]
                    },
                    {
                      "additionalProperties": true,
                      "properties": {},
                      "type": [
                        "object",
                        "null"
                      ]
                    }
                  ],
                  "maxItems": 2,
                  "minItems": 2,
                  "type": [
                    "array",
                    "null"
                  ]
                },
                {
                  "type": [
                    "string",
                    "null"
                  ]
                }
              ],
              "description": "Specify a custom transpiler for use with transpileOnly"
            },
            "typeCheck": {
              "default": true,
              "description": "**DEPRECATED** Specify type-check is enabled (e.g. `transpileOnly == false`).",
              "type": [
                "boolean",
                "null"
              ]
            }
          },
          "type": [
            "object",
            "null"
          ]
        }
      }
    },
    "effectLanguageServicePluginDiagnosticSeverityDefinition": {
      "type": "object",
      "description": "Allows overriding the default severity for each Effect diagnostic across the project.",
      "additionalProperties": {
        "type": "string",
        "enum": [
          "off",
          "error",
          "warning",
          "message",
          "suggestion"
        ]
      },
      "properties": {
        "anyUnknownInErrorContext": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Detects 'any' or 'unknown' types in Effect error or requirements channels Default severity: off."
        },
        "asyncFunction": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when declaring async functions and suggests using Effect values and Effect.gen for async control flow Default severity: off."
        },
        "catchAllToMapError": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests using Effect.mapError instead of Effect.catchAll when the callback only wraps the error with Effect.fail Default severity: suggestion."
        },
        "catchUnfailableEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Warns when using error handling on Effects that never fail (error type is 'never') Default severity: suggestion."
        },
        "classSelfMismatch": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "error",
          "description": "Ensures Self type parameter matches the class name in Service/Tag/Schema classes Default severity: error."
        },
        "cryptoRandomUUID": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using crypto.randomUUID() outside Effect generators instead of the Effect Random module, which uses Effect-injected randomness rather than the crypto module behind the scenes Default severity: off."
        },
        "cryptoRandomUUIDInEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using crypto.randomUUID() inside Effect generators instead of the Effect Random module, which uses Effect-injected randomness rather than the crypto module behind the scenes Default severity: off."
        },
        "deterministicKeys": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Enforces deterministic naming for service/tag/error identifiers based on class names Default severity: off."
        },
        "duplicatePackage": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Detects when multiple versions of the same Effect package are loaded Default severity: warning."
        },
        "effectDoNotation": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Suggests using Effect.gen or Effect.fn instead of the Effect.Do notation helpers Default severity: off."
        },
        "effectFnIife": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Effect.fn or Effect.fnUntraced is called as an IIFE (Immediately Invoked Function Expression). Use Effect.gen instead. Default severity: warning."
        },
        "effectFnImplicitAny": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "error",
          "description": "Mirrors noImplicitAny for unannotated Effect.fn and Effect.fnUntraced callback parameters when no outer contextual function type exists Default severity: error."
        },
        "effectFnOpportunity": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests using Effect.fn for functions that returns an Effect Default severity: suggestion."
        },
        "effectGenUsesAdapter": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Warns when using the deprecated adapter parameter in Effect.gen Default severity: warning."
        },
        "effectInFailure": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Warns when an Effect is used inside an Effect failure channel Default severity: warning."
        },
        "effectInVoidSuccess": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Detects nested Effects in void success channels that may cause unexecuted effects Default severity: warning."
        },
        "effectMapFlatten": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests using Effect.flatMap instead of Effect.map followed by Effect.flatten in piping flows Default severity: suggestion."
        },
        "effectMapVoid": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests using Effect.asVoid instead of Effect.map(() => void 0), Effect.map(() => undefined), or Effect.map(() => {}) Default severity: suggestion."
        },
        "effectSucceedWithVoid": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests using Effect.void instead of Effect.succeed(undefined) or Effect.succeed(void 0) Default severity: suggestion."
        },
        "extendsNativeError": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when a class directly extends the native Error class Default severity: off."
        },
        "flatMapToMap": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests using Effect.map instead of Effect.flatMap when the callback only wraps its result with Effect.succeed Default severity: suggestion."
        },
        "floatingEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "error",
          "description": "Ensures Effects are yielded or assigned to variables, not left floating Default severity: error."
        },
        "genericEffectServices": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Prevents services with type parameters that cannot be discriminated at runtime Default severity: warning."
        },
        "globalConsole": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using console methods outside Effect generators instead of Effect.log/Logger Default severity: off."
        },
        "globalConsoleInEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using console methods inside Effect generators instead of Effect.log/Logger Default severity: off."
        },
        "globalDate": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using Date.now() or new Date() outside Effect generators instead of Clock/DateTime Default severity: off."
        },
        "globalDateInEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using Date.now() or new Date() inside Effect generators instead of Clock/DateTime Default severity: off."
        },
        "globalErrorInEffectCatch": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Warns when catch callbacks return global Error type instead of typed errors Default severity: warning."
        },
        "globalErrorInEffectFailure": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Warns when the global Error type is used in an Effect failure channel Default severity: warning."
        },
        "globalFetch": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using the global fetch function outside Effect generators instead of the Effect HTTP client Default severity: off."
        },
        "globalFetchInEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using the global fetch function inside Effect generators instead of the Effect HTTP client Default severity: off."
        },
        "globalRandom": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using Math.random() outside Effect generators instead of the Random service Default severity: off."
        },
        "globalRandomInEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using Math.random() inside Effect generators instead of the Random service Default severity: off."
        },
        "globalTimers": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using setTimeout/setInterval outside Effect generators instead of Effect.sleep/Schedule Default severity: off."
        },
        "globalTimersInEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using setTimeout/setInterval inside Effect generators instead of Effect.sleep/Schedule Default severity: off."
        },
        "importFromBarrel": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Suggests importing from specific module paths instead of barrel exports Default severity: off."
        },
        "instanceOfSchema": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Suggests using Schema.is instead of instanceof for Effect Schema types Default severity: off."
        },
        "layerMergeAllWithDependencies": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Detects interdependencies in Layer.mergeAll calls where one layer provides a service that another layer requires Default severity: warning."
        },
        "lazyPromiseInEffectSync": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Warns when Effect.sync lazily returns a Promise instead of using an async Effect constructor Default severity: warning."
        },
        "leakingRequirements": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Detects implementation services leaked in service methods Default severity: suggestion."
        },
        "missedPipeableOpportunity": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Enforces the use of pipeable style for nested function calls Default severity: off."
        },
        "missingEffectContext": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "error",
          "description": "Reports missing service requirements in Effect context channel Default severity: error."
        },
        "missingEffectError": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "error",
          "description": "Reports missing error types in Effect error channel Default severity: error."
        },
        "missingEffectServiceDependency": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Checks that Effect.Service dependencies satisfy all required layer inputs Default severity: off."
        },
        "missingLayerContext": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "error",
          "description": "Reports missing service requirements in Layer context channel Default severity: error."
        },
        "missingReturnYieldStar": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "error",
          "description": "Suggests using 'return yield*' for Effects with never success for better type narrowing Default severity: error."
        },
        "missingStarInYieldEffectGen": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "error",
          "description": "Enforces using 'yield*' instead of 'yield' when yielding Effects in generators Default severity: error."
        },
        "multipleEffectProvide": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Warns against chaining Effect.provide calls which can cause service lifecycle issues Default severity: warning."
        },
        "nestedEffectGenYield": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when yielding a nested bare Effect.gen inside an existing Effect generator context Default severity: off."
        },
        "newPromise": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when constructing promises with new Promise instead of using Effect APIs Default severity: off."
        },
        "nodeBuiltinImport": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when importing Node.js built-in modules that have Effect-native counterparts Default severity: off."
        },
        "nonObjectEffectServiceType": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "error",
          "description": "Ensures Effect.Service types are objects, not primitives Default severity: error."
        },
        "outdatedApi": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Detects usage of APIs that have been removed or renamed in Effect v4 Default severity: warning."
        },
        "outdatedEffectCodegen": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Detects when generated code is outdated and needs to be regenerated Default severity: warning."
        },
        "overriddenSchemaConstructor": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "error",
          "description": "Prevents overriding constructors in Schema classes which breaks decoding behavior Default severity: error."
        },
        "preferSchemaOverJson": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Suggests using Effect Schema for JSON operations instead of JSON.parse/JSON.stringify which may throw Default severity: off."
        },
        "processEnv": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when reading process.env outside Effect generators instead of using Effect Config Default severity: off."
        },
        "processEnvInEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when reading process.env inside Effect generators instead of using Effect Config Default severity: off."
        },
        "redundantSchemaTagIdentifier": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests removing redundant identifier argument when it equals the tag value in Schema.TaggedClass/TaggedError/TaggedRequest Default severity: suggestion."
        },
        "returnEffectInGen": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Warns when returning an Effect in a generator causes nested Effect<Effect<...>> Default severity: suggestion."
        },
        "runEffectInsideEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests using Runtime or Effect.run*With methods instead of Effect.run* inside Effect contexts Default severity: suggestion."
        },
        "schemaStructWithTag": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests using Schema.TaggedStruct instead of Schema.Struct with _tag field Default severity: suggestion."
        },
        "schemaSyncInEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests using Effect-based Schema methods instead of sync methods inside Effect generators Default severity: suggestion."
        },
        "schemaUnionOfLiterals": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Simplifies Schema.Union of multiple Schema.Literal calls into single Schema.Literal Default severity: off."
        },
        "scopeInLayerEffect": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Suggests using Layer.scoped instead of Layer.effect when Scope is in requirements Default severity: warning."
        },
        "serviceNotAsClass": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when Context.Service is used as a variable instead of a class declaration Default severity: off."
        },
        "strictBooleanExpressions": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Enforces boolean types in conditional expressions for type safety Default severity: off."
        },
        "strictEffectProvide": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Warns when using Effect.provide with layers outside of application entry points Default severity: off."
        },
        "tryCatchInEffectGen": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Discourages try/catch in Effect generators in favor of Effect error handling Default severity: suggestion."
        },
        "unknownInEffectCatch": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Warns when catch callbacks return unknown instead of typed errors Default severity: warning."
        },
        "unnecessaryArrowBlock": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Suggests using a concise arrow body when the block only returns an expression Default severity: off."
        },
        "unnecessaryEffectGen": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests removing Effect.gen when it contains only a single return statement Default severity: suggestion."
        },
        "unnecessaryFailYieldableError": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Suggests yielding yieldable errors directly instead of wrapping with Effect.fail Default severity: suggestion."
        },
        "unnecessaryPipe": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Removes pipe calls with no arguments Default severity: suggestion."
        },
        "unnecessaryPipeChain": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "suggestion",
          "description": "Simplifies chained pipe calls into a single pipe call Default severity: suggestion."
        },
        "unsafeEffectTypeAssertion": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "off",
          "description": "Detects unsafe type assertions that narrow Effect, Stream, or Layer error or requirements channels Default severity: off."
        },
        "unsupportedServiceAccessors": {
          "type": "string",
          "enum": [
            "off",
            "error",
            "warning",
            "message",
            "suggestion"
          ],
          "default": "warning",
          "description": "Warns about service accessors that need codegen due to generic/complex signatures Default severity: warning."
        }
      }
    }
  },
  "id": "https://json.schemastore.org/tsconfig",
  "title": "JSON schema for the TypeScript compiler's configuration file",
  "type": "object"
}