diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index f70a8adbc90..cd6ff8c425a 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -25,5 +25,5 @@ repos: args: [ '--ignore-words-list', - 'crate,ninjs,ans,specif,seh,specifid,deriver,isnt,tye,forin,dependees,rouge,interm,fo,wast,nome,statics,ue,aack,gost,inout,provId,handels,bu,testng,ags,edn,aks,te,decorder,provid,branche,alse,nd,mape,wil,clude,wit,flate,omlet,THIRDPARTY,NotIn,notIn,CopyIn,Requestor,requestor,re-use,ofo,abl,dout,foto,vor,wel,NAM,BRIN,everyTime,afterAll,beforeAll,ontainer', + 'crate,ninjs,ans,specif,seh,specifid,deriver,isnt,tye,forin,dependees,rouge,interm,fo,wast,nome,statics,ue,aack,gost,inout,provId,handels,bu,testng,ags,edn,aks,te,decorder,provid,branche,alse,nd,mape,wil,clude,wit,flate,omlet,THIRDPARTY,NotIn,notIn,CopyIn,Requestor,requestor,re-use,ofo,abl,dout,foto,vor,wel,NAM,BRIN,everyTime,afterAll,beforeAll,ontainer,mis-match', ] diff --git a/src/api/json/catalog.json b/src/api/json/catalog.json index 476b3a5180e..03cfa399ef3 100644 --- a/src/api/json/catalog.json +++ b/src/api/json/catalog.json @@ -715,6 +715,12 @@ "fileMatch": ["buf.plugin.yaml"], "url": "https://www.schemastore.org/buf.plugin.json" }, + { + "name": "buf.policy.yaml", + "description": "buf.policy.yaml defines a policy containing lint, breaking change detection, and plugin configuration that can be shared across BSR modules", + "fileMatch": ["buf.policy.yaml"], + "url": "https://www.schemastore.org/buf.policy.json" + }, { "name": "buf.work.yaml", "description": "buf.work.yaml is used to define a workspace, which is an advanced local development feature. Workspaces make it possible to consolidate one or more modules into a single buildable unit. They also allow users to run buf operations across multiple modules with a single execution (such as buf lint)", @@ -9619,6 +9625,18 @@ "description": "Configuration file for Qwen Code", "fileMatch": ["**/.qwen/settings.json"], "url": "https://www.schemastore.org/qwen-code-settings.json" + }, + { + "name": "Raid Profile", + "description": "Definition for one or more Raid Profiles", + "fileMatch": ["*.raid.yaml", "*.raid.yml", "*.raid.json"], + "url": "https://raw.githubusercontent.com/8bitAlex/raid/main/schemas/raid-profile.schema.json" + }, + { + "name": "Raid Repo Configuration", + "description": "Definition for a single repository", + "fileMatch": ["raid.yaml", "raid.yml", "raid.json"], + "url": "https://raw.githubusercontent.com/8bitAlex/raid/main/schemas/raid-repo.schema.json" } ] } diff --git a/src/negative_test/buf.gen/buf.gen.v1.unknown-top-level-key.yaml b/src/negative_test/buf.gen/buf.gen.v1.unknown-top-level-key.yaml new file mode 100644 index 00000000000..73364c87111 --- /dev/null +++ b/src/negative_test/buf.gen/buf.gen.v1.unknown-top-level-key.yaml @@ -0,0 +1,6 @@ +# yaml-language-server: $schema=../../schemas/json/buf.gen.json +version: v1 +plugins: + - plugin: go + out: gen/go +blargh: whatever diff --git a/src/negative_test/buf.gen/buf.gen.v2.unknown-top-level-key.yaml b/src/negative_test/buf.gen/buf.gen.v2.unknown-top-level-key.yaml new file mode 100644 index 00000000000..d05cb1f46dd --- /dev/null +++ b/src/negative_test/buf.gen/buf.gen.v2.unknown-top-level-key.yaml @@ -0,0 +1,6 @@ +# yaml-language-server: $schema=../../schemas/json/buf.gen.json +version: v2 +plugins: + - local: go + out: gen/go +blargh: whatever diff --git a/src/negative_test/buf.policy/buf.policy.unknown-top-level-key.yaml b/src/negative_test/buf.policy/buf.policy.unknown-top-level-key.yaml new file mode 100644 index 00000000000..673d45d6899 --- /dev/null +++ b/src/negative_test/buf.policy/buf.policy.unknown-top-level-key.yaml @@ -0,0 +1,3 @@ +# yaml-language-server: $schema=../../schemas/json/buf.policy.json +version: v2 +blargh: whatever diff --git a/src/negative_test/buf.policy/buf.policy.wrong-version.yaml b/src/negative_test/buf.policy/buf.policy.wrong-version.yaml new file mode 100644 index 00000000000..edce08bf4e1 --- /dev/null +++ b/src/negative_test/buf.policy/buf.policy.wrong-version.yaml @@ -0,0 +1,5 @@ +# yaml-language-server: $schema=../../schemas/json/buf.policy.json +version: v1 +lint: + use: + - STANDARD diff --git a/src/negative_test/buf.work/buf.work.unknown-top-level-key.yaml b/src/negative_test/buf.work/buf.work.unknown-top-level-key.yaml new file mode 100644 index 00000000000..d08877bf606 --- /dev/null +++ b/src/negative_test/buf.work/buf.work.unknown-top-level-key.yaml @@ -0,0 +1,5 @@ +# yaml-language-server: $schema=../../schemas/json/buf.work.json +version: v1 +directories: + - proto +blargh: whatever diff --git a/src/negative_test/buf/buf.unknown-top-level-key.yaml b/src/negative_test/buf/buf.unknown-top-level-key.yaml new file mode 100644 index 00000000000..1eac6b52855 --- /dev/null +++ b/src/negative_test/buf/buf.unknown-top-level-key.yaml @@ -0,0 +1,3 @@ +# yaml-language-server: $schema=../../schemas/json/buf.json +version: v1 +blargh: whatever diff --git a/src/negative_test/buf/buf.v2.unknown-top-level-key.yaml b/src/negative_test/buf/buf.v2.unknown-top-level-key.yaml new file mode 100644 index 00000000000..5bdcce77e74 --- /dev/null +++ b/src/negative_test/buf/buf.v2.unknown-top-level-key.yaml @@ -0,0 +1,3 @@ +# yaml-language-server: $schema=../../schemas/json/buf.json +version: v2 +blargh: whatever diff --git a/src/schemas/json/buf.gen.json b/src/schemas/json/buf.gen.json index b38c0d7778a..ad2892b73f0 100644 --- a/src/schemas/json/buf.gen.json +++ b/src/schemas/json/buf.gen.json @@ -50,13 +50,15 @@ "if": { "properties": { "version": { - "const": "v1" + "enum": ["v1", "v1beta1"] } } }, "then": { "required": ["version", "plugins"], + "additionalProperties": false, "properties": { + "version": {}, "plugins": { "$comment": "https://buf.build/docs/configuration/v1/buf-gen-yaml#plugins", "description": "Required. Each entry in the plugins key is a protoc plugin configuration. Plugins are invoked in parallel and their outputs are written in the order you specify here.", @@ -265,7 +267,7 @@ "additionalProperties": false, "properties": { "default": { - "description": "Optional. Overrides managed mode's default value for the class prefix.", + "description": "Required if the objc_class_prefix key is set. Overrides managed mode's default value for the class prefix.", "type": "string" }, "except": { @@ -391,7 +393,10 @@ }, "else": { "$comment": "v2 properties", + "required": ["version", "plugins"], + "additionalProperties": false, "properties": { + "version": {}, "clean": { "$comment": "https://buf.build/docs/configuration/v2/buf-gen-yaml#clean", "description": "Optional. When set to true, buf generate deletes all directories, zip files, and/or jar files specified by the out field for each plugin before running code generation.", @@ -576,7 +581,7 @@ { "type": "object", "additionalProperties": false, - "minProperties": 1, + "required": ["directory"], "properties": { "types": { "$ref": "#/$defs/types" @@ -599,7 +604,7 @@ { "type": "object", "additionalProperties": false, - "minProperties": 1, + "required": ["module"], "properties": { "types": { "$ref": "#/$defs/types" @@ -627,7 +632,7 @@ { "type": "object", "additionalProperties": false, - "minProperties": 1, + "required": ["git_repo"], "properties": { "types": { "$ref": "#/$defs/types" @@ -675,7 +680,7 @@ { "type": "object", "additionalProperties": false, - "minProperties": 1, + "required": ["tarball"], "properties": { "types": { "$ref": "#/$defs/types" @@ -711,7 +716,7 @@ { "type": "object", "additionalProperties": false, - "minProperties": 1, + "required": ["zip_archive"], "properties": { "types": { "$ref": "#/$defs/types" @@ -742,7 +747,7 @@ { "type": "object", "additionalProperties": false, - "minProperties": 1, + "required": ["proto_file"], "properties": { "types": { "type": "array", @@ -785,7 +790,7 @@ { "type": "object", "additionalProperties": false, - "minProperties": 1, + "required": ["binary_image"], "properties": { "types": { "$ref": "#/$defs/types" @@ -813,7 +818,7 @@ { "type": "object", "additionalProperties": false, - "minProperties": 1, + "required": ["json_image"], "properties": { "types": { "$ref": "#/$defs/types" @@ -841,7 +846,7 @@ { "type": "object", "additionalProperties": false, - "minProperties": 1, + "required": ["yaml_image"], "properties": { "types": { "$ref": "#/$defs/types" @@ -869,7 +874,7 @@ { "type": "object", "additionalProperties": false, - "minProperties": 1, + "required": ["txt_image"], "properties": { "types": { "$ref": "#/$defs/types" diff --git a/src/schemas/json/buf.json b/src/schemas/json/buf.json index 68904aabbcc..f2cbd07397b 100644 --- a/src/schemas/json/buf.json +++ b/src/schemas/json/buf.json @@ -908,7 +908,6 @@ "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#lint", "description": "Optional. The lint settings you specify in this section are the default for all modules in the workspace, but can be replaced for individual modules by specifying different settings at the module level. Module-level settings have all of the same fields and behavior as workspace-level settings. If no lint settings are specified for the workspace, it uses the default settings.", "type": "object", - "additionalProperties": false, "properties": { "use": { "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#use", @@ -969,6 +968,12 @@ "description": "Optional. Controls the behavior of the SERVICE_SUFFIX lint rule. By default, this rule verifies that all service names are suffixed with Service.", "type": "string", "default": "Service" + }, + "disable_builtin": { + "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#disable_builtin", + "description": "Optional. Disables Buf's built-in lint rules when set to true. Defaults to false.", + "type": "boolean", + "default": false } } }, @@ -976,7 +981,6 @@ "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#breaking", "description": "Optional. Specifies the breaking change detection rules enforced on the Protobuf files in the directory.", "type": "object", - "additionalProperties": false, "properties": { "use": { "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#use-1", @@ -1010,6 +1014,12 @@ "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#ignore_unstable_packages", "description": "Optional. Ignores packages with a last component that's one of the unstable forms recognized by the Buf linter's PACKAGE_VERSION_SUFFIX rule.", "type": "boolean" + }, + "disable_builtin": { + "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#disable_builtin-1", + "description": "Optional. Disables Buf's built-in breaking change detection rules when set to true. Defaults to false.", + "type": "boolean", + "default": false } } } @@ -1028,12 +1038,14 @@ "if": { "properties": { "version": { - "const": "v1" + "enum": ["v1", "v1beta1"] } } }, "then": { + "additionalProperties": false, "properties": { + "version": {}, "name": { "$comment": "https://buf.build/docs/configuration/v1/buf-yaml#name", "description": "The name is optional, and uniquely identifies your module. The name must be a valid module name and is directly associated with the repository that owns it.", @@ -1177,14 +1189,15 @@ }, "else": { "$comment": "v2 properties", + "additionalProperties": false, "properties": { + "version": {}, "modules": { "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#modules", "description": "Required. Defines the list of modules that will be built together in this workspace. Any dependencies that the files have on each other are automatically taken into account when building and shouldn't be declared in the deps section.", "type": "array", "items": { "type": "object", - "additionalProperties": false, "properties": { "path": { "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#path", @@ -1234,6 +1247,62 @@ }, "breaking": { "$ref": "#/$defs/v2-breaking" + }, + "plugins": { + "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#plugins", + "description": "Optional. Custom lint or breaking change rule plugins applied across all modules in the workspace.", + "type": "array", + "items": { + "type": "object", + "required": ["plugin"], + "properties": { + "plugin": { + "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#plugin", + "description": "Required. Path to a plugin binary or remote BSR plugin reference.", + "type": "string" + }, + "options": { + "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#options", + "description": "Optional. Key-value configuration pairs for plugin customization.", + "type": "object" + } + } + } + }, + "policies": { + "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#policies", + "description": "Optional. YAML-based rule sets shareable across workspaces. Each entry references a local buf.policy.yaml file or a remote BSR policy.", + "type": "array", + "items": { + "type": "object", + "required": ["policy"], + "properties": { + "policy": { + "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#policy", + "description": "Required. Local file path or BSR policy reference.", + "type": "string" + }, + "ignore": { + "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#ignore-2", + "description": "Optional. Files or directories excluded from all rules in this policy. Paths must be relative to the buf.yaml file.", + "type": "array", + "items": { + "type": "string" + } + }, + "ignore_only": { + "$comment": "https://buf.build/docs/configuration/v2/buf-yaml#ignore_only-2", + "description": "Optional. Excludes specific policy rules for certain paths. Keys are rule IDs; values are arrays of paths relative to the buf.yaml file.", + "type": "object", + "additionalProperties": { + "type": "array", + "items": { + "type": "string" + } + } + } + } + } } } } diff --git a/src/schemas/json/buf.lock.json b/src/schemas/json/buf.lock.json index 2ad283cc63c..0d068258a67 100644 --- a/src/schemas/json/buf.lock.json +++ b/src/schemas/json/buf.lock.json @@ -12,37 +12,92 @@ "description": "Buf configuration version.", "type": "string", "enum": ["v2", "v1", "v1beta1"] - }, - "deps": { - "description": "Module pins, each uniquely representing a specific snapshot of a module, protected with a cryptographic digest.", - "type": "array", - "items": { - "type": "object", - "required": ["name", "commit", "digest"], - "additionalProperties": false, - "properties": { - "name": { - "description": "Module name.", - "type": "string", - "pattern": "^[a-z0-9.-]+/[a-z0-9-]+/[a-z0-9-]+$", - "examples": [ - "buf.build/googleapis/googleapis", - "buf.build/grpc/grpc" - ] - }, - "commit": { - "description": "Commit that uniquely identifies this snapshot of the module.", - "type": "string", - "pattern": "^[a-f0-9]{32}$", - "examples": ["7a6bc1e3207144b38e9066861e1de0ff"] - }, - "digest": { - "description": "Digest of the module contents.", - "type": "string", - "pattern": "^b[0-9]+:[a-f0-9]+$", - "examples": [ - "b5:6d05bde5ed4cd22531d7ca6467feb828d2dc45cc9de12ce3345fbddd64ddb1bf0db756558c32ca49e6bc7de4426ada8960d5590e8446854b81f5f36f0916dc48" - ] + } + }, + "if": { + "properties": { + "version": { + "enum": ["v1", "v1beta1"] + } + } + }, + "then": { + "properties": { + "deps": { + "description": "Module pins, each uniquely representing a specific snapshot of a module.", + "type": "array", + "items": { + "type": "object", + "properties": { + "remote": { + "description": "Remote registry hostname.", + "type": "string" + }, + "owner": { + "description": "Owner of the module.", + "type": "string" + }, + "repository": { + "description": "Repository name.", + "type": "string" + }, + "branch": { + "description": "Deprecated. Branch of the module.", + "type": "string", + "deprecated": true + }, + "commit": { + "description": "Commit that uniquely identifies this snapshot of the module.", + "type": "string", + "pattern": "^[a-f0-9]{32}$" + }, + "digest": { + "description": "Digest of the module contents.", + "type": "string" + }, + "create_time": { + "description": "Deprecated. Creation timestamp.", + "type": "string", + "deprecated": true + } + } + } + } + } + }, + "else": { + "properties": { + "deps": { + "description": "Module pins, each uniquely representing a specific snapshot of a module, protected with a cryptographic digest.", + "type": "array", + "items": { + "type": "object", + "required": ["name", "commit", "digest"], + "additionalProperties": false, + "properties": { + "name": { + "description": "Module name.", + "type": "string", + "pattern": "^[a-z0-9.-]+/[a-z0-9-]+/[a-z0-9-]+$", + "examples": [ + "buf.build/googleapis/googleapis", + "buf.build/grpc/grpc" + ] + }, + "commit": { + "description": "Commit that uniquely identifies this snapshot of the module.", + "type": "string", + "pattern": "^[a-f0-9]{32}$", + "examples": ["7a6bc1e3207144b38e9066861e1de0ff"] + }, + "digest": { + "description": "Digest of the module contents.", + "type": "string", + "pattern": "^b[0-9]+:[a-f0-9]+$", + "examples": [ + "b5:6d05bde5ed4cd22531d7ca6467feb828d2dc45cc9de12ce3345fbddd64ddb1bf0db756558c32ca49e6bc7de4426ada8960d5590e8446854b81f5f36f0916dc48" + ] + } } } } diff --git a/src/schemas/json/buf.plugin.json b/src/schemas/json/buf.plugin.json index 0381ae94199..b0b9eb369f6 100644 --- a/src/schemas/json/buf.plugin.json +++ b/src/schemas/json/buf.plugin.json @@ -17,7 +17,11 @@ "type": "string" }, "plugin_version": { - "description": "The plugin version with format`v{semver}`, the `v` prefix is required and the version must be valid [semantic versioning](https://semver.org/).", + "description": "The plugin version with format `v{semver}`, the `v` prefix is required and the version must be valid [semantic versioning](https://semver.org/).", + "type": "string" + }, + "license_url": { + "description": "URL to the license of the plugin source code.", "type": "string" }, "source_url": { diff --git a/src/schemas/json/buf.policy.json b/src/schemas/json/buf.policy.json new file mode 100644 index 00000000000..cd70c9906dd --- /dev/null +++ b/src/schemas/json/buf.policy.json @@ -0,0 +1,278 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "$id": "https://json.schemastore.org/buf.policy.json", + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml", + "$defs": { + "lint-rule": { + "type": "string", + "description": "https://buf.build/docs/lint/rules", + "examples": [ + "STANDARD", + "DEFAULT", + "BASIC", + "MINIMAL", + "COMMENTS", + "UNARY_RPC", + "DIRECTORY_SAME_PACKAGE", + "PACKAGE_DEFINED", + "PACKAGE_DIRECTORY_MATCH", + "PACKAGE_SAME_DIRECTORY", + "ENUM_PASCAL_CASE", + "ENUM_VALUE_UPPER_SNAKE_CASE", + "FIELD_LOWER_SNAKE_CASE", + "MESSAGE_PASCAL_CASE", + "ONEOF_LOWER_SNAKE_CASE", + "PACKAGE_LOWER_SNAKE_CASE", + "RPC_PASCAL_CASE", + "SERVICE_PASCAL_CASE", + "PACKAGE_SAME_CSHARP_NAMESPACE", + "PACKAGE_SAME_GO_PACKAGE", + "PACKAGE_SAME_JAVA_MULTIPLE_FILES", + "PACKAGE_SAME_JAVA_PACKAGE", + "PACKAGE_SAME_PHP_NAMESPACE", + "PACKAGE_SAME_RUBY_PACKAGE", + "PACKAGE_SAME_SWIFT_PREFIX", + "ENUM_FIRST_VALUE_ZERO", + "ENUM_NO_ALLOW_ALIAS", + "IMPORT_NO_WEAK", + "IMPORT_NO_PUBLIC", + "IMPORT_USED", + "ENUM_VALUE_PREFIX", + "ENUM_ZERO_VALUE_SUFFIX", + "FIELD_NOT_REQUIRED", + "FILE_LOWER_SNAKE_CASE", + "RPC_REQUEST_RESPONSE_UNIQUE", + "RPC_REQUEST_STANDARD_NAME", + "RPC_RESPONSE_STANDARD_NAME", + "PACKAGE_VERSION_SUFFIX", + "PROTOVALIDATE", + "SERVICE_SUFFIX", + "COMMENT_ENUM", + "COMMENT_ENUM_VALUE", + "COMMENT_FIELD", + "COMMENT_MESSAGE", + "COMMENT_ONEOF", + "COMMENT_RPC", + "COMMENT_SERVICE", + "RPC_NO_CLIENT_STREAMING", + "RPC_NO_SERVER_STREAMING", + "PACKAGE_NO_IMPORT_CYCLE", + "SYNTAX_SPECIFIED", + "STABLE_PACKAGE_NO_IMPORT_UNSTABLE" + ] + }, + "breaking-rule": { + "type": "string", + "description": "https://buf.build/docs/breaking/rules", + "examples": [ + "FILE", + "PACKAGE", + "WIRE_JSON", + "WIRE", + "ENUM_NO_DELETE", + "ENUM_SAME_JSON_FORMAT", + "ENUM_SAME_TYPE", + "ENUM_VALUE_NO_DELETE", + "ENUM_VALUE_NO_DELETE_UNLESS_NAME_RESERVED", + "ENUM_VALUE_NO_DELETE_UNLESS_NUMBER_RESERVED", + "ENUM_VALUE_SAME_NAME", + "EXTENSION_MESSAGE_NO_DELETE", + "EXTENSION_NO_DELETE", + "FIELD_NO_DELETE", + "FIELD_NO_DELETE_UNLESS_NAME_RESERVED", + "FIELD_NO_DELETE_UNLESS_NUMBER_RESERVED", + "FIELD_SAME_CARDINALITY", + "FIELD_SAME_CPP_STRING_TYPE", + "FIELD_SAME_CTYPE", + "FIELD_SAME_DEFAULT", + "FIELD_SAME_JAVA_UTF8_VALIDATION", + "FIELD_SAME_JSON_NAME", + "FIELD_SAME_JSTYPE", + "FIELD_SAME_LABEL", + "FIELD_SAME_NAME", + "FIELD_SAME_ONEOF", + "FIELD_SAME_TYPE", + "FIELD_SAME_UTF8_VALIDATION", + "FIELD_WIRE_COMPATIBLE_CARDINALITY", + "FIELD_WIRE_COMPATIBLE_TYPE", + "FIELD_WIRE_JSON_COMPATIBLE_CARDINALITY", + "FIELD_WIRE_JSON_COMPATIBLE_TYPE", + "FILE_NO_DELETE", + "FILE_SAME_CC_ENABLE_ARENAS", + "FILE_SAME_CC_GENERIC_SERVICES", + "FILE_SAME_CSHARP_NAMESPACE", + "FILE_SAME_GO_PACKAGE", + "FILE_SAME_JAVA_GENERIC_SERVICES", + "FILE_SAME_JAVA_MULTIPLE_FILES", + "FILE_SAME_JAVA_OUTER_CLASSNAME", + "FILE_SAME_JAVA_PACKAGE", + "FILE_SAME_JAVA_STRING_CHECK_UTF8", + "FILE_SAME_OBJC_CLASS_PREFIX", + "FILE_SAME_OPTIMIZE_FOR", + "FILE_SAME_PACKAGE", + "FILE_SAME_PHP_CLASS_PREFIX", + "FILE_SAME_PHP_GENERIC_SERVICES", + "FILE_SAME_PHP_METADATA_NAMESPACE", + "FILE_SAME_PHP_NAMESPACE", + "FILE_SAME_PY_GENERIC_SERVICES", + "FILE_SAME_RUBY_PACKAGE", + "FILE_SAME_SWIFT_PREFIX", + "FILE_SAME_SYNTAX", + "MESSAGE_NO_DELETE", + "MESSAGE_NO_REMOVE_STANDARD_DESCRIPTOR_ACCESSOR", + "MESSAGE_SAME_JSON_FORMAT", + "MESSAGE_SAME_MESSAGE_SET_WIRE_FORMAT", + "MESSAGE_SAME_REQUIRED_FIELDS", + "ONEOF_NO_DELETE", + "PACKAGE_ENUM_NO_DELETE", + "PACKAGE_EXTENSION_NO_DELETE", + "PACKAGE_MESSAGE_NO_DELETE", + "PACKAGE_NO_DELETE", + "PACKAGE_SERVICE_NO_DELETE", + "RESERVED_ENUM_NO_DELETE", + "RESERVED_MESSAGE_NO_DELETE", + "RPC_NO_DELETE", + "RPC_SAME_CLIENT_STREAMING", + "RPC_SAME_IDEMPOTENCY_LEVEL", + "RPC_SAME_REQUEST_TYPE", + "RPC_SAME_RESPONSE_TYPE", + "RPC_SAME_SERVER_STREAMING", + "SERVICE_NO_DELETE" + ] + } + }, + "title": "buf.policy.yaml", + "description": "buf.policy.yaml defines a policy containing a subset of Buf configuration focused on lint, breaking change detection, and plugins. Policies can be shared across modules in the Buf Schema Registry.", + "type": "object", + "required": ["version"], + "additionalProperties": false, + "properties": { + "version": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#version", + "description": "Required. The version key defines the current configuration version. The only accepted value is v2.", + "type": "string", + "const": "v2" + }, + "name": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#name", + "description": "Optional. A BSR path that uniquely identifies this policy. Must be a valid policy name in the format buf.build/ORGANIZATION/POLICY_NAME.", + "type": "string" + }, + "lint": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#lint", + "description": "Optional. The lint settings for this policy.", + "type": "object", + "additionalProperties": false, + "properties": { + "use": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#use", + "description": "Optional. Lists the categories and/or specific rules to use. The STANDARD category is used if lint is unset.", + "type": "array", + "default": ["STANDARD"], + "items": { + "$ref": "#/$defs/lint-rule" + } + }, + "except": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#except", + "description": "Optional. Removes rules or categories from the use list.", + "type": "array", + "items": { + "$ref": "#/$defs/lint-rule" + } + }, + "enum_zero_value_suffix": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#enum_zero_value_suffix", + "description": "Optional. Controls the behavior of the ENUM_ZERO_VALUE_SUFFIX lint rule. By default, this rule verifies that the zero value of all enums ends in _UNSPECIFIED.", + "type": "string", + "default": "_UNSPECIFIED" + }, + "rpc_allow_same_request_response": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#rpc_allow_same_request_response", + "description": "Optional. Allows the same message type to be used for a single RPC's request and response type. We don't recommend using this option.", + "type": "boolean" + }, + "rpc_allow_google_protobuf_empty_requests": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#rpc_allow_google_protobuf_empty_requests", + "description": "Optional. Allows RPC requests to be google.protobuf.Empty messages. We don't recommend using this option.", + "type": "boolean" + }, + "rpc_allow_google_protobuf_empty_responses": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#rpc_allow_google_protobuf_empty_responses", + "description": "Optional. Allows RPC responses to be google.protobuf.Empty messages. We don't recommend using this option.", + "type": "boolean" + }, + "service_suffix": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#service_suffix", + "description": "Optional. Controls the behavior of the SERVICE_SUFFIX lint rule. By default, this rule verifies that all service names are suffixed with Service.", + "type": "string", + "default": "Service" + }, + "disable_builtin": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#disable_builtin", + "description": "Optional. Disables Buf's built-in lint rules when set to true. Defaults to false.", + "type": "boolean", + "default": false + } + } + }, + "breaking": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#breaking", + "description": "Optional. The breaking change detection settings for this policy.", + "type": "object", + "additionalProperties": false, + "properties": { + "use": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#use-1", + "description": "Optional. Lists the rules or categories to use for breaking change detection. The FILE category is used if breaking is unset.", + "type": "array", + "default": ["FILE"], + "items": { + "$ref": "#/$defs/breaking-rule" + } + }, + "except": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#except-1", + "description": "Optional. Removes rules or categories from the use list. We don't recommend using this option.", + "type": "array", + "items": { + "$ref": "#/$defs/breaking-rule" + } + }, + "ignore_unstable_packages": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#ignore_unstable_packages", + "description": "Optional. Ignores packages with a last component that's one of the unstable forms recognized by the Buf linter's PACKAGE_VERSION_SUFFIX rule.", + "type": "boolean" + }, + "disable_builtin": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#disable_builtin-1", + "description": "Optional. Disables Buf's built-in breaking change detection rules when set to true. Defaults to false.", + "type": "boolean", + "default": false + } + } + }, + "plugins": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#plugins", + "description": "Optional. Custom Buf plugins that provide additional lint or breaking change rules.", + "type": "array", + "items": { + "type": "object", + "required": ["plugin"], + "additionalProperties": false, + "properties": { + "plugin": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#plugin", + "description": "Required. References a Buf plugin via local binary path, filesystem location, or remote BSR plugin path.", + "type": "string" + }, + "options": { + "$comment": "https://buf.build/docs/configuration/v2/buf-policy-yaml#options", + "description": "Optional. Key-value configuration pairs for plugin customization.", + "type": "object" + } + } + } + } + } +} diff --git a/src/schemas/json/buf.work.json b/src/schemas/json/buf.work.json index 4b5c8423047..a6a1634a3d2 100644 --- a/src/schemas/json/buf.work.json +++ b/src/schemas/json/buf.work.json @@ -5,6 +5,7 @@ "title": "buf.work.yaml", "description": "buf.work.yaml is used to define a workspace, which is an advanced local development feature. Workspaces make it possible to consolidate one or more modules into a single buildable unit. They also allow users to run buf operations across multiple modules with a single execution (such as buf lint).", "type": "object", + "additionalProperties": false, "properties": { "version": { "description": "Required. Defines the current configuration version. The only accepted value is v1.", diff --git a/src/schemas/json/drupal-recipe.json b/src/schemas/json/drupal-recipe.json index eb652f0b7f3..2d2b1865f08 100644 --- a/src/schemas/json/drupal-recipe.json +++ b/src/schemas/json/drupal-recipe.json @@ -48,6 +48,73 @@ }, "actionsList": { "generic": { + "hideComponent": { + "type": "string", + "title": "Hides a component from an entity view display or entity form display.", + "description": "Value: The component id", + "default": "uid" + }, + "hideComponents": { + "type": "array", + "description": "Value: The list of component ids", + "items": [ + { + "type": "string" + } + ] + }, + "setComponent": { + "type": "object", + "description": "Allows adding a field to an entity's view or form displays.", + "properties": { + "name": { + "description": "The field id. i.e. field_tags", + "type": "string" + }, + "options": { + "type": "object", + "properties": { + "type": { + "description": "The field type. i.e. entity_reference_label", + "type": "string" + }, + "label": { + "description": "Label position. i.e. above", + "type": "string", + "enum": ["above", "below", "hidden", "inline"] + }, + "settings": { + "type": "object", + "properties": { + "link": { + "type": "boolean" + } + } + }, + "third_party_settings": { + "type": "object" + }, + "weight": { + "type": "number" + }, + "region": { + "$ref": "#/$defs/theme/defaultRegions", + "type": "string" + } + } + } + }, + "additionalProperties": false + }, + "setComponents": { + "type": "array", + "description": "Allows adding adding the configuration for multiple fields.", + "items": [ + { + "$ref": "#/$defs/actionsList/generic/setComponent" + } + ] + }, "cloneAs": { "description": "Creates a clone of any config entity with a new ID.", "type": "string" @@ -222,75 +289,20 @@ "core.entity_form_display.*.*.*": { "$comment": "", "type": "object", - "title": "Form/View display", + "title": "Form display", "description": "", "properties": { "hideComponent": { - "type": "string", - "title": "Hides a component from an entity view display or entity form display.", - "description": "Value: The component id", - "default": "uid" + "$ref": "#/$defs/actionsList/generic/hideComponent" }, "hideComponents": { - "type": "array", - "description": "Value: The list of component ids", - "items": [ - { - "type": "string" - } - ] + "$ref": "#/$defs/actionsList/generic/hideComponents" }, "setComponent": { - "type": "object", - "description": "Allows adding a field to an entity's view or form displays.", - "properties": { - "name": { - "description": "The field id. i.e. field_tags", - "type": "string" - }, - "options": { - "type": "object", - "properties": { - "type": { - "description": "The field type. i.e. entity_reference_label", - "type": "string" - }, - "label": { - "description": "Label position. i.e. above", - "type": "string", - "enum": ["above", "below", "hidden", "inline"] - }, - "settings": { - "type": "object", - "properties": { - "link": { - "type": "boolean" - } - } - }, - "third_party_settings": { - "type": "object" - }, - "weight": { - "type": "number" - }, - "region": { - "$ref": "#/$defs/theme/defaultRegions", - "type": "string" - } - } - } - }, - "additionalProperties": false + "$ref": "#/$defs/actionsList/generic/setComponent" }, "setComponents": { - "type": "array", - "description": "Allows adding adding the configuration for multiple fields.", - "items": [ - { - "$ref": "#/$defs/actionsList/specific/core.entity_form_display.*.*.*/properties/setComponent" - } - ] + "$ref": "#/$defs/actionsList/generic/setComponents" }, "cloneAs": { "$ref": "#/$defs/actionsList/generic/cloneAs" @@ -326,7 +338,59 @@ "additionalProperties": false }, "core.entity_view_display.*.*.*": { - "$ref": "#/$defs/actionsList/specific/core.entity_form_display.*.*.*" + "$comment": "", + "type": "object", + "title": "Form display", + "description": "", + "properties": { + "allowLayoutOverrides": { + "type": "boolean", + "title": "Sets whether layout builder overrides are allowed." + }, + "hideComponent": { + "$ref": "#/$defs/actionsList/generic/hideComponent" + }, + "hideComponents": { + "$ref": "#/$defs/actionsList/generic/hideComponents" + }, + "setComponent": { + "$ref": "#/$defs/actionsList/generic/setComponent" + }, + "setComponents": { + "$ref": "#/$defs/actionsList/generic/setComponents" + }, + "cloneAs": { + "$ref": "#/$defs/actionsList/generic/cloneAs" + }, + "create": { + "$ref": "#/$defs/actionsList/generic/create" + }, + "createIfNotExists": { + "$ref": "#/$defs/actionsList/generic/createIfNotExists" + }, + "createForEach": { + "$ref": "#/$defs/actionsList/generic/createForEach" + }, + "createForEachIfNotExists": { + "$ref": "#/$defs/actionsList/generic/createForEachIfNotExists" + }, + "set": { + "$ref": "#/$defs/actionsList/generic/set" + }, + "setMultiple": { + "$ref": "#/$defs/actionsList/generic/setMultiple" + }, + "setThirdPartySetting": { + "$ref": "#/$defs/actionsList/generic/setThirdPartySetting" + }, + "setThirdPartySettings": { + "$ref": "#/$defs/actionsList/generic/setThirdPartySettings" + }, + "simpleConfigUpdate": { + "$ref": "#/$defs/actionsList/generic/simpleConfigUpdate" + } + }, + "additionalProperties": false }, "contact.form.*": { "type": "object", diff --git a/src/schemas/json/paper-plugin.json b/src/schemas/json/paper-plugin.json index 8d68564beac..bcb8b6c78e1 100644 --- a/src/schemas/json/paper-plugin.json +++ b/src/schemas/json/paper-plugin.json @@ -160,8 +160,8 @@ "api-version": { "description": "The API version of the plugin", "type": "string", - "pattern": "^1\\.\\d{2}(\\.\\d{1,2})?$", - "examples": ["1.19", "1.20", "1.20.6"] + "pattern": "^\\d{1,2}\\.\\d{1,2}(\\.\\d{1,2})?$", + "examples": ["1.19", "1.20", "1.20.6", "26.1.1"] }, "dependencies": { "description": "Plugin dependencies.", diff --git a/src/schemas/json/partial-poe.json b/src/schemas/json/partial-poe.json index 787bdea4bce..c41bf829649 100644 --- a/src/schemas/json/partial-poe.json +++ b/src/schemas/json/partial-poe.json @@ -355,7 +355,14 @@ } } }, - {} + { + "not": { + "properties": { + "type": { "enum": ["uv", "virtualenv"] } + }, + "required": ["type"] + } + } ], "required": ["type"], "type": "object" @@ -860,6 +867,43 @@ }, "type": "object" }, + "groups": { + "description": "Define groups of tasks to be displayed together in the help output.", + "additionalProperties": false, + "patternProperties": { + "^\\w[\\w\\d\\-_]*$": { + "type": "object", + "additionalProperties": false, + "properties": { + "heading": { + "description": "A human-readable name for the group displayed in the help output.", + "type": "string" + }, + "executor": { + "$ref": "#/definitions/executor_option" + }, + "tasks": { + "description": "The tasks defined within this group.", + "additionalProperties": false, + "patternProperties": { + "^\\w[\\w\\d\\-_\\+:]*$": { + "oneOf": [ + { + "$ref": "#/definitions/one_of_tasks" + }, + { + "$ref": "#/definitions/tasks_array" + } + ] + } + }, + "type": "object" + } + } + } + }, + "type": "object" + }, "verbosity": { "default": 0, "description": "Sets the default verbosity level for all commands. '-1' is quieter, '0' is the default level, and '1' is more verbose. The command line arguments are incremental, with '--quiet' or '-q' decreasing verbosity, and '--verbose' or '-v' increasing it.", diff --git a/src/schemas/json/phrase.json b/src/schemas/json/phrase.json index 39be7030297..9bb78a8e339 100644 --- a/src/schemas/json/phrase.json +++ b/src/schemas/json/phrase.json @@ -30,6 +30,13 @@ "default": ";" } } + }, + "locale_mapping": { + "description": "Optional mapping between locale names in Phrase and locale names in the local files. This works in conjunction with placeholder in the file patterns. If a mapping is provided, the placeholders will be replaced with the corresponding values in the mapping. If a locale name is not included in the mapping, the locale name in Phrase will be used as a fallback.", + "type": "object", + "additionalProperties": { + "type": "string" + } } }, "properties": { @@ -51,6 +58,9 @@ "project_id": { "$ref": "#/definitions/project_id" }, + "locale_mapping": { + "$ref": "#/definitions/locale_mapping" + }, "push": { "type": "object", "properties": { diff --git a/src/schemas/json/sigrid-scope-file.schema.json b/src/schemas/json/sigrid-scope-file.schema.json index 1717a504c5b..27266e1e7bb 100644 --- a/src/schemas/json/sigrid-scope-file.schema.json +++ b/src/schemas/json/sigrid-scope-file.schema.json @@ -350,17 +350,37 @@ "properties": { "license": { "type": "string", - "description": "Excludes license risks identified in dependencies with the specified name." + "description": "Excludes license risks in dependencies matching the specified regular expression." } }, "required": ["license"] }, + { + "type": "object", + "properties": { + "freshness": { + "type": "string", + "description": "Excludes freshness risks in dependencies matching the specified regular expression." + } + }, + "required": ["freshness"] + }, + { + "type": "object", + "properties": { + "management": { + "type": "string", + "description": "Excludes management risks in dependencies matching the specified regular expression." + } + }, + "required": ["management"] + }, { "type": "object", "properties": { "activity": { "type": "string", - "description": "Excludes activity risks identified in dependencies with the specified name." + "description": "Excludes activity risks in dependencies matching the specified regular expression." } }, "required": ["activity"] @@ -555,7 +575,7 @@ }, "include": { "$ref": "#/definitions/file_pattern_list", - "description": "List of file/directory patterns that should be included in the third party findings analysis beyond the maintainability scope and production configuration files." + "description": "List of file/directory patterns to explicitly include beyond the files normally in scope." }, "exclude": { "$ref": "#/definitions/file_pattern_list", @@ -567,7 +587,7 @@ }, "checkmarx": false }, - "required": ["languages"], + "required": [], "title": "Sigrid scope configuration file", "type": "object" } diff --git a/src/schemas/json/tsconfig.json b/src/schemas/json/tsconfig.json index b8b242bf356..6cabbb9cbee 100644 --- a/src/schemas/json/tsconfig.json +++ b/src/schemas/json/tsconfig.json @@ -50,36 +50,42 @@ "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.", + "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": "

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

Specifies an allowlist of files to include in the program. An error occurs if any of the files can't be found.

\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

This 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.

\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.", + "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 `/// 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

Specifies an array of filenames or patterns that should be skipped when resolving include.

\n

Important: exclude only changes which files are included as a result of the 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 list.

\n

It is not a mechanism that prevents a file from being included in the codebase - it simply changes what the include setting finds.

\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.", + "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\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\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": "

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

Specifies 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  "include": ["src/**/*", "tests/**/*"]\n}\n
\n

Which would include:

\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

include and exclude support wildcard characters to make glob patterns:

\n\n

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. .ts, .tsx, and .d.ts by default, with .js and .jsx if allowJs is set to true).

\n" } } }, @@ -94,7 +100,7 @@ "extendsDefinition": { "properties": { "extends": { - "description": "Path to base configuration file to inherit from (requires TypeScript version 2.1 or later), or array of base files, with the rightmost files having the greater priority (requires TypeScript version 5.0 or later).", + "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": "", @@ -107,7 +113,9 @@ }, "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": "

Path to base configuration file to inherit from. Requires TypeScript version 2.1 or later.

\n
\n

The 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

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.

\n

It's worth noting that files, include, and exclude from the inheriting config file overwrite those from the\nbase config file, and that circularity between configuration files is not allowed.

\n

Currently, the only top-level property that is excluded from inheritance is references.

\n
Example
\n

configs/base.json:

\n
{\n  "compilerOptions": {\n    "noImplicitAny": true,\n    "strictNullChecks": true\n  }\n}\n
\n

tsconfig.json:

\n
{\n  "extends": "./configs/base",\n  "files": ["main.ts", "supplemental.ts"]\n}\n
\n

tsconfig.nostrictnull.json:

\n
{\n  "extends": "./tsconfig",\n  "compilerOptions": {\n    "strictNullChecks": false\n  }\n}\n
\n

Properties 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.

\n" } } }, @@ -124,31 +132,36 @@ "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\n\nSee more: https://www.typescriptlang.org/tsconfig#force" + "markdownDescription": "Build all projects, including those that appear to be up to date", + "x-intellij-html-description": "

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

\n" }, "verbose": { "description": "Enable verbose logging", "type": ["boolean", "null"], "default": false, - "markdownDescription": "Enable verbose logging\n\nSee more: https://www.typescriptlang.org/tsconfig#verbose" + "markdownDescription": "Enable verbose logging", + "x-intellij-html-description": "

Enable verbose logging

\n" }, "incremental": { - "description": "Save .tsbuildinfo files to allow for incremental compilation of projects.", + "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": "Save .tsbuildinfo files to allow for incremental compilation of projects.\n\nSee more: https://www.typescriptlang.org/tsconfig#incremental" + "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": "

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.

\n

To control which folders you want to the files to be built to, use the config option tsBuildInfoFile.

\n" }, "assumeChangesOnlyAffectDirectDependencies": { - "description": "Have recompiles in projects that use `incremental` and `watch` mode assume that changes within a file will only affect files directly depending on it.", + "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": "Have recompiles in projects that use `incremental` and `watch` mode assume that changes within a file will only affect files directly depending on it.\n\nSee more: https://www.typescriptlang.org/tsconfig#assumeChangesOnlyAffectDirectDependencies" + "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": "

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

This 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.

\n" }, "traceResolution": { - "description": "Log paths used during the `moduleResolution` process.", + "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": "Log paths used during the `moduleResolution` process.\n\nSee more: https://www.typescriptlang.org/tsconfig#traceResolution" + "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": "

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.

\n" } } } @@ -165,42 +178,48 @@ "type": ["string", "null"] }, "watchFile": { - "description": "Specify how the TypeScript watch mode works.", + "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": "Specify how the TypeScript watch mode works.\n\nSee more: https://www.typescriptlang.org/tsconfig#watchFile" + "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": "

The strategy for how individual files are watched.

\n\n" }, "watchDirectory": { - "description": "Specify how directories are watched on systems that lack recursive file-watching functionality.", + "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": "Specify how directories are watched on systems that lack recursive file-watching functionality.\n\nSee more: https://www.typescriptlang.org/tsconfig#watchDirectory" + "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": "

The strategy for how entire directory trees are watched under systems that lack recursive file-watching functionality.

\n\n" }, "fallbackPolling": { - "description": "Specify what approach the watcher should use if the system runs out of native file watchers.", + "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": "Specify what approach the watcher should use if the system runs out of native file watchers.\n\nSee more: https://www.typescriptlang.org/tsconfig#fallbackPolling" + "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": "

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" }, "synchronousWatchDirectory": { - "description": "Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively.", + "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.\n\nSee more: https://www.typescriptlang.org/tsconfig#synchronousWatchDirectory" + "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": "

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  "watchOptions": {\n    "synchronousWatchDirectory": true\n  }\n}\n
\n" }, "excludeFiles": { - "description": "Remove a list of files from the watch mode's processing.", + "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": "Remove a list of files from the watch mode's processing.\n\nSee more: https://www.typescriptlang.org/tsconfig#excludeFiles" + "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": "

You can use excludeFiles to remove a set of specific files from the files which are watched.

\n
{\n  "watchOptions": {\n    "excludeFiles": ["temp/file.ts"]\n  }\n}\n
\n" }, "excludeDirectories": { - "description": "Remove a list of directories from the watch process.", + "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": "Remove a list of directories from the watch process.\n\nSee more: https://www.typescriptlang.org/tsconfig#excludeDirectories" + "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": "

You can use 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  "watchOptions": {\n    "excludeDirectories": ["**/node_modules", "_build", "temp/*"]\n  }\n}\n
\n" } } } @@ -213,155 +232,177 @@ "description": "Instructs the TypeScript compiler how to compile .ts files.", "properties": { "allowArbitraryExtensions": { - "description": "Enable importing files with any extension, provided a declaration file is present.", + "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": "Enable importing files with any extension, provided a declaration file is present.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowArbitraryExtensions" + "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": "

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
/* app.css */\n.cookie-banner {\n  display: none;\n}\n
\n
// app.d.css.ts\ndeclare const css: {\n  cookieBanner: string;\n};\nexport default css;\n
\n
// App.tsx\nimport styles from "./app.css";\n\nstyles.cookieBanner; // string\n
\n

By 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

Note 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

For more information, read up the proposal for this feature and its corresponding pull request.

\n" }, "allowImportingTsExtensions": { - "description": "Allow imports to include TypeScript file extensions. Requires `--moduleResolution bundler` and either `--noEmit` or `--emitDeclarationOnly` to be set.", + "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": "Allow imports to include TypeScript file extensions. Requires `--moduleResolution bundler` and either `--noEmit` or `--emitDeclarationOnly` to be set.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowImportingTsExtensions" + "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": "

--allowImportingTsExtensions allows TypeScript files to import each other with a TypeScript-specific extension like .ts, .mts, or .tsx.

\n

This 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.

\n" }, "charset": { - "description": "No longer supported. In early versions, manually set the text encoding for reading files.", + "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": "No longer supported. In early versions, manually set the text encoding for reading files.\n\nSee more: https://www.typescriptlang.org/tsconfig#charset" + "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": "

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.

\n" }, "composite": { - "description": "Enable constraints that allow a TypeScript project to be used with project references.", + "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": "Enable constraints that allow a TypeScript project to be used with project references.\n\nSee more: https://www.typescriptlang.org/tsconfig#composite" + "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": "

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

When this setting is on:

\n\n

You can find documentation on TypeScript projects in the handbook.

\n" }, "customConditions": { - "description": "Conditions to set in addition to the resolver-specific defaults when resolving imports.", + "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": "Conditions to set in addition to the resolver-specific defaults when resolving imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#customConditions" + "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": "

--customConditions takes a list of additional conditions that should succeed when TypeScript resolves from an exports or imports field of a package.json.\nThese conditions are added to whatever existing conditions a resolver will use by default.

\n

For example, when this field is set in a tsconfig.json as so:

\n
{\n    "compilerOptions": {\n        "target": "es2022",\n        "moduleResolution": "bundler",\n        "customConditions": ["my-condition"]\n    }\n}\n
\n

Any time an exports or imports field is referenced in package.json, TypeScript will consider conditions called my-condition.

\n

So when importing from a package with the following package.json

\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

TypeScript will try to look for files corresponding to foo.mjs.

\n

This field is only valid under the node16, nodenext, and bundler options for --moduleResolution.

\n" }, "declaration": { - "description": "Generate .d.ts files from TypeScript and JavaScript files in your project.", + "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 from TypeScript and JavaScript files in your project.\n\nSee more: https://www.typescriptlang.org/tsconfig#declaration" + "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": "

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

When declaration is set to true, running the compiler with this TypeScript code:

\n
export let helloWorld = "hi";\n
\n

Will generate an index.js file like this:

\n
// @showEmit\nexport let helloWorld = "hi";\n
\n

With a corresponding helloWorld.d.ts:

\n
// @showEmittedFile: index.d.ts\n// @showEmit\n// @declaration\nexport let helloWorld = "hi";\n
\n

When working with .d.ts files for JavaScript files you may want to use emitDeclarationOnly or use outDir to ensure that the JavaScript files are not overwritten.

\n" }, "declarationDir": { - "description": "Specify the output directory for generated declaration files.", + "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": "Specify the output directory for generated declaration files.\n\nSee more: https://www.typescriptlang.org/tsconfig#declarationDir" + "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": "

Offers a way to configure the root directory for where declaration files are emitted.

\n
example\n├── index.ts\n├── package.json\n└── tsconfig.json\n
\n

with this tsconfig.json:

\n
{\n  "compilerOptions": {\n    "declaration": true,\n    "declarationDir": "./types"\n  }\n}\n
\n

Would place the d.ts for the index.ts in a types folder:

\n
example\n├── index.js\n├── index.ts\n├── package.json\n├── tsconfig.json\n└── types\n    └── index.d.ts\n
\n" }, "diagnostics": { - "description": "Output compiler performance information after building.", + "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": "Output compiler performance information after building.\n\nSee more: https://www.typescriptlang.org/tsconfig#diagnostics" + "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": "

Used to output diagnostic information for debugging. This command is a subset of extendedDiagnostics which are more user-facing results, and easier to interpret.

\n

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 extendedDiagnostics instead.

\n" }, "disableReferencedProjectLoad": { - "description": "Reduce the number of projects loaded automatically by TypeScript.", + "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": "Reduce the number of projects loaded automatically by TypeScript.\n\nSee more: https://www.typescriptlang.org/tsconfig#disableReferencedProjectLoad" + "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": "

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

If 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.

\n" }, "noPropertyAccessFromIndexSignature": { - "description": "Enforces using indexed accessors for keys declared using an indexed type.", + "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": "Enforces using indexed accessors for keys declared using an indexed type.\n\nSee more: https://www.typescriptlang.org/tsconfig#noPropertyAccessFromIndexSignature" + "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": "

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

Without this flag, TypeScript will allow you to use the dot syntax to access fields which are not defined:

\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

Turning the flag on will raise an error because the unknown field uses dot syntax instead of indexed syntax.

\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

The goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.

\n" }, "emitBOM": { - "description": "Emit a UTF-8 Byte Order Mark (BOM) in the beginning of output files.", + "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": "Emit a UTF-8 Byte Order Mark (BOM) in the beginning of output files.\n\nSee more: https://www.typescriptlang.org/tsconfig#emitBOM" + "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": "

Controls whether TypeScript will emit a byte order mark (BOM) 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.

\n" }, "emitDeclarationOnly": { - "description": "Only output d.ts files and not JavaScript files.", + "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 output d.ts files and not JavaScript files.\n\nSee more: https://www.typescriptlang.org/tsconfig#emitDeclarationOnly" + "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": "

Only emit .d.ts files; do not emit .js files.

\n

This setting is useful in two cases:

\n\n" }, "erasableSyntaxOnly": { - "description": "Do not allow runtime constructs that are not part of ECMAScript.", + "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* ``-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: -style type assertion.\nconst num = 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": "Do not allow runtime constructs that are not part of ECMAScript.\n\nSee more: https://www.typescriptlang.org/tsconfig#erasableSyntaxOnly" + "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* ``-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: -style type assertion.\nconst num = 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": "

Node.js supports running TypeScript files directly 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

That means the following constructs are not supported:

\n
    \n
  • enum declarations
    • \n
  • namespaces and modules with runtime code
    • \n
  • parameter properties in classes
    • \n
  • Non-ECMAScript import = and export = assignments
    • \n
  • <prefix>-style type assertions
    • \n
\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

Similar tools like ts-blank-space or 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

The --erasableSyntaxOnly flag will cause TypeScript to error on most TypeScript-specific constructs that have runtime behavior.

\n
class C {\n    constructor(public x: number) { }\n    //          ~~~~~~~~~~~~~~~~\n    // error! This syntax is not allowed when 'erasableSyntaxOnly' is enabled.\n    }\n}\n
\n

Typically, 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.

\n" }, "exactOptionalPropertyTypes": { - "description": "Interpret optional property types as written, rather than adding `undefined`.", + "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": "Interpret optional property types as written, rather than adding `undefined`.\n\nSee more: https://www.typescriptlang.org/tsconfig#exactOptionalPropertyTypes" + "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": "

With exactOptionalPropertyTypes enabled, TypeScript applies stricter rules around how it handles properties on type or interfaces which have a ? prefix.

\n

For 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
interface UserDefaults {\n  // The absence of a value represents 'system'\n  colorThemeOverride?: "dark" | "light";\n}\n
\n

Without this flag enabled, there are three values which you can set colorThemeOverride to be: "dark", "light" and undefined.

\n

Setting 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

exactOptionalPropertyTypes makes TypeScript truly enforce the definition provided as an optional property:

\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
\n" }, "incremental": { "description": "Enable incremental compilation. Requires TypeScript version 3.4 or later.", "type": ["boolean", "null"] }, "tsBuildInfoFile": { - "description": "Specify the path to .tsbuildinfo incremental compilation file.", + "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 `.tsbuildinfo`.\n- If `rootDir` and `outDir` are set, then the file is `//.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 `/.tsbuildInfo`\n- Otherwise, the default is `.tsbuildInfo`", "default": ".tsbuildinfo", "type": ["string", "null"], - "markdownDescription": "Specify the path to .tsbuildinfo incremental compilation file.\n\nSee more: https://www.typescriptlang.org/tsconfig#tsBuildInfoFile" + "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 `.tsbuildinfo`.\n- If `rootDir` and `outDir` are set, then the file is `//.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 `/.tsbuildInfo`\n- Otherwise, the default is `.tsbuildInfo`", + "x-intellij-html-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.

\n

The 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\nFor example, if rootDir is src, outDir is dest, and the config is\n./tsconfig.json, then the default is ./tsconfig.tsbuildinfo\nas 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
    • \n
\n" }, "inlineSourceMap": { - "description": "Include sourcemap files inside the emitted JavaScript.", + "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": "Include sourcemap files inside the emitted JavaScript.\n\nSee more: https://www.typescriptlang.org/tsconfig#inlineSourceMap" + "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": "

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

Mutually exclusive with sourceMap.

\n

For example, with this TypeScript:

\n
const helloWorld = "hi";\nconsole.log(helloWorld);\n
\n

Converts to this JavaScript:

\n
// @showEmit\nconst helloWorld = "hi";\nconsole.log(helloWorld);\n
\n

Then 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
// @inlineSourceMap\n// @showEmit\nconst helloWorld = "hi";\nconsole.log(helloWorld);\n
\n" }, "inlineSources": { - "description": "Include source code in the sourcemaps inside the emitted JavaScript.", + "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": "Include source code in the sourcemaps inside the emitted JavaScript.\n\nSee more: https://www.typescriptlang.org/tsconfig#inlineSources" + "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": "

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.

\n

Requires either sourceMap or inlineSourceMap to be set.

\n

For example, with this TypeScript:

\n
const helloWorld = "hi";\nconsole.log(helloWorld);\n
\n

By default converts to this JavaScript:

\n
// @showEmit\nconst helloWorld = "hi";\nconsole.log(helloWorld);\n
\n

Then enable building it with inlineSources and 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 because the source-map now contains the original source code also.

\n
// @inlineSources\n// @inlineSourceMap\n// @showEmit\nconst helloWorld = "hi";\nconsole.log(helloWorld);\n
\n" }, "jsx": { - "description": "Specify what JSX code is generated.", + "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 = () =>

Hello world

;\n```\n\nReact: `\"react-jsx\"`[[1]](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html)\n\n```tsx twoslash\ndeclare module JSX {\n interface Element {}\n interface IntrinsicElements {\n [s: string]: any;\n }\n}\n// @showEmit\n// @noErrors\n// @jsx: react-jsx\nexport const HelloWorld = () =>

Hello world

;\n```\n\nReact dev transform: `\"react-jsxdev\"`[[1]](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html)\n\n```tsx twoslash\ndeclare module JSX {\n interface Element {}\n interface IntrinsicElements {\n [s: string]: any;\n }\n}\n// @showEmit\n// @noErrors\n// @jsx: react-jsxdev\nexport const HelloWorld = () =>

Hello world

;\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 = () =>

Hello world

;\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 = () =>

Hello world

;\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 = () =>

Hello world

;\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 = () =>

Hello world

;\n```\n\nAlways use the automatic runtime (`\"react-jsx\"`) for this file:\n\n```tsx\n/* @jsxRuntime automatic */\nexport const HelloWorld = () =>

Hello world

;\n```", "enum": [ "preserve", "react", "react-jsx", "react-jsxdev", "react-native" - ], - "markdownDescription": "Specify what JSX code is generated.\n\nSee more: https://www.typescriptlang.org/tsconfig#jsx" + ] }, "reactNamespace": { - "description": "Specify the object invoked for `createElement`. This only applies when targeting `react` JSX emit.", + "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": "Specify the object invoked for `createElement`. This only applies when targeting `react` JSX emit.\n\nSee more: https://www.typescriptlang.org/tsconfig#reactNamespace" + "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": "

Use jsxFactory instead. Specify the object invoked for createElement when targeting react for TSX files.

\n" }, "jsxFactory": { - "description": "Specify the JSX factory function used when targeting React JSX emit, e.g. `React.createElement` or `h`.", + "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 = () =>
Hello
;\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 = () =>
Hello
;\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 = () =>
Hello
;\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": "Specify the JSX factory function used when targeting React JSX emit, e.g. `React.createElement` or `h`.\n\nSee more: https://www.typescriptlang.org/tsconfig#jsxFactory" + "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 = () =>
Hello
;\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 = () =>
Hello
;\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 = () =>
Hello
;\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": "

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

For example, this TSX file:

\n
import { h } from "preact";\n\nconst HelloWorld = () => <div>Hello</div>;\n
\n

With jsxFactory: "h" looks like:

\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

This option can be used on a per-file basis too similar to Babel's /** @jsx h */ directive.

\n
/** @jsx h */\nimport { h } from "preact";\n\nconst HelloWorld = () => <div>Hello</div>;\n
\n

The factory chosen will also affect where the JSX namespace is looked up (for type checking information) before falling back to the global one.

\n

If 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.

\n" }, "jsxFragmentFactory": { - "description": "Specify the JSX Fragment reference used for fragments when targeting React JSX emit e.g. `React.Fragment` or `Fragment`.", + "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
Hello
\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
Hello
\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
Hello
\n \n);\n```", "type": ["string", "null"], "default": "React.Fragment", - "markdownDescription": "Specify the JSX Fragment reference used for fragments when targeting React JSX emit e.g. `React.Fragment` or `Fragment`.\n\nSee more: https://www.typescriptlang.org/tsconfig#jsxFragmentFactory" + "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
Hello
\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
Hello
\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
Hello
\n \n);\n```", + "x-intellij-html-description": "

Specify the JSX fragment factory function to use when targeting react JSX emit with jsxFactory compiler option is specified, e.g. Fragment.

\n

For example with this TSConfig:

\n
{\n  "compilerOptions": {\n    "target": "esnext",\n    "module": "commonjs",\n    "jsx": "react",\n    "jsxFactory": "h",\n    "jsxFragmentFactory": "Fragment"\n  }\n}\n
\n

This TSX file:

\n
import { h, Fragment } from "preact";\n\nconst HelloWorld = () => (\n  <>\n    <div>Hello</div>\n  </>\n);\n
\n

Would look like:

\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

This option can be used on a per-file basis too similar to Babel's /* @jsxFrag h */ directive.

\n

For example:

\n
/** @jsx h */\n/** @jsxFrag Fragment */\n\nimport { h, Fragment } from "preact";\n\nconst HelloWorld = () => (\n  <>\n    <div>Hello</div>\n  </>\n);\n
\n" }, "jsxImportSource": { - "description": "Specify module specifier used to import the JSX factory functions when using `jsx: react-jsx*`.", + "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

Hello World

;\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

Hello World

;\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

Hello World

;\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

Hello World

;\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": "Specify module specifier used to import the JSX factory functions when using `jsx: react-jsx*`.\n\nSee more: https://www.typescriptlang.org/tsconfig#jsxImportSource" + "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

Hello World

;\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

Hello World

;\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

Hello World

;\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

Hello World

;\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": "

Declares the module specifier to be used for importing the jsx and jsxs factory functions when using jsx as "react-jsx" or "react-jsxdev" which were introduced in TypeScript 4.1.

\n

With React 17 the library supports a new form of JSX transformation via a separate import.

\n

For example with this code:

\n
import React from "react";\n\nfunction App() {\n  return <h1>Hello World</h1>;\n}\n
\n

Using this TSConfig:

\n
{\n  "compilerOptions": {\n    "target": "esnext",\n    "module": "commonjs",\n    "jsx": "react-jsx"\n  }\n}\n
\n

The emitted JavaScript from TypeScript is:

\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

For example if you wanted to use "jsxImportSource": "preact", you need a tsconfig like:

\n
{\n  "compilerOptions": {\n    "target": "esnext",\n    "module": "commonjs",\n    "jsx": "react-jsx",\n    "jsxImportSource": "preact",\n    "types": ["preact"]\n  }\n}\n
\n

Which generates code like:

\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

Alternatively, you can use a per-file pragma to set this option, for example:

\n
/** @jsxImportSource preact */\n\nexport function App() {\n  return <h1>Hello World</h1>;\n}\n
\n

Would add preact/jsx-runtime as an import for the _jsx factory.

\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.

\n" }, "listFiles": { - "description": "Print all of the files read during the compilation.", + "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 all of the files read during the compilation.\n\nSee more: https://www.typescriptlang.org/tsconfig#listFiles" + "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": "

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

For example:

\n
example\n├── index.ts\n├── package.json\n└── tsconfig.json\n
\n

With:

\n
{\n  "compilerOptions": {\n    "listFiles": true\n  }\n}\n
\n

Would echo paths like:

\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

Note if using TypeScript 4.2, prefer explainFiles which offers an explanation of why a file was added too.

\n" }, "mapRoot": { - "description": "Specify the location where debugger should locate map files instead of generated locations.", + "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.\n\nSee more: https://www.typescriptlang.org/tsconfig#mapRoot" + "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": "

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  "compilerOptions": {\n    "sourceMap": true,\n    "mapRoot": "https://my-website.com/debug/sourcemaps/"\n  }\n}\n
\n

Would declare that index.js will have sourcemaps at https://my-website.com/debug/sourcemaps/index.js.map.

\n" }, "module": { - "description": "Specify what module code is generated.", + "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": [ { @@ -387,10 +428,11 @@ "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": "Specify what module code is generated.\n\nSee more: https://www.typescriptlang.org/tsconfig#module" + "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": "

Sets the module system for the program. See the theory behind TypeScript’s module option and its reference page for more information. You very likely want "nodenext" for modern Node.js projects and preserve or esnext for code that will be bundled.

\n

Changing module affects moduleResolution which also has a reference page.

\n

Here's some example output for this file:

\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

CommonJS

\n
// @showEmit\n// @module: commonjs\n// @noErrors\nimport { valueOfPi } from "./constants";\n\nexport const twoPi = valueOfPi * 2;\n
\n

UMD

\n
// @showEmit\n// @module: umd\n// @noErrors\nimport { valueOfPi } from "./constants";\n\nexport const twoPi = valueOfPi * 2;\n
\n

AMD

\n
// @showEmit\n// @module: amd\n// @noErrors\nimport { valueOfPi } from "./constants";\n\nexport const twoPi = valueOfPi * 2;\n
\n

System

\n
// @showEmit\n// @module: system\n// @noErrors\nimport { valueOfPi } from "./constants";\n\nexport const twoPi = valueOfPi * 2;\n
\n

ESNext

\n
// @showEmit\n// @module: esnext\n// @noErrors\nimport { valueOfPi } from "./constants";\n\nexport const twoPi = valueOfPi * 2;\n
\n

ES2015/ES6/ES2020/ES2022

\n
// @showEmit\n// @module: es2015\n// @noErrors\nimport { valueOfPi } from "./constants";\n\nexport const twoPi = valueOfPi * 2;\n
\n

In addition to the base functionality of ES2015/ES6, ES2020 adds support for dynamic imports, and import.meta while ES2022 further adds support for top level await.

\n

node16/node18/node20/nodenext

\n

The node16, node18, node20, and nodenext modes integrate with Node's native ECMAScript Module support. 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 and Modules Reference.

\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

In --module preserve (added 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
// @showEmit\n// @module: preserve\n// @noErrors\nimport { valueOfPi } from "./constants";\nimport constants = require("./constants");\n\nexport const piSquared = valueOfPi * constants.valueOfPi;\n
\n

While 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
// @showEmit\n// @module: none\n// @noErrors\nimport { valueOfPi } from "./constants";\n\nexport const twoPi = valueOfPi * 2;\n
\n" }, "moduleResolution": { - "description": "Specify how TypeScript looks up a file from a given module specifier.", + "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": [ { @@ -415,19 +457,21 @@ "pattern": "^(([Nn]ode)|([Nn]ode1[06])|([Nn]ode[Nn]ext)|([Cc]lassic)|([Bb]undler))$" } ], - "markdownDescription": "Specify how TypeScript looks up a file from a given module specifier.\n\nSee more: https://www.typescriptlang.org/tsconfig#moduleResolution" + "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": "

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 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
\n

There are reference pages explaining the theory behind TypeScript’s module resolution and the details of each option.

\n" }, "moduleSuffixes": { - "description": "List of file name suffixes to search when resolving a module.", + "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": "List of file name suffixes to search when resolving a module.\n\nSee more: https://www.typescriptlang.org/tsconfig#moduleSuffixes" + "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": "

Provides a way to override the default list of file name suffixes to search when resolving a module.

\n
{\n    "compilerOptions": {\n        "moduleSuffixes": [".ios", ".native", ""]\n    }\n}\n
\n

Given the above configuration, an import like the following:

\n
import * as foo from "./foo";\n
\n

TypeScript will look for the relative files ./foo.ios.ts, ./foo.native.ts, and finally ./foo.ts.

\n

Note the empty string "" in moduleSuffixes which is necessary for TypeScript to also look-up ./foo.ts.

\n

This feature can be useful for React Native projects where each target platform can use a separate tsconfig.json with differing moduleSuffixes.

\n" }, "newLine": { - "description": "Set the newline character for emitting files.", + "description": "Specify the end of line sequence to be used when emitting files: 'CRLF' (dos) or 'LF' (unix).", "type": ["string", "null"], "default": "lf", "anyOf": [ @@ -438,65 +482,76 @@ "pattern": "^(CRLF|LF|crlf|lf)$" } ], - "markdownDescription": "Set the newline character for emitting files.\n\nSee more: https://www.typescriptlang.org/tsconfig#newLine" + "markdownDescription": "Specify the end of line sequence to be used when emitting files: 'CRLF' (dos) or 'LF' (unix).", + "x-intellij-html-description": "

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

\n" }, "noEmit": { - "description": "Disable emitting files from a compilation.", + "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": "Disable emitting files from a compilation.\n\nSee more: https://www.typescriptlang.org/tsconfig#noEmit" + "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": "

Do not emit compiler output files like JavaScript source code, source-maps or declarations.

\n

This makes room for another tool like Babel, or swc to handle converting the TypeScript file to a file which can run inside a JavaScript environment.

\n

You can then use TypeScript as a tool for providing editor integration, and as a source code type-checker.

\n" }, "noEmitHelpers": { - "description": "Disable generating custom helper functions like `__extends` in compiled output.", + "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": "Disable generating custom helper functions like `__extends` in compiled output.\n\nSee more: https://www.typescriptlang.org/tsconfig#noEmitHelpers" + "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": "

Instead of importing helpers with importHelpers, you can provide implementations in the global scope for the helpers you use and completely turn off emitting of helper functions.

\n

For example, using this async function in ES5 requires a await-like function and generator-like function to run:

\n
const getAPI = async (url: string) => {\n  // Get API\n  return {};\n};\n
\n

Which creates quite a lot of JavaScript:

\n
// @showEmit\n// @target: ES5\nconst getAPI = async (url: string) => {\n  // Get API\n  return {};\n};\n
\n

Which can be switched out with your own globals via this flag:

\n
// @showEmit\n// @target: ES5\n// @noEmitHelpers\nconst getAPI = async (url: string) => {\n  // Get API\n  return {};\n};\n
\n" }, "noEmitOnError": { - "description": "Disable emitting files if any type checking errors are reported.", + "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": "Disable emitting files if any type checking errors are reported.\n\nSee more: https://www.typescriptlang.org/tsconfig#noEmitOnError" + "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": "

Do not emit compiler output files like JavaScript source code, source-maps or declarations if any errors were reported.

\n

This 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.

\n" }, "noImplicitAny": { - "description": "Enable error reporting for expressions and declarations with an implied `any` type.", + "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": "Enable error reporting for expressions and declarations with an implied `any` type.\n\nSee more: https://www.typescriptlang.org/tsconfig#noImplicitAny" + "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": "

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

This can cause some errors to be missed, for example:

\n
// @noImplicitAny: false\nfunction fn(s) {\n  // No error?\n  console.log(s.subtr(3));\n}\nfn(42);\n
\n

Turning on noImplicitAny however TypeScript will issue an error whenever it would have inferred any:

\n
// @errors: 7006\nfunction fn(s) {\n  console.log(s.subtr(3));\n}\n
\n" }, "noImplicitThis": { - "description": "Enable error reporting when `this` is given the type `any`.", + "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": "Enable error reporting when `this` is given the type `any`.\n\nSee more: https://www.typescriptlang.org/tsconfig#noImplicitThis" + "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": "

Raise error on 'this' expressions with an implied 'any' type.

\n

For 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
// @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
\n" }, "noUnusedLocals": { - "description": "Enable error reporting when local variables aren't read.", + "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": "Enable error reporting when local variables aren't read.\n\nSee more: https://www.typescriptlang.org/tsconfig#noUnusedLocals" + "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": "

Report errors on unused local variables.

\n
// @noUnusedLocals\n// @errors: 6133\nconst createKeyboard = (modelID: number) => {\n  const defaultModelID = 23;\n  return { type: "keyboard", modelID };\n};\n
\n" }, "noUnusedParameters": { - "description": "Raise an error when a function parameter isn't read.", + "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": "Raise an error when a function parameter isn't read.\n\nSee more: https://www.typescriptlang.org/tsconfig#noUnusedParameters" + "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": "

Report errors on unused parameters in functions.

\n
// @noUnusedParameters\n// @errors: 6133\nconst createDefaultKeyboard = (modelID: number) => {\n  const defaultModelID = 23;\n  return { type: "keyboard", modelID: defaultModelID };\n};\n
\n

Parameters declaration with names starting with an underscore (_) are exempt from the unused parameter checking. e.g.:

\n
// @noUnusedParameters\nconst createDefaultKeyboard = (_modelID: number) => {\n  return { type: "keyboard" };\n};\n
\n" }, "noLib": { - "description": "Disable including any library files, including the default lib.d.ts.", + "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": "Disable including any library files, including the default lib.d.ts.\n\nSee more: https://www.typescriptlang.org/tsconfig#noLib" + "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": "

Disables the automatic inclusion of any library files.\nIf this option is set, lib is ignored.

\n

TypeScript 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.

\n" }, "noResolve": { - "description": "Disallow `import`s, `require`s or ``s from expanding the number of files TypeScript should add to a project.", + "description": "By default, TypeScript will examine the initial set of files for `import` and ``s from expanding the number of files TypeScript should add to a project.\n\nSee more: https://www.typescriptlang.org/tsconfig#noResolve" + "markdownDescription": "By default, TypeScript will examine the initial set of files for `import` and `By default, TypeScript will examine the initial set of files for import and <reference directives and add these resolved files to your program.

\n

If 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.

\n" }, "noStrictGenericChecks": { - "description": "Disable strict checking of generic signatures in function types.", + "description": "TypeScript will unify type parameters when comparing two generic functions.\n\n```ts twoslash\n// @errors: 2322\n\ntype A = (x: T, y: U) => [T, U];\ntype B = (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": "Disable strict checking of generic signatures in function types.\n\nSee more: https://www.typescriptlang.org/tsconfig#noStrictGenericChecks" + "markdownDescription": "TypeScript will unify type parameters when comparing two generic functions.\n\n```ts twoslash\n// @errors: 2322\n\ntype A = (x: T, y: U) => [T, U];\ntype B = (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": "

TypeScript will unify type parameters when comparing two generic functions.

\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

This flag can be used to remove that check.

\n" }, "out": { "description": "Deprecated setting. Use `outFile` instead.", @@ -504,109 +559,127 @@ "markdownDescription": "Deprecated setting. Use `outFile` instead.\n\nSee more: https://www.typescriptlang.org/tsconfig#out" }, "skipDefaultLibCheck": { - "description": "Skip type checking .d.ts files that are included with TypeScript.", + "description": "Use [`skipLibCheck`](https://typescriptlang.org/tsconfig/#skipLibCheck) instead. Skip type checking of default library declaration files.", "type": ["boolean", "null"], "default": false, - "markdownDescription": "Skip type checking .d.ts files that are included with TypeScript.\n\nSee more: https://www.typescriptlang.org/tsconfig#skipDefaultLibCheck" + "markdownDescription": "Use [`skipLibCheck`](https://typescriptlang.org/tsconfig/#skipLibCheck) instead. Skip type checking of default library declaration files.", + "x-intellij-html-description": "

Use skipLibCheck instead. Skip type checking of default library declaration files.

\n" }, "skipLibCheck": { - "description": "Skip type checking all .d.ts files.", + "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 all .d.ts files.\n\nSee more: https://www.typescriptlang.org/tsconfig#skipLibCheck" + "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": "

Skip type checking of declaration files.

\n

This 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

A 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\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

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.

\n

Note, that if these issues come from the TypeScript standard library you can replace the library using TypeScript 4.5's lib replacement technique.

\n" }, "outFile": { - "description": "Specify a file that bundles all outputs into one JavaScript file. If `declaration` is true, also designates a file that bundles all .d.ts output.", + "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": "Specify a file that bundles all outputs into one JavaScript file. If `declaration` is true, also designates a file that bundles all .d.ts output.\n\nSee more: https://www.typescriptlang.org/tsconfig#outFile" + "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": "

If specified, all global (non-module) files will be concatenated into the single output file specified.

\n

If module is system or amd, all module files will also be concatenated into this file after all global content.

\n

Note: outFile cannot be used unless module is None, System, or AMD.\nThis option cannot be used to bundle CommonJS or ES6 modules.

\n" }, "outDir": { - "description": "Specify an output folder for all emitted files.", + "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": "Specify an output folder for all emitted files.\n\nSee more: https://www.typescriptlang.org/tsconfig#outDir" + "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": "

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 if the computed root is not what you intended.

\n

If not specified, .js files will be emitted in the same directory as the .ts files they were generated from:

\n
$ tsc\n\nexample\n├── index.js\n└── index.ts\n
\n

With a tsconfig.json like this:

\n
{\n  "compilerOptions": {\n    "outDir": "dist"\n  }\n}\n
\n

Running tsc with these settings moves the files into the specified dist folder:

\n
$ tsc\n\nexample\n├── dist\n│   └── index.js\n├── index.ts\n└── tsconfig.json\n
\n" }, "preserveConstEnums": { - "description": "Disable erasing `const enum` declarations in generated code.", + "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": "Disable erasing `const enum` declarations in generated code.\n\nSee more: https://www.typescriptlang.org/tsconfig#preserveConstEnums" + "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": "

Do not erase const enum declarations in generated code. const enums provide a way to reduce the overall memory footprint\nof your application at runtime by emitting the enum value instead of a reference.

\n

For example with this TypeScript:

\n
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("That is a great choice.");\n}\n
\n

The 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
// @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

With preserveConstEnums set to true, the enum exists at runtime and the numbers are still emitted.

\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

This essentially makes such const enums a source-code feature only, with no runtime traces.

\n" }, "preserveSymlinks": { - "description": "Disable resolving symlinks to their realpath. This correlates to the same flag in node.", + "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 `/// ` 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": "Disable resolving symlinks to their realpath. This correlates to the same flag in node.\n\nSee more: https://www.typescriptlang.org/tsconfig#preserveSymlinks" + "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 `/// ` 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": "

This is to reflect the same flag in Node.js; which does not resolve the real path of symlinks.

\n

This 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

With this enabled, references to modules and packages (e.g. imports 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.

\n" }, "preserveValueImports": { - "description": "Preserve unused imported values in the JavaScript output that would otherwise be removed.", + "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": "Preserve unused imported values in the JavaScript output that would otherwise be removed.\n\nSee more: https://www.typescriptlang.org/tsconfig#preserveValueImports" + "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": "

Deprecated in favor of verbatimModuleSyntax.

\n

There are some cases where TypeScript can't detect that you're using an import. For example, take the following code:

\n
import { Animal } from "./animal.js";\n\neval("console.log(new Animal().isDangerous())");\n
\n

or code using 'Compiles to HTML' languages like Svelte or Vue. preserveValueImports will prevent TypeScript from removing the import, even if it appears unused.

\n

When combined with 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.

\n" }, "preserveWatchOutput": { - "description": "Disable wiping the console in watch mode.", + "description": "Whether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.", "type": ["boolean", "null"], - "markdownDescription": "Disable wiping the console in watch mode.\n\nSee more: https://www.typescriptlang.org/tsconfig#preserveWatchOutput" + "markdownDescription": "Whether to keep outdated console output in watch mode instead of clearing the screen every time a change happened.", + "x-intellij-html-description": "

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

\n" }, "pretty": { - "description": "Enable color and formatting in TypeScript's output to make compiler errors easier to read.", + "description": "Stylize errors and messages using color and context, this is on by default — offers you a chance to have less terse,\nsingle colored messages from the compiler.", "type": ["boolean", "null"], "default": true, - "markdownDescription": "Enable color and formatting in TypeScript's output to make compiler errors easier to read.\n\nSee more: https://www.typescriptlang.org/tsconfig#pretty" + "markdownDescription": "Stylize errors and messages using color and context, this is on by default — offers you a chance to have less terse,\nsingle colored messages from the compiler.", + "x-intellij-html-description": "

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

\n" }, "removeComments": { - "description": "Disable emitting comments.", + "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": "Disable emitting comments.\n\nSee more: https://www.typescriptlang.org/tsconfig#removeComments" + "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": "

Strips all comments from TypeScript files when converting into JavaScript. Defaults to false.

\n

For example, this is a TypeScript file which has a JSDoc comment:

\n
/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = "Olá Mundo";\n
\n

When removeComments is set to true:

\n
// @showEmit\n// @removeComments: true\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = "Olá Mundo";\n
\n

Without setting removeComments or having it as false:

\n
// @showEmit\n// @removeComments: false\n/** The translation of 'Hello world' into Portuguese */\nexport const helloWorldPTBR = "Olá Mundo";\n
\n

This means that your comments will show up in the JavaScript code.

\n" }, "rewriteRelativeImportExtensions": { - "description": "Rewrite `.ts`, `.tsx`, `.mts`, and `.cts` file extensions in relative import paths to their JavaScript equivalent in output files.", + "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\nSee more: https://www.typescriptlang.org/tsconfig#rewriteRelativeImportExtensions" + "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": "

Rewrite .ts, .tsx, .mts, and .cts file extensions in relative import paths to their JavaScript equivalent in output files.

\n

For more information, see the TypeScript 5.7 release notes.

\n" }, "rootDir": { - "description": "Specify the root folder within your source files.", + "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": "Specify the root folder within your source files.\n\nSee more: https://www.typescriptlang.org/tsconfig#rootDir" + "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": "

Default: The longest common path of all non-declaration input files. If composite is set, the default is instead the directory containing the tsconfig.json file.

\n

When TypeScript compiles files, it keeps the same directory structure in the output directory as exists in the input directory.

\n

For example, let's say you have some input files:

\n
MyProj\n├── tsconfig.json\n├── core\n│   ├── a.ts\n│   ├── b.ts\n│   ├── sub\n│   │   ├── c.ts\n├── types.d.ts\n
\n

The inferred value for rootDir is the longest common path of all non-declaration input files, which in this case is core/.

\n

If your outDir was dist, TypeScript would write this tree:

\n
MyProj\n├── dist\n│   ├── a.js\n│   ├── b.js\n│   ├── sub\n│   │   ├── c.js\n
\n

However, 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
MyProj\n├── dist\n│   ├── core\n│   │   ├── a.js\n│   │   ├── b.js\n│   │   ├── sub\n│   │   │   ├── c.js\n
\n

Importantly, rootDir does not affect which files become part of the compilation.\nIt has no interaction with the include, exclude, or files tsconfig.json settings.

\n

Note that TypeScript will never write an output file to a directory outside of 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

For example, let's say you had this tree:

\n
MyProj\n├── tsconfig.json\n├── core\n│   ├── a.ts\n│   ├── b.ts\n├── helpers.ts\n
\n

It would be an error to specify rootDir as core and include as * because it creates a file (helpers.ts) that would need to be emitted outside the outDir (i.e. ../helpers.js).

\n" }, "isolatedModules": { - "description": "Ensure that each file can be safely transpiled without relying on other imports.", + "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": "Ensure that each file can be safely transpiled without relying on other imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#isolatedModules" + "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": "

While you can use TypeScript to produce JavaScript code from TypeScript code, it's also common to use other transpilers such as Babel 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

These limitations can cause runtime problems with some TypeScript features like const enums and namespaces.\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

It does not change the behavior of your code, or otherwise change the behavior of TypeScript's checking and emitting process.

\n

Some examples of code which does not work when isolatedModules is enabled.

\n

Exports of Non-Value Identifiers

\n

In TypeScript, you can import a type and then subsequently export it:

\n
// @noErrors\nimport { someType, someFunction } from "someModule";\n\nsomeFunction();\n\nexport { someType, someFunction };\n
\n

Because there's no value for someType, the emitted export will not try to export it (this would be a runtime error in JavaScript):

\n
export { someFunction };\n
\n

Single-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

Non-Module Files

\n

If 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
// @errors: 1277\n// @isolatedModules\nnamespace Instantiated {\n export const x = 1;\n}\n
\n

This restriction doesn't apply to .d.ts files.

\n

References to const enum members

\n

In TypeScript, when you reference a const enum member, the reference is replaced by its actual value in the emitted JavaScript. Changing this TypeScript:

\n
declare const enum Numbers {\n  Zero = 0,\n  One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n
\n

To this JavaScript:

\n
// @showEmit\n// @removeComments\ndeclare const enum Numbers {\n  Zero = 0,\n  One = 1,\n}\nconsole.log(Numbers.Zero + Numbers.One);\n
\n

Without 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.

\n" }, "sourceMap": { - "description": "Create source map files for emitted JavaScript files.", + "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": "Create source map files for emitted JavaScript files.\n\nSee more: https://www.typescriptlang.org/tsconfig#sourceMap" + "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": "

Enables the generation of sourcemap files.\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

The .js files will in turn contain a sourcemap comment to indicate where the files are to external tools, for example:

\n
// helloWorld.ts\nexport declare const helloWorld = "hi";\n
\n

Compiling with sourceMap set to true creates the following JavaScript file:

\n
// helloWorld.js\n"use strict";\nObject.defineProperty(exports, "__esModule", { value: true });\nexports.helloWorld = "hi";\n//# sourceMappingURL=// helloWorld.js.map\n
\n

And this also generates this json map:

\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
\n" }, "sourceRoot": { - "description": "Specify the root path for debuggers to find the reference source code.", + "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 root path for debuggers to find the reference source code.\n\nSee more: https://www.typescriptlang.org/tsconfig#sourceRoot" + "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": "

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  "compilerOptions": {\n    "sourceMap": true,\n    "sourceRoot": "https://my-website.com/debug/source/"\n  }\n}\n
\n

Would declare that index.js will have a source file at https://my-website.com/debug/source/index.ts.

\n" }, "suppressExcessPropertyErrors": { - "description": "Disable reporting of excess property errors during the creation of object literals.", + "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": "Disable reporting of excess property errors during the creation of object literals.\n\nSee more: https://www.typescriptlang.org/tsconfig#suppressExcessPropertyErrors" + "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": "

This disables reporting of excess property errors, such as the one shown in the following example:

\n
// @errors: 2322\ntype Point = { x: number; y: number };\nconst p: Point = { x: 1, y: 3, m: 10 };\n
\n

This flag was added to help people migrate to the stricter checking of new object literals in TypeScript 1.6.

\n

We don't recommend using this flag in a modern codebase, you can suppress one-off cases where you need it using // @ts-ignore.

\n" }, "suppressImplicitAnyIndexErrors": { - "description": "Suppress `noImplicitAny` errors when indexing objects that lack index signatures.", + "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": "Suppress `noImplicitAny` errors when indexing objects that lack index signatures.\n\nSee more: https://www.typescriptlang.org/tsconfig#suppressImplicitAnyIndexErrors" + "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": "

Turning suppressImplicitAnyIndexErrors on suppresses reporting the error about implicit anys when indexing into objects, as shown in the following example:

\n
// @noImplicitAny: true\n// @suppressImplicitAnyIndexErrors: false\n// @strict: true\n// @errors: 7053\nconst obj = { x: 10 };\nconsole.log(obj["foo"]);\n
\n

Using suppressImplicitAnyIndexErrors is quite a drastic approach. It is recommended to use a @ts-ignore comment instead:

\n
// @noImplicitAny: true\n// @strict: true\nconst obj = { x: 10 };\n// @ts-ignore\nconsole.log(obj["foo"]);\n
\n" }, "stripInternal": { - "description": "Disable emitting declarations that have `@internal` in their JSDoc comments.", + "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": "Disable emitting declarations that have `@internal` in their JSDoc comments.\n\nSee more: https://www.typescriptlang.org/tsconfig#stripInternal" + "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": "

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.

\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

With the flag set to false (default):

\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

With stripInternal set to true the d.ts emitted will be redacted.

\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

The JavaScript output is still the same.

\n" }, "target": { - "description": "Set the JavaScript language version for emitted JavaScript and include compatible library declarations.", + "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": [ @@ -633,13 +706,15 @@ "pattern": "^([Ee][Ss]([356]|(20(1[56789]|2[012345]))|[Nn][Ee][Xx][Tt]))$" } ], - "markdownDescription": "Set the JavaScript language version for emitted JavaScript and include compatible library declarations.\n\nSee more: https://www.typescriptlang.org/tsconfig#target" + "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": "

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

The 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

Changing target also changes the default value of lib.\nYou may "mix and match" target and lib settings as desired, but you could just set target for convenience.

\n

For 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, which has configurations for common platforms and their versions.

\n

The special ESNext value refers to the highest version your version of TypeScript supports.\nThis setting should be used with caution, since it doesn't mean the same thing between different TypeScript versions and can make upgrades less predictable.

\n" }, "useUnknownInCatchVariables": { - "description": "Default catch clause variables as `unknown` instead of `any`.", + "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": "Default catch clause variables as `unknown` instead of `any`.\n\nSee more: https://www.typescriptlang.org/tsconfig#useUnknownInCatchVariables" + "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": "

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
// @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

This 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.

\n" }, "watch": { "description": "Watch input files.", @@ -680,67 +755,78 @@ "default": "useFsEvents" }, "experimentalDecorators": { - "description": "Enable experimental support for legacy experimental decorators.", + "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": "Enable experimental support for legacy experimental decorators.\n\nSee more: https://www.typescriptlang.org/tsconfig#experimentalDecorators" + "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": "

Enables experimental support for decorators, which is a version of decorators that predates the TC39 standardization process.

\n

Decorators 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

You can find out more about decorator support in TypeScript in the handbook.

\n" }, "emitDecoratorMetadata": { - "description": "Emit design-type metadata for decorated declarations in source files.", + "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": "Emit design-type metadata for decorated declarations in source files.\n\nSee more: https://www.typescriptlang.org/tsconfig#emitDecoratorMetadata" + "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": "

Enables experimental support for emitting type metadata for decorators which works with the module reflect-metadata.

\n

For example, here is the TypeScript

\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

With emitDecoratorMetadata not set to true (default) the emitted JavaScript is:

\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

With emitDecoratorMetadata set to true the emitted JavaScript is:

\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
\n" }, "allowUnusedLabels": { - "description": "Disable error reporting for unused labels.", + "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": "Disable error reporting for unused labels.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowUnusedLabels" + "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": "

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
\n

Labels are very rare in JavaScript and typically indicate an attempt to write an object literal:

\n
// @errors: 7028\n// @allowUnusedLabels: false\nfunction verifyAge(age: number) {\n  // Forgot 'return' statement\n  if (age > 18) {\n    verified: true;\n  }\n}\n
\n" }, "noImplicitReturns": { - "description": "Enable error reporting for codepaths that do not explicitly return in a function.", + "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": "Enable error reporting for codepaths that do not explicitly return in a function.\n\nSee more: https://www.typescriptlang.org/tsconfig#noImplicitReturns" + "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": "

When enabled, TypeScript will check all code paths in a function to ensure they return a value.

\n
// @errors: 2366 2322\nfunction lookupHeadphonesManufacturer(color: "blue" | "black"): string {\n  if (color === "blue") {\n    return "beats";\n  } else {\n    "bose";\n  }\n}\n
\n" }, "noUncheckedIndexedAccess": { - "description": "Add `undefined` to a type when accessed using an index.", + "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": "Add `undefined` to a type when accessed using an index.\n\nSee more: https://www.typescriptlang.org/tsconfig#noUncheckedIndexedAccess" + "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": "

TypeScript has a way to describe objects which have unknown keys but known values on an object, via index signatures.

\n
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
\n

Turning on noUncheckedIndexedAccess will add undefined to any un-declared field in the type.

\n
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
\n" }, "noFallthroughCasesInSwitch": { - "description": "Enable error reporting for fallthrough cases in switch statements.", + "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": "Enable error reporting for fallthrough cases in switch statements.\n\nSee more: https://www.typescriptlang.org/tsconfig#noFallthroughCasesInSwitch" + "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": "

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
// @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
\n" }, "noImplicitOverride": { - "description": "Ensure overriding members in derived classes are marked with an override modifier.", + "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": "Ensure overriding members in derived classes are marked with an override modifier.\n\nSee more: https://www.typescriptlang.org/tsconfig#noImplicitOverride" + "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": "

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

For example, imagine you are modeling a music album syncing system:

\n
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
\n

Then when you add support for machine-learning generated playlists, you refactor the Album class to have a 'setup' function instead:

\n
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
\n

In this case, TypeScript has provided no warning that download on SharedAlbum expected to override a function in the base class.

\n

Using noImplicitOverride you can ensure that the sub-classes never go out of sync, by ensuring that functions which override include the keyword override.

\n

The following example has noImplicitOverride enabled, and you can see the error received when override is missing:

\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
\n" }, "allowUnreachableCode": { - "description": "Disable error reporting for unreachable code.", + "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": "Disable error reporting for unreachable code.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowUnreachableCode" + "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": "

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
\n

These warnings are only about code which is provably unreachable due to the use of JavaScript syntax, for example:

\n
function fn(n: number) {\n  if (n > 5) {\n    return true;\n  } else {\n    return false;\n  }\n  return true;\n}\n
\n

With "allowUnreachableCode": false:

\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

This does not affect errors on the basis of code which appears to be unreachable due to type analysis.

\n" }, "forceConsistentCasingInFileNames": { - "description": "Ensure that casing is correct in imports.", + "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": "Ensure that casing is correct in imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#forceConsistentCasingInFileNames" + "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": "

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

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.

\n" }, "generateCpuProfile": { - "description": "Emit a v8 CPU profile of the compiler run for debugging.", + "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": "Emit a v8 CPU profile of the compiler run for debugging.\n\nSee more: https://www.typescriptlang.org/tsconfig#generateCpuProfile" + "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": "

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

This option can only be used from the CLI via: --generateCpuProfile tsc-output.cpuprofile.

\n
npm run tsc --generateCpuProfile tsc-output.cpuprofile\n
\n

This file can be opened in a chromium based browser like Chrome or Edge Developer in the CPU profiler section.\nYou can learn more about understanding the compilers performance in the TypeScript wiki section on performance.

\n" }, "baseUrl": { - "description": "Specify the base directory to resolve non-relative module names.", + "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": "Specify the base directory to resolve non-relative module names.\n\nSee more: https://www.typescriptlang.org/tsconfig#baseUrl" + "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": "

Sets a base directory from which to resolve bare specifier module names. For example, in the directory structure:

\n
project\n├── ex.ts\n├── hello\n│   └── world.ts\n└── tsconfig.json\n
\n

With "baseUrl": "./", TypeScript will look for files starting at the same folder as the tsconfig.json:

\n
import { helloWorld } from "hello/world";\n\nconsole.log(helloWorld);\n
\n

This resolution has higher priority than lookups from node_modules.

\n

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, baseUrl is no longer required to be set when using paths.

\n" }, "paths": { - "description": "Specify a set of entries that re-map imports to additional lookup locations.", + "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"], @@ -750,10 +836,11 @@ "description": "Path mapping to be computed relative to baseUrl option." } }, - "markdownDescription": "Specify a set of entries that re-map imports to additional lookup locations.\n\nSee more: https://www.typescriptlang.org/tsconfig#paths" + "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": "

A series of entries which re-map imports to lookup locations relative to the baseUrl if set, or to the tsconfig file itself otherwise. There is a larger coverage of paths in the moduleResolution reference page.

\n

paths lets you declare how TypeScript should resolve an import in your require/imports.

\n
{\n  "compilerOptions": {\n    "paths": {\n      "jquery": ["./vendor/jquery/dist/jquery"]\n    }\n  }\n}\n
\n

This would allow you to be able to write import "jquery", and get all of the correct typing locally.

\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

In this case, you can tell the TypeScript file resolver to support a number of custom prefixes to find code.

\n

Note 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.

\n" }, "plugins": { - "description": "Specify a list of language service plugins to include.", + "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) — Adds SQL linting with a template strings SQL builder.\n- [typescript-styled-plugin](https://github.com/Microsoft/typescript-styled-plugin) — Provides CSS linting inside template strings .\n- [typescript-eslint-language-service](https://github.com/Quramy/typescript-eslint-language-service) — Provides eslint error messaging and fix-its inside the compiler's output.\n- [ts-graphql-plugin](https://github.com/Quramy/ts-graphql-plugin) — Provides validation and auto-completion inside GraphQL query template strings.\n\nVS Code has the ability for a extension to [automatically include language service plugins](https://code.visualstudio.com/api/references/contribution-points#contributes.typescriptServerPlugins), and so you may have some running in your editor without needing to define them in your `tsconfig.json`.", "type": ["array", "null"], "items": { "type": "object", @@ -764,78 +851,87 @@ } } }, - "markdownDescription": "Specify a list of language service plugins to include.\n\nSee more: https://www.typescriptlang.org/tsconfig#plugins" + "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) — Adds SQL linting with a template strings SQL builder.\n- [typescript-styled-plugin](https://github.com/Microsoft/typescript-styled-plugin) — Provides CSS linting inside template strings .\n- [typescript-eslint-language-service](https://github.com/Quramy/typescript-eslint-language-service) — Provides eslint error messaging and fix-its inside the compiler's output.\n- [ts-graphql-plugin](https://github.com/Quramy/ts-graphql-plugin) — 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": "

List of language service plugins to run inside the editor.

\n

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.

\n

For example:

\n\n

VS Code has the ability for a extension to automatically include language service plugins, and so you may have some running in your editor without needing to define them in your tsconfig.json.

\n" }, "rootDirs": { - "description": "Allow multiple folders to be treated as one when resolving modules.", + "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": "Allow multiple folders to be treated as one when resolving modules.\n\nSee more: https://www.typescriptlang.org/tsconfig#rootDirs" + "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": "

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

For example:

\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  "compilerOptions": {\n    "rootDirs": ["src/views", "generated/templates/views"]\n  }\n}\n
\n

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.

\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
 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  "compilerOptions": {\n    "rootDirs": ["src", "generated"]\n  }\n}\n
\n

This 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
// @filename: main.css.d.ts\nexport const appClass = "mainClassF3EC2";\n// ---cut---\n// @filename: index.ts\nimport { appClass } from "./main.css";\n
\n" }, "typeRoots": { - "description": "Specify multiple folders that act like `./node_modules/@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 `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": "Specify multiple folders that act like `./node_modules/@types`.\n\nSee more: https://www.typescriptlang.org/tsconfig#typeRoots" + "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": "

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

If typeRoots is specified, only packages under typeRoots will be included. For example:

\n
{\n  "compilerOptions": {\n    "typeRoots": ["./typings", "./vendor/types"]\n  }\n}\n
\n

This 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.

\n" }, "types": { - "description": "Specify type package names to be included without being referenced in a source file.", + "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": "Specify type package names to be included without being referenced in a source file.\n\nSee more: https://www.typescriptlang.org/tsconfig#types" + "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": "

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

If types is specified, only packages listed will be included in the global scope. For instance:

\n
{\n  "compilerOptions": {\n    "types": ["node", "jest", "express"]\n  }\n}\n
\n

This 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

What does this affect?

\n

This 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
import * as moment from "moment";\n\nmoment().format("MMMM Do YYYY, h:mm:ss a");\n
\n

The moment import would be fully typed.

\n

When 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
\n

This feature differs from typeRoots in that it is about specifying only the exact types you want included, whereas typeRoots supports saying you want particular folders.

\n" }, "traceResolution": { - "description": "Log paths used during the `moduleResolution` process.", + "description": "Enable tracing of the name resolution process. Requires TypeScript version 2.0 or later.", "type": ["boolean", "null"], - "default": false, - "markdownDescription": "Log paths used during the `moduleResolution` process.\n\nSee more: https://www.typescriptlang.org/tsconfig#traceResolution" + "default": false }, "allowJs": { - "description": "Allow JavaScript files to be a part of your program. Use the `checkJs` option to get errors from these files.", + "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 a part of your program. Use the `checkJs` option to get errors from these files.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowJs" + "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": "

Allow JavaScript files to be imported inside your project, instead of just .ts and .tsx files. For example, this JS file:

\n
// @filename: card.js\nexport const defaultCardDeck = "Heart";\n
\n

When imported into a TypeScript file will raise an error:

\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

Imports fine with allowJs enabled:

\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

This 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

It can also be used along-side declaration and emitDeclarationOnly to create declarations for JS files.

\n" }, "noErrorTruncation": { - "description": "Disable truncating types in error messages.", + "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": "Disable truncating types in error messages.\n\nSee more: https://www.typescriptlang.org/tsconfig#noErrorTruncation" + "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": "

Do not truncate error messages.

\n

With false, the default.

\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

With true

\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
\n" }, "allowSyntheticDefaultImports": { - "description": "Allow `import x from y` when a module doesn't have a default export.", + "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": "Allow `import x from y` when a module doesn't have a default export.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowSyntheticDefaultImports" + "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": "

When set to true, allowSyntheticDefaultImports allows you to write an import like:

\n
import React from "react";\n
\n

instead of:

\n
import * as React from "react";\n
\n

When the module does not explicitly specify a default export.

\n

For example, without allowSyntheticDefaultImports as true:

\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

This 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
// @filename: utilFunctions.js\nconst getStringLength = (str) => str.length;\nconst allFunctions = {\n  getStringLength,\n};\n\nmodule.exports = allFunctions;\nmodule.exports.default = allFunctions;\n
\n

This 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.

\n" }, "noImplicitUseStrict": { - "description": "Disable adding `use strict` directives in emitted JavaScript files.", + "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": "Disable adding `use strict` directives in emitted JavaScript files.\n\nSee more: https://www.typescriptlang.org/tsconfig#noImplicitUseStrict" + "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": "

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.

\n" }, "listEmittedFiles": { - "description": "Print the names of emitted files after a compilation.", + "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 the names of emitted files after a compilation.\n\nSee more: https://www.typescriptlang.org/tsconfig#listEmittedFiles" + "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": "

Print names of generated files part of the compilation to the terminal.

\n

This 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.
    • \n
\n

For example:

\n
example\n├── index.ts\n├── package.json\n└── tsconfig.json\n
\n

With:

\n
{\n  "compilerOptions": {\n    "declaration": true,\n    "listEmittedFiles": true\n  }\n}\n
\n

Would echo paths like:

\n
$ npm run tsc\n\npath/to/example/index.js\npath/to/example/index.d.ts\n
\n

Normally, TypeScript would return silently on success.

\n" }, "disableSizeLimit": { - "description": "Remove the 20mb cap on total source code size for JavaScript files in the TypeScript language server.", + "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": "Remove the 20mb cap on total source code size for JavaScript files in the TypeScript language server.\n\nSee more: https://www.typescriptlang.org/tsconfig#disableSizeLimit" + "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": "

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.

\n" }, "lib": { - "description": "Specify a set of bundled library declaration files that describe the target runtime environment.", + "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": { @@ -1000,185 +1096,210 @@ } ] }, - "markdownDescription": "Specify a set of bundled library declaration files that describe the target runtime environment.\n\nSee more: https://www.typescriptlang.org/tsconfig#lib" + "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": "

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 you specify; for example the definition for Map is available if target is ES6 or newer.

\n

You 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
\n

In TypeScript 4.5, lib files can be overridden by npm modules, find out more in the blog.

\n

High Level libraries

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
NameContents
ES5Core definitions for all ES5 functionality
ES2015Additional APIs available in ES2015 (also known as ES6) - array.find, Promise, Proxy, Symbol, Map, Set, Reflect, etc.
ES6Alias for "ES2015"
ES2016Additional APIs available in ES2016 - array.include, etc.
ES7Alias for "ES2016"
ES2017Additional APIs available in ES2017 - Object.entries, Object.values, Atomics, SharedArrayBuffer, date.formatToParts, typed arrays, etc.
ES2018Additional APIs available in ES2018 - async iterables, promise.finally, Intl.PluralRules, regexp.groups, etc.
ES2019Additional APIs available in ES2019 - array.flat, array.flatMap, Object.fromEntries, string.trimStart, string.trimEnd, etc.
ES2020Additional APIs available in ES2020 - string.matchAll, etc.
ES2021Additional APIs available in ES2021 - promise.any, string.replaceAll etc.
ES2022Additional APIs available in ES2022 - array.at, RegExp.hasIndices, etc.
ES2023Additional APIs available in ES2023 - array.with, array.findLast, array.findLastIndex, array.toSorted, array.toReversed, etc.
ESNextAdditional APIs available in ESNext - This changes as the JavaScript specification evolves
DOMDOM definitions - window, document, etc.
WebWorkerAPIs available in WebWorker contexts
ScriptHostAPIs for the Windows Script Hosting System
\n

Individual library components

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Name
DOM.Iterable
ES2015.Core
ES2015.Collection
ES2015.Generator
ES2015.Iterable
ES2015.Promise
ES2015.Proxy
ES2015.Reflect
ES2015.Symbol
ES2015.Symbol.WellKnown
ES2016.Array.Include
ES2017.object
ES2017.Intl
ES2017.SharedMemory
ES2017.String
ES2017.TypedArrays
ES2018.Intl
ES2018.Promise
ES2018.RegExp
ES2019.Array
ES2019.Object
ES2019.String
ES2019.Symbol
ES2020.String
ES2020.Symbol.wellknown
ES2021.Promise
ES2021.String
ES2021.WeakRef
ESNext.AsyncIterable
ESNext.Array
ESNext.Intl
ESNext.Symbol
\n

This list may be out of date, you can see the full list in the TypeScript source code.

\n" }, "libReplacement": { - "description": "Enable lib replacement.", + "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": "Enable lib replacement.\n\nSee more: https://www.typescriptlang.org/tsconfig#libReplacement" + "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": "

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 with the following package.json:

\n
{\n    "devDependencies": {\n       "@typescript/lib-dom": "npm:@types/web@0.0.199"\n     }\n}\n
\n

When installed, a package called @typescript/lib-dom should exist, and TypeScript would always look there when searching for lib.dom.d.ts.

\n

The --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.

\n" }, "moduleDetection": { - "description": "Control what method is used to detect module-format JS files.", - "enum": ["auto", "legacy", "force"], - "markdownDescription": "Control what method is used to detect module-format JS files.\n\nSee more: https://www.typescriptlang.org/tsconfig#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 type checking, take into account `null` and `undefined`.", + "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 type checking, take into account `null` and `undefined`.\n\nSee more: https://www.typescriptlang.org/tsconfig#strictNullChecks" + "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": "

When strictNullChecks is false, null and undefined are effectively ignored by the language.\nThis can lead to unexpected errors at runtime.

\n

When 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

For 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
// @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

Setting strictNullChecks to true will raise an error that you have not made a guarantee that the loggedInUser exists before trying to use it.

\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

The second example failed because the array's find function looks a bit like this simplification:

\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
\n" }, "maxNodeModuleJsDepth": { - "description": "Specify the maximum folder depth used for checking JavaScript files from `node_modules`. Only applicable with `allowJs`.", + "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": "Specify the maximum folder depth used for checking JavaScript files from `node_modules`. Only applicable with `allowJs`.\n\nSee more: https://www.typescriptlang.org/tsconfig#maxNodeModuleJsDepth" + "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": "

The maximum dependency depth to search under node_modules and load JavaScript files.

\n

This flag can only be used when allowJs is enabled, and is used if you want to have TypeScript infer types for all of the JavaScript inside your node_modules.

\n

Ideally 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.

\n" }, "importHelpers": { - "description": "Allow importing helper functions from tslib once per project, instead of including them per-file.", + "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": "Allow importing helper functions from tslib once per project, instead of including them per-file.\n\nSee more: https://www.typescriptlang.org/tsconfig#importHelpers" + "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": "

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

If the importHelpers flag is on, these helper functions are instead imported from the 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

For example, with this TypeScript:

\n
export function fn(arr: number[]) {\n  const arr2 = [1, ...arr];\n}\n
\n

Turning on downlevelIteration and importHelpers is still false:

\n
// @showEmit\n// @target: ES5\n// @downleveliteration\nexport function fn(arr: number[]) {\n  const arr2 = [1, ...arr];\n}\n
\n

Then turning on both downlevelIteration and importHelpers:

\n
// @showEmit\n// @target: ES5\n// @downleveliteration\n// @importhelpers\n// @noErrors\nexport function fn(arr: number[]) {\n  const arr2 = [1, ...arr];\n}\n
\n

You can use noEmitHelpers when you provide your own implementations of these functions.

\n" }, "importsNotUsedAsValues": { - "description": "Specify emit/checking behavior for imports that are only used for types.", + "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"], - "markdownDescription": "Specify emit/checking behavior for imports that are only used for types.\n\nSee more: https://www.typescriptlang.org/tsconfig#importsNotUsedAsValues" + "enum": ["remove", "preserve", "error"] }, "alwaysStrict": { - "description": "Ensure `use strict` is always emitted.", + "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": "Ensure `use strict` is always emitted.\n\nSee more: https://www.typescriptlang.org/tsconfig#alwaysStrict" + "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": "

Ensures that your files are parsed in the ECMAScript strict mode, and emit "use strict" for each source file.

\n

ECMAScript strict 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.

\n" }, "strict": { - "description": "Enable all strict type-checking options.", + "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": "Enable all strict type-checking options.\n\nSee more: https://www.typescriptlang.org/tsconfig#strict" + "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": "

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

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.

\n" }, "strictBindCallApply": { - "description": "Check that the arguments for `bind`, `call`, and `apply` methods match the original function.", + "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": "Check that the arguments for `bind`, `call`, and `apply` methods match the original function.\n\nSee more: https://www.typescriptlang.org/tsconfig#strictBindCallApply" + "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": "

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
// @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

Otherwise, these functions accept any arguments and will return any:

\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
\n" }, "downlevelIteration": { - "description": "Emit more compliant, but verbose and less performant JavaScript for iteration.", + "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": "Emit more compliant, but verbose and less performant JavaScript for iteration.\n\nSee more: https://www.typescriptlang.org/tsconfig#downlevelIteration" + "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": "

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

ECMAScript 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.\ndownlevelIteration allows for these iteration primitives to be used more accurately in ES5 environments if a Symbol.iterator implementation is present.

\n

Example: Effects on for / of

\n

With this TypeScript code:

\n
const str = "Hello!";\nfor (const s of str) {\n  console.log(s);\n}\n
\n

Without downlevelIteration enabled, a for / of loop on any object is downleveled to a traditional for loop:

\n
// @target: ES5\n// @showEmit\nconst str = "Hello!";\nfor (const s of str) {\n  console.log(s);\n}\n
\n

This 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 for a longer explanation.

\n

When 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
// @target: ES5\n// @downlevelIteration\n// @showEmit\nconst str = "Hello!";\nfor (const s of str) {\n  console.log(s);\n}\n
\n

You can use tslib via importHelpers to reduce the amount of inline JavaScript too:

\n
// @target: ES5\n// @downlevelIteration\n// @importHelpers\n// @showEmit\nconst str = "Hello!";\nfor (const s of str) {\n  console.log(s);\n}\n
\n

Note: enabling downlevelIteration does not improve compliance if Symbol.iterator is not present in the runtime.

\n

Example: Effects on Array Spreads

\n

This is an array spread:

\n
// Make a new array whose elements are 1 followed by the elements of arr2\nconst arr = [1, ...arr2];\n
\n

Based on the description, it sounds easy to downlevel to ES5:

\n
// The same, right?\nconst arr = [1].concat(arr2);\n
\n

However, this is observably different in certain rare cases.

\n

For 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
// 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

Just as with for / of, downlevelIteration will use Symbol.iterator (if present) to more accurately emulate ES 6 behavior.

\n" }, "checkJs": { - "description": "Enable error reporting in type-checked JavaScript files.", + "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": "Enable error reporting in type-checked JavaScript files.\n\nSee more: https://www.typescriptlang.org/tsconfig#checkJs" + "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": "

Works in tandem with 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

For example, this is incorrect JavaScript according to the parseFloat type definition which comes with TypeScript:

\n
// parseFloat only takes a string\nmodule.exports.pi = parseFloat(3.142);\n
\n

When imported into a TypeScript module:

\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

You will not get any errors. However, if you turn on checkJs then you will get error messages from the JavaScript file.

\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
\n" }, "strictFunctionTypes": { - "description": "When assigning functions, check to ensure parameters and the return values are subtype-compatible.", + "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 assigning functions, check to ensure parameters and the return values are subtype-compatible.\n\nSee more: https://www.typescriptlang.org/tsconfig#strictFunctionTypes" + "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": "

When enabled, this flag causes functions parameters to be checked more correctly.

\n

Here's a basic example with strictFunctionTypes off:

\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

With strictFunctionTypes on, the error is correctly detected:

\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

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 function syntax, not to those in method syntax:

\n
type 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
\n" }, "strictPropertyInitialization": { - "description": "Check for class properties that are declared but not set in the constructor.", + "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": "Check for class properties that are declared but not set in the constructor.\n\nSee more: https://www.typescriptlang.org/tsconfig#strictPropertyInitialization" + "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": "

When set to true, TypeScript will raise an error when a class property was declared but not set in the constructor.

\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

In 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.
    • \n
\n" }, "esModuleInterop": { - "description": "Emit additional JavaScript to ease support for importing CommonJS modules. This enables `allowSyntheticDefaultImports` for type compatibility.", + "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": "Emit additional JavaScript to ease support for importing CommonJS modules. This enables `allowSyntheticDefaultImports` for type compatibility.\n\nSee more: https://www.typescriptlang.org/tsconfig#esModuleInterop" + "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": "

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
    • \n
\n

This 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\ntreating 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
    • \n
\n

Turning 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
import * as fs from "fs";\nimport _ from "lodash";\n\nfs.readFileSync("file.txt", "utf8");\n_.chunk(["a", "b", "c", "d"], 2);\n
\n

With esModuleInterop disabled:

\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

With esModuleInterop set to true:

\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

Note: The namespace import import * as fs from "fs" only accounts for properties which are owned (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

Note: You can make JS emit terser by enabling importHelpers:

\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

Enabling esModuleInterop will also enable allowSyntheticDefaultImports.

\n" }, "allowUmdGlobalAccess": { - "description": "Allow accessing UMD globals from modules.", + "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": "Allow accessing UMD globals from modules.\n\nSee more: https://www.typescriptlang.org/tsconfig#allowUmdGlobalAccess" + "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": "

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

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.

\n" }, "keyofStringsOnly": { - "description": "Make keyof only return strings instead of string, numbers or symbols. Legacy option.", + "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": "Make keyof only return strings instead of string, numbers or symbols. Legacy option.\n\nSee more: https://www.typescriptlang.org/tsconfig#keyofStringsOnly" + "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": "

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

This flag is used to help people keep this behavior from before TypeScript 2.9's release.

\n" }, "useDefineForClassFields": { - "description": "Emit ECMAScript-standard-compliant class fields.", + "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": "Emit ECMAScript-standard-compliant class fields.\n\nSee more: https://www.typescriptlang.org/tsconfig#useDefineForClassFields" + "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": "

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

This flag switches to the upcoming ECMA runtime behavior.

\n

You can read more about the transition in the 3.7 release notes.

\n" }, "declarationMap": { - "description": "Create sourcemaps for d.ts files.", + "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": "Create sourcemaps for d.ts files.\n\nSee more: https://www.typescriptlang.org/tsconfig#declarationMap" + "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": "

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

You should strongly consider turning this on if you're using project references.

\n" }, "resolveJsonModule": { - "description": "Enable importing .json files.", + "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": "Enable importing .json files.\n\nSee more: https://www.typescriptlang.org/tsconfig#resolveJsonModule" + "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": "

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

TypeScript does not support resolving JSON files by default:

\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

Enabling the option allows importing JSON, and validating the types in that JSON file.

\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
\n" }, "resolvePackageJsonExports": { - "description": "Use the package.json 'exports' field when resolving package imports.", + "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": "Use the package.json 'exports' field when resolving package imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#resolvePackageJsonExports" + "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": "

--resolvePackageJsonExports forces TypeScript to consult the exports field of package.json files if it ever reads from a package in node_modules.

\n

This option defaults to true under the node16, nodenext, and bundler options for --moduleResolution.

\n" }, "resolvePackageJsonImports": { - "description": "Use the package.json 'imports' field when resolving imports.", + "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": "Use the package.json 'imports' field when resolving imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#resolvePackageJsonImports" + "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": "

--resolvePackageJsonImports forces TypeScript to consult the imports field of package.json files when performing a lookup that starts with # from a file whose ancestor directory contains a package.json.

\n

This option defaults to true under the node16, nodenext, and bundler options for --moduleResolution.

\n" }, "assumeChangesOnlyAffectDirectDependencies": { - "description": "Have recompiles in projects that use `incremental` and `watch` mode assume that changes within a file will only affect files directly depending on it.", - "type": ["boolean", "null"], - "markdownDescription": "Have recompiles in projects that use `incremental` and `watch` mode assume that changes within a file will only affect files directly depending on it.\n\nSee more: https://www.typescriptlang.org/tsconfig#assumeChangesOnlyAffectDirectDependencies" + "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": "Output more detailed compiler performance information after building.", + "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": "Output more detailed compiler performance information after building.\n\nSee more: https://www.typescriptlang.org/tsconfig#extendedDiagnostics" + "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": "

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

You can learn more about how to measure and understand the output in the performance section of the wiki.

\n" }, "listFilesOnly": { "description": "Print names of files that are part of the compilation and then stop processing.", "type": ["boolean", "null"] }, "disableSourceOfProjectReferenceRedirect": { - "description": "Disable preferring source files instead of declaration files when referencing composite projects.", + "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": "Disable preferring source files instead of declaration files when referencing composite projects.\n\nSee more: https://www.typescriptlang.org/tsconfig#disableSourceOfProjectReferenceRedirect" + "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": "

When working with composite TypeScript projects, this option provides a way to go back to the pre-3.7 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.

\n" }, "disableSolutionSearching": { - "description": "Opt a project out of multi-project reference checking when editing.", + "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": "Opt a project out of multi-project reference checking when editing.\n\nSee more: https://www.typescriptlang.org/tsconfig#disableSolutionSearching" + "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": "

When working with composite TypeScript projects, 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

This flag is something you can use to increase responsiveness in large composite projects.

\n" }, "verbatimModuleSyntax": { - "description": "Do not transform or elide any imports or exports not marked as type-only, ensuring they are written in the output file's format based on the `module` setting.", + "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\n\n \n \n \n \n\n\n\n\n\n\n\n\n\n\n
Input TypeScriptOutput JavaScript
\n\n```ts\nimport foo = require(\"foo\");\n```\n\n\n\n```js\nconst foo = require(\"foo\");\n```\n\n
\n\n```ts\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nexport = {\n foo,\n bar,\n baz\n};\n```\n\n\n\n```js\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nmodule.exports = {\n foo,\n bar,\n baz\n};\n```\n\n
\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": "Do not transform or elide any imports or exports not marked as type-only, ensuring they are written in the output file's format based on the `module` setting.\n\nSee more: https://www.typescriptlang.org/tsconfig#verbatimModuleSyntax" + "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\n\n \n \n \n \n\n\n\n\n\n\n\n\n\n\n
Input TypeScriptOutput JavaScript
\n\n```ts\nimport foo = require(\"foo\");\n```\n\n\n\n```js\nconst foo = require(\"foo\");\n```\n\n
\n\n```ts\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nexport = {\n foo,\n bar,\n baz\n};\n```\n\n\n\n```js\nfunction foo() {}\nfunction bar() {}\nfunction baz() {}\n\nmodule.exports = {\n foo,\n bar,\n baz\n};\n```\n\n
\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": "

By default, TypeScript does something called import elision.\nBasically, if you write something like

\n
import { Car } from "./car";\n\nexport function drive(car: Car) {\n    // ...\n}\n
\n

TypeScript detects that you're only using an import for types and drops the import entirely.\nYour output JavaScript might look something like this:

\n
export function drive(car) {\n    // ...\n}\n
\n

Most 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

But 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

TypeScript'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
export { Car } from "./car";\n
\n

should 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

While TypeScript might be able to make these emit decisions based on information from across files, not every compiler can.

\n

The 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
// 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

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

TypeScript 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
// 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

With this new option, what you see is what you get.

\n

That does have some implications when it comes to module interop though.\nUnder this flag, ECMAScript imports and exports 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\n \n \n \n \n\n\n\n\n\n\n\n\n
Input TypeScriptOutput JavaScript
import foo = require("foo");\n
\n
const foo = require("foo");\n
\n
function foo() {}\nfunction bar() {}\nfunction baz() {}\n\nexport = {\n    foo,\n    bar,\n    baz\n};\n
\n
function foo() {}\nfunction bar() {}\nfunction baz() {}\n\nmodule.exports = {\n    foo,\n    bar,\n    baz\n};\n
\n

While 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 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

Because --verbatimModuleSyntax provides a more consistent story than --importsNotUsedAsValues and --preserveValueImports, those two existing flags are being deprecated in its favor.

\n

For more details, read up on the original pull request and its proposal issue.

\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).\n\nSee more: https://www.typescriptlang.org/tsconfig#noCheck" + "markdownDescription": "Disable full type checking (only critical parse and emit errors will be reported).", + "x-intellij-html-description": "

Disable full type checking (only critical parse and emit errors will be reported).

\n" }, "isolatedDeclarations": { - "description": "Require sufficient annotation on exports so other tools can trivially generate declaration files.", + "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\nSee more: https://www.typescriptlang.org/tsconfig#isolatedDeclarations" + "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": "

Require sufficient annotation on exports so other tools can trivially generate declaration files.

\n

For more information, see the 5.5 release notes

\n" }, "noUncheckedSideEffectImports": { - "description": "Check side effect imports.", + "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": "Check side effect imports.\n\nSee more: https://www.typescriptlang.org/tsconfig#noUncheckedSideEffectImports" + "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": "

In JavaScript it's possible to import a module without actually importing any values from it.

\n
import "some-module";\n
\n

These 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

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.

\n

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 .css files by writing something like the following:

\n
import "./button-component.css";\n\nexport function Button() {\n    // ...\n}\n
\n

Still, this masks potential typos on side effect imports.

\n

When --noUncheckedSideEffectImports is enabled, TypeScript will error if it can't find a source file for a side effect import.

\n
import "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

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 imports 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
// ./src/globals.d.ts\n\n// Recognize all CSS files as module imports.\ndeclare module "*.css" {}\n
\n

In fact, you might already have a file like this in your project!\nFor example, running something like vite init might create a similar vite-env.d.ts.

\n" }, "strictBuiltinIteratorReturn": { - "description": "Built-in iterators are instantiated with a `TReturn` type of `undefined` instead of `any`.", + "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`.\n\nSee more: https://www.typescriptlang.org/tsconfig#strictBuiltinIteratorReturn" + "markdownDescription": "Built-in iterators are instantiated with a `TReturn` type of undefined instead of `any`.", + "x-intellij-html-description": "

Built-in iterators are instantiated with a TReturn type of undefined instead of any.

\n" } } } @@ -1220,7 +1341,7 @@ "references": { "type": "array", "uniqueItems": true, - "description": "Referenced projects. Requires TypeScript version 3.0 or later.", + "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.", @@ -1230,7 +1351,9 @@ "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": "

Referenced projects. Requires TypeScript version 3.0 or later.

\n
\n

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.

\n

You can read more about how references works in the Project References section of the handbook

\n" } } }, @@ -1312,7 +1435,7 @@ }, "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, and\nthe file extension is ignored.\nThis is useful if you cannot use .mts, .cts, .mjs, or .cjs file extensions;\nit achieves the same effect.\n\nEach key is a glob pattern following the same rules as tsconfig's \"include\" array.\nWhen multiple patterns match the same file, the last pattern takes precedence.\n\n`cjs` overrides matches files to compile and execute as CommonJS.\n`esm` overrides matches files to compile and execute as native ECMAScript modules.\n`package` overrides either of the above to default behavior, which obeys package.json \"type\" and\ntsconfig.json \"module\" options." + "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, diff --git a/src/test/buf.lock/buf.lock.v1.deps.yaml b/src/test/buf.lock/buf.lock.v1.deps.yaml new file mode 100644 index 00000000000..f06942b7c4c --- /dev/null +++ b/src/test/buf.lock/buf.lock.v1.deps.yaml @@ -0,0 +1,10 @@ +# yaml-language-server: $schema=../../schemas/json/buf.lock.json +# Generated by buf. DO NOT EDIT. +version: v1 +deps: + - remote: buf.build + owner: googleapis + repository: googleapis + commit: 75b4300737fb4efca0831636be94e517 + digest: '1/DivfMPTLjIYBMEoY5lEtFBXygHKpFBfPzDPRm6+AklKZNJfFm2R3b4K5L9E0Y=' + create_time: '2022-07-22T10:22:24.519524Z' diff --git a/src/test/buf.policy/buf.policy.full.yaml b/src/test/buf.policy/buf.policy.full.yaml new file mode 100644 index 00000000000..b90dec4fffb --- /dev/null +++ b/src/test/buf.policy/buf.policy.full.yaml @@ -0,0 +1,29 @@ +# yaml-language-server: $schema=../../schemas/json/buf.policy.json +# via https://buf.build/docs/bsr/checks/policies + +version: v2 +name: buf.build/acme/my-policy +lint: + use: + - STANDARD + - FILE_LOWER_SNAKE_CASE + except: + - RPC_REQUEST_RESPONSE_UNIQUE + enum_zero_value_suffix: _NONE + rpc_allow_same_request_response: false + rpc_allow_google_protobuf_empty_requests: false + rpc_allow_google_protobuf_empty_responses: false + service_suffix: API + disable_builtin: false +breaking: + use: + - FILE + except: + - EXTENSION_MESSAGE_NO_DELETE + ignore_unstable_packages: true + disable_builtin: false +plugins: + - plugin: buf.build/acme/my-plugin + options: + enum_zero_value_suffix: _UNSPECIFIED + - plugin: ./path/to/local-plugin diff --git a/src/test/buf.policy/buf.policy.yaml b/src/test/buf.policy/buf.policy.yaml new file mode 100644 index 00000000000..cf88352a813 --- /dev/null +++ b/src/test/buf.policy/buf.policy.yaml @@ -0,0 +1,10 @@ +# yaml-language-server: $schema=../../schemas/json/buf.policy.json +# via https://buf.build/docs/configuration/v2/buf-policy-yaml + +version: v2 +lint: + use: + - STANDARD +breaking: + use: + - FILE diff --git a/src/test/buf/buf.v2.yaml b/src/test/buf/buf.v2.yaml index 87095c391e1..2dad7aeb7ec 100644 --- a/src/test/buf/buf.v2.yaml +++ b/src/test/buf/buf.v2.yaml @@ -44,6 +44,7 @@ modules: rpc_allow_google_protobuf_empty_requests: false rpc_allow_google_protobuf_empty_responses: false service_suffix: Service + disable_builtin: false # Breaking configuration for this module only. Behaves the same as a module-level # lint configuration. breaking: @@ -52,6 +53,7 @@ modules: except: - EXTENSION_MESSAGE_NO_DELETE ignore_unstable_packages: true + disable_builtin: false # Dependencies shared by all modules in the workspace. Must be modules hosted in the Buf Schema Registry. # The resolution of these dependencies is stored in the buf.lock file. deps: @@ -69,3 +71,18 @@ lint: breaking: use: - FILE +# Custom lint/breaking plugins applied across all modules. +plugins: + - plugin: buf.build/acme/my-plugin + options: + enum_zero_value_suffix: _UNSPECIFIED + - plugin: ./path/to/local-plugin +# Policies from the BSR or local files. +policies: + - policy: buf.build/acme/my-policy + - policy: ./buf.policy.yaml + ignore: + - proto/foo/v1/foo.proto + ignore_only: + ENUM_NO_DELETE: + - proto/bar/v1 diff --git a/src/test/drupal-recipe/drupal-recipe.yml b/src/test/drupal-recipe/drupal-recipe.yml index f9ce2bc52ef..d07d8ad0e5b 100644 --- a/src/test/drupal-recipe/drupal-recipe.yml +++ b/src/test/drupal-recipe/drupal-recipe.yml @@ -263,6 +263,7 @@ config: - module: layout_builder key: enabled value: false + allowLayoutOverrides: true contact.form.feedback: createIfNotExists: langcode: es diff --git a/src/test/phrase/.phrase.yml b/src/test/phrase/.phrase.yml index c3e4ca60d66..79f9850c2be 100644 --- a/src/test/phrase/.phrase.yml +++ b/src/test/phrase/.phrase.yml @@ -4,6 +4,10 @@ phrase: access_token: YOUR_ACCESS_TOKEN project_id: YOUR_PROJECT_ID + locale_mapping: + en: en-US + fr: fr-FR + push: sources: - file: ./config/locales/en.yml diff --git a/src/test/pyproject/poe-groups.toml b/src/test/pyproject/poe-groups.toml new file mode 100644 index 00000000000..fae3ef0c267 --- /dev/null +++ b/src/test/pyproject/poe-groups.toml @@ -0,0 +1,33 @@ +#:schema ../../schemas/json/pyproject.json + +[tool.poe.groups.server] +heading = "Application Serving" +executor = { type = "uv", group = "server" } + +[tool.poe.groups.server.tasks.dev] +help = "Run the app in debug mode" +cmd = "uvicorn my_app:app --reload" + +[tool.poe.groups.server.tasks.prod] +help = "Run the app in production mode" +cmd = "uvicorn my_app:app" + +[tool.poe.groups.testing] +heading = "Testing Tasks" + +[tool.poe.groups.testing.tasks.unit] +cmd = "pytest tests/unit" +help = "Run unit tests" + +[tool.poe.groups.testing.tasks.integration] +cmd = "pytest tests/integration" +help = "Run integration tests" + +[tool.poe.groups.testing.tasks.all] +sequence = ["unit", "integration"] +help = "Run all tests" + +[tool.poe.groups.no-heading] + +[tool.poe.groups.no-heading.tasks.build] +cmd = "python -m build"