{ "options": [ { "id": "checkJs", "slug": "check-js", "title": "checkJs", "kind": "compilerOption", "option": "checkJs", "category": "Checking JavaScript", "tsCategory": "JavaScript Support", "type": "boolean", "default": "false", "flag": "--checkJs", "officialDescription": "Enable error reporting in type-checked JavaScript files.", "since": "2.3", "startWith": "`\"checkJs\": true`", "summary": "checkJs turns on TypeScript's error reporting for .js files. What it checks, how it relates to allowJs and // @ts-check, and how to switch it on.", "intro": [ "`checkJs` is the option that makes TypeScript report errors in JavaScript files. With it on, `tsc` and your editor check every `.js` file in the project the way they check `.ts` files, using your JSDoc comments where you have written them and inference everywhere else.", "Every jsconfig.json on this site sets it. In TypeScript 5.9, `checkJs` also turns on `allowJs` when you leave `allowJs` out, so `\"checkJs\": true` on its own both includes your JavaScript files and checks them." ], "examples": [ "config/check-js-on", "config/check-js-pragma" ], "sections": [ { "id": "what-it-checks", "heading": "What it catches with no annotations", "body": [ "The first example has no JSDoc in it at all, and the checker still finds the typo. Without annotations, `checkJs` reports what it can work out from literals, the standard library, and the `@types` packages you install:" ], "list": [ "misspelled properties and methods, often with a \"Did you mean\" suggestion", "calls with too many arguments (in JavaScript, a parameter without a JSDoc type counts as optional, so calls with fewer arguments are allowed)", "wrong types going into functions that do have types, such as the DOM and Node.js APIs", "imports of files and exports that do not exist" ] }, { "id": "allowjs-and-ts-check", "heading": "checkJs, allowJs and // @ts-check", "body": [ "[`allowJs`](/config/allow-js/) lets JavaScript files into the program; `checkJs` decides whether their errors are reported. A config file named `jsconfig.json` already defaults `allowJs` to true, and in TypeScript 5.9 `checkJs` implies it as well, so most JavaScript projects only need `checkJs`.", "You can also opt in one file at a time. A [`// @ts-check`](/config/ts-check/) comment at the top of a file checks that file even when `checkJs` is off, which is how the second example works; [`// @ts-nocheck`](/config/ts-nocheck/) at the top of a file skips it when `checkJs` is on.", "For a single line, [`// @ts-expect-error`](/config/ts-expect-error/) silences the error on the next line and is itself reported (TS2578) once there is nothing left to silence. [`// @ts-ignore`](/config/ts-ignore/) silences the next line without that check, so it can hide a later, different error." ] }, { "id": "existing-codebase", "heading": "Switching it on in an existing codebase", "body": [ "In a large JavaScript codebase the first run can report hundreds of errors. A workable order: turn on `checkJs` without `strict`, fix or `// @ts-nocheck` the noisiest files, then turn on [`strict`](/config/strict/) (or [`noImplicitAny`](/config/no-implicit-any/) first) once the count is manageable. The relaxed level of the [jsconfig generator](/tools/jsconfig-generator/) is that first step." ] } ], "gotchas": [ "Set [`noEmit`](/config/no-emit/) too. A config file named `tsconfig.json` with `allowJs` and no `outDir` makes `tsc` try to write output over your own `.js` files, which fails with TS5055 (\"Cannot write file … because it would overwrite input file\"). A file named `jsconfig.json` defaults `noEmit` to true.", "`checkJs` changes what `tsc` reports and nothing else. Node.js and browsers run the same JavaScript whether it is on or off.", "Without `checkJs` (and without `// @ts-check`), editors still give completions and hovers in `.js` files but show no type errors, which can look as if everything passes." ], "faq": [ { "q": "Do I need both allowJs and checkJs?", "a": "Not in TypeScript 5.9: `checkJs` turns on `allowJs` when you leave `allowJs` out, and a file named `jsconfig.json` defaults `allowJs` to true anyway. Setting both does no harm and makes the intent plain to the next reader." }, { "q": "Is checkJs the same as // @ts-check?", "a": "They turn on the same checks. `checkJs` applies to every JavaScript file in the project; `// @ts-check` applies to the one file it is written in, and works even when `checkJs` is off." } ], "related": [ "config/allow-js", "config/ts-check", "config/strict", "errors/ts7006", "start/node-esm", "tools/jsconfig-generator" ], "sources": [ { "title": "TSConfig Reference: checkJs", "url": "https://www.typescriptlang.org/tsconfig/#checkJs", "publisher": "TypeScript" }, { "title": "TSConfig Reference: allowJs", "url": "https://www.typescriptlang.org/tsconfig/#allowJs", "publisher": "TypeScript" }, { "title": "TypeScript 2.3 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-3.html", "publisher": "TypeScript handbook" }, { "title": "Type Checking JavaScript Files", "url": "https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html", "publisher": "TypeScript handbook" }, { "title": "jsconfig.json", "url": "https://code.visualstudio.com/docs/languages/jsconfig", "publisher": "Visual Studio Code docs" } ], "updated": "2026-10-20" }, { "id": "allowJs", "slug": "allow-js", "title": "allowJs", "kind": "compilerOption", "option": "allowJs", "category": "Checking JavaScript", "tsCategory": "JavaScript Support", "type": "boolean", "default": "false", "defaultNote": "(on when `checkJs` is on and `allowJs` is left out)", "jsconfigDefault": "true", "flag": "--allowJs", "officialDescription": "Allow JavaScript files to be a part of your program. Use the 'checkJs' option to get errors from these files.", "since": "1.8", "startWith": "Nothing in a `jsconfig.json`, where it is already on. In a `tsconfig.json`, write `\"allowJs\": true` (or let `\"checkJs\": true` imply it)", "summary": "allowJs brings .js files into the program so their types reach other files, without reporting errors in them. How it differs from checkJs.", "intro": [ "`allowJs` lets JavaScript files into the program. `tsc` reads them, works out the types of what they export (from JSDoc where there is some, by inference elsewhere), and lets other files use those types. It does not report errors inside them: that is [`checkJs`](/config/check-js/).", "A file named `jsconfig.json` turns `allowJs` on by default, and in TypeScript 5.9 `checkJs` turns it on when you leave it out. In a JavaScript project you rarely write it; it matters in a `tsconfig.json`, and in projects that mix `.ts` and `.js` files." ], "examples": [ "config/allow-js-unchecked-file" ], "sections": [ { "id": "in-the-program-not-checked", "heading": "In the program, but not checked", "body": [ "The example shows the difference in one project. `legacy.js` opts out of checking with [`// @ts-nocheck`](/config/ts-nocheck/), so it is in the program the way `allowJs` alone puts a file there: its JSDoc still types `orderTotal`, and the call in `checkout.js` that passes a string price is an error. The misspelled `toUppercase` inside `legacy.js` is never reported, because nothing checks that file.", "That is the whole job of `allowJs`: types flow out of JavaScript files. Turning on `checkJs`, or adding `// @ts-check` to one file, is what makes their own mistakes visible." ] }, { "id": "when-to-write-it", "heading": "When you need to write it", "body": [ "Three cases, all outside a plain `jsconfig.json`:" ], "list": [ "a config file named `tsconfig.json` for a JavaScript project: write `\"checkJs\": true` (which implies `allowJs` in TypeScript 5.9) or both", "a TypeScript project with some `.js` files left in it: `\"allowJs\": true` with `checkJs` off lets `.ts` files import them, and `// @ts-check` opts single files in as you convert them", "a project that writes output from `.js` files (Babel-free downlevel builds, or [`.d.ts` files for a package](/config/declaration/)): `allowJs` is what lets those files be inputs" ] } ], "gotchas": [ "With `allowJs` and output turned on, `tsc` writes `.js` files. Without `outDir` or [`noEmit`](/config/no-emit/), it would write over your sources, so it stops with TS5055 instead.", "JavaScript files inside `node_modules` are a separate setting: [`maxNodeModuleJsDepth`](/config/max-node-module-js-depth/) decides whether TypeScript reads them.", "Setting `\"allowJs\": false` while `\"checkJs\": true` is a config error in TypeScript 5.9 (TS5052): checking JavaScript needs JavaScript in the program." ], "faq": [ { "q": "Does allowJs check my JavaScript?", "a": "No. It makes `.js` files part of the program so their types are known. Errors inside them are reported only with `checkJs` on, or in a file that starts with `// @ts-check`." } ], "related": [ "config/check-js", "config/max-node-module-js-depth", "config/no-emit", "config/ts-nocheck" ], "sources": [ { "title": "TSConfig Reference: allowJs", "url": "https://www.typescriptlang.org/tsconfig/#allowJs", "publisher": "TypeScript" }, { "title": "TypeScript 1.8 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-1-8.html", "publisher": "TypeScript handbook" }, { "title": "Type Checking JavaScript Files", "url": "https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html", "publisher": "TypeScript handbook" } ], "updated": "2026-10-20" }, { "id": "maxNodeModuleJsDepth", "slug": "max-node-module-js-depth", "title": "maxNodeModuleJsDepth", "kind": "compilerOption", "option": "maxNodeModuleJsDepth", "category": "Checking JavaScript", "tsCategory": "JavaScript Support", "type": "number", "default": "0", "jsconfigDefault": "2", "flag": "--maxNodeModuleJsDepth", "officialDescription": "Specify the maximum folder depth used for checking JavaScript files from 'node_modules'. Only applicable with 'allowJs'.", "since": null, "startWith": "Keep the `jsconfig.json` default, `2`. Write `0` if reading JavaScript packages makes checking slow", "summary": "maxNodeModuleJsDepth sets whether TypeScript reads JavaScript packages in node_modules for types. jsconfig.json defaults it to 2, tsconfig.json to 0.", "intro": [ "When a package in `node_modules` ships only JavaScript, with no `.d.ts` files and no `@types` package, TypeScript can read its `.js` files to work out its types, JSDoc included. `maxNodeModuleJsDepth` sets how far it goes: `0` reads none of them, `2` reads the file your import resolves to and the JavaScript files it imports in turn, two levels deep.", "A file named `jsconfig.json` defaults it to `2`; a `tsconfig.json` defaults it to `0`. At `0`, importing such a package gives you `any`, and under [`noImplicitAny`](/config/no-implicit-any/) the import itself is an error (TS7016)." ], "examples": [ "config/max-node-module-js-depth-0", "config/max-node-module-js-depth-2" ], "sections": [ { "id": "what-the-examples-show", "heading": "What the two examples show", "body": [ "Both examples import the same small JavaScript-only package, `slugify-lite`, whose function has a JSDoc `@param {string}`. At depth `0`, TypeScript does not look inside the package: the import is TS7016 and `slugify` is `any`, so the wrong argument passes unnoticed. At the `jsconfig.json` default of `2`, TypeScript reads the package, picks up the JSDoc, and reports `slugify(42)`.", "The package also contains a mistake of its own, `words.lenght`. Neither example reports it: files read from `node_modules` this way lend their types to your code, but type errors inside them are not reported.", "One thing from inside a package can still show up. If the package imports another JavaScript package that lies past the depth limit, that import is reported as TS7016 in the package's own file, with a path into `node_modules`. Raising the depth by one, or installing types for the inner package, makes it go away." ] }, { "id": "packages-with-types", "heading": "Packages that ship types are not affected", "body": [ "When a package has a `types` entry, a `.d.ts` file next to its JavaScript, or an `@types` package, TypeScript uses that and this option changes nothing. It only matters for packages that are JavaScript all the way down." ] }, { "id": "when-to-lower-it", "heading": "When to set it to 0", "body": [ "Reading large JavaScript packages takes time, and inferred types from code that was never written for a checker can be loose or odd. If checking is slow or a dependency's inferred types get in the way, set `0` and give the package types another way: install its `@types` package, or write a one-line declaration such as `declare module \"slugify-lite\";` in a `.d.ts` file, which types it as `any` on purpose." ] } ], "gotchas": [ "The depth counts import steps, not folders or packages: depth `1` reads the file your import resolves to, and `2` also reads the JavaScript files that file imports, in the same package or another one.", "The option only applies when JavaScript files are allowed in the program ([`allowJs`](/config/allow-js/), which a `jsconfig.json` and `checkJs` both give you)." ], "faq": [ { "q": "Why does the same import work in my editor but fail with tsc?", "a": "Check the config file name. A `jsconfig.json` reads JavaScript packages two levels deep by default, a `tsconfig.json` does not, so the same import can be typed in one project and TS7016 in the other." } ], "related": [ "config/allow-js", "config/skip-lib-check", "config/no-implicit-any", "tags/import", "errors/ts7016" ], "sources": [ { "title": "TSConfig Reference: maxNodeModuleJsDepth", "url": "https://www.typescriptlang.org/tsconfig/#maxNodeModuleJsDepth", "publisher": "TypeScript" }, { "title": "jsconfig.json", "url": "https://code.visualstudio.com/docs/languages/jsconfig", "publisher": "Visual Studio Code docs" } ], "updated": "2026-10-20" }, { "id": "noEmit", "slug": "no-emit", "title": "noEmit", "kind": "compilerOption", "option": "noEmit", "category": "Checking JavaScript", "tsCategory": "Emit", "type": "boolean", "default": "false", "jsconfigDefault": "true", "flag": "--noEmit", "officialDescription": "Disable emitting files from a compilation.", "since": null, "startWith": "`\"noEmit\": true` (already the default in a `jsconfig.json`; write it anyway so the file says what it does)", "summary": "noEmit makes tsc check your files and write nothing. A jsconfig.json defaults it to true; a tsconfig.json with allowJs needs it, or tsc stops with TS5055.", "intro": [ "By default `tsc` checks your files and then writes output: `.js` files, and `.d.ts` files if you ask. In a JavaScript project your source already is the output, so all you want is the checking. `noEmit` turns the writing off.", "A file named `jsconfig.json` defaults `noEmit` to `true`. A `tsconfig.json` does not: with `allowJs` and no `outDir`, `tsc` would write each `.js` file over itself, so it stops with TS5055 for every file instead." ], "examples": [], "sections": [ { "id": "ts5055", "heading": "The error without it", "body": [ "This is what `tsc` prints for a `tsconfig.json` that sets `allowJs` (or `checkJs`) and neither `noEmit` nor `outDir`. The path is your own file; the message is the same in every project:" ], "snippets": [ { "lang": "sh", "code": "$ npx tsc -p tsconfig.json\nerror TS5055: Cannot write file '/home/ada/shop/src/cart.js' because it would overwrite input file." } ] }, { "id": "publishing-types", "heading": "When you do want output: .d.ts files", "body": [ "A package written in JavaScript can still ship types: [`declaration` with `emitDeclarationOnly`](/config/declaration/) writes `.d.ts` files and never touches your `.js`. Keep that in a second config file, so the everyday `jsconfig.json` stays a pure check with `noEmit`.", "If that second config `extends` your `jsconfig.json`, it inherits `noEmit: true`, the `jsconfig.json` default, even when the file never writes it. Set `\"noEmit\": false` in the second config, or `tsc` writes nothing and says nothing." ] } ], "gotchas": [ "`noEmit` silently wins over `emitDeclarationOnly`: TypeScript 5.9 reports no error for the pair, and no file is written.", "`noEmit` skips the writing, not any of the checking: the same errors are reported either way. For a faster run, see [`skipLibCheck`](/config/skip-lib-check/)." ], "faq": [ { "q": "Does noEmit change how my code runs?", "a": "No. With `noEmit` nothing is written, so what runs is exactly the JavaScript you wrote. Without it, tsc writes output files, and only those can differ from the code you wrote." } ], "related": [ "config/declaration", "config/allow-js", "config/check-js", "start/node-esm" ], "sources": [ { "title": "TSConfig Reference: noEmit", "url": "https://www.typescriptlang.org/tsconfig/#noEmit", "publisher": "TypeScript" }, { "title": "jsconfig.json", "url": "https://code.visualstudio.com/docs/languages/jsconfig", "publisher": "Visual Studio Code docs" } ], "updated": "2026-10-20" }, { "id": "declaration", "slug": "declaration", "title": "declaration and emitDeclarationOnly", "kind": "compilerOption", "option": "declaration", "alsoCovers": [ "emitDeclarationOnly", "declarationMap", "declarationDir" ], "category": "Checking JavaScript", "tsCategory": "Emit", "type": "boolean", "default": "false", "defaultNote": "(on when `composite` is on)", "flag": "--declaration", "officialDescription": "Generate .d.ts files from TypeScript and JavaScript files in your project.", "since": "3.7", "startWith": "In a second config used for publishing: `\"declaration\": true` with `\"emitDeclarationOnly\": true` and a `declarationDir`", "summary": "declaration and emitDeclarationOnly make tsc write .d.ts files from your JavaScript and its JSDoc, so a package written in JavaScript ships its own types.", "intro": [ "Since TypeScript 3.7, `tsc` can write declaration (`.d.ts`) files from JavaScript. Turn on `declaration` to write them, `emitDeclarationOnly` so that `tsc` writes only those and never a `.js` file, and `declarationDir` to put them in a folder of their own.", "The `.d.ts` files carry your JSDoc types in TypeScript syntax. Publish them with your package, point `package.json` at them, and anyone who installs the package gets your types in their editor and their `tsc`, whether they write TypeScript or checked JavaScript." ], "examples": [ "config/declaration-emit", "config/declaration-emit#types/geometry.d.ts" ], "sections": [ { "id": "second-config", "heading": "A second config for the .d.ts files", "body": [ "Your `jsconfig.json` keeps `noEmit` and stays the file your editor and `npm run lint` use. A second file extends it and turns writing on, for declarations only. The second example above is the file `tsc -p jsconfig.types.json` wrote from the first; this site runs that config again on every build, in memory, and the build fails if the output no longer matches the file shown." ], "snippets": [ { "file": "jsconfig.types.json", "from": "config/declaration-emit", "lang": "json", "code": "{\n \"extends\": \"./jsconfig.json\",\n \"compilerOptions\": {\n \"noEmit\": false,\n \"declaration\": true,\n \"emitDeclarationOnly\": true,\n \"declarationDir\": \"types\"\n }\n}" }, { "lang": "sh", "code": "npx tsc -p jsconfig.types.json" } ] }, { "id": "what-tsc-writes", "heading": "What tsc writes", "body": [ "Compare the two examples:" ], "list": [ "a `@typedef` becomes an exported `type`, so users of the package can import `Point` by name", "parameter and return types come from the JSDoc, or from inference where there is none (`distance` returns `number` without a `@returns` tag)", "class properties assigned in the constructor become declared properties", "an exported object literal (`origin`) is written as a `namespace` with one variable per property, which works the same for importers", "the JSDoc comments are copied into the `.d.ts`, so hovers in the user's editor show your descriptions" ] }, { "id": "declaration-dir-and-map", "heading": "declarationDir and declarationMap", "body": [ "`declarationDir` sends the `.d.ts` files to their own folder (here `types/`), which keeps them apart from your sources and easy to leave out of git. `declarationMap` also writes a `.d.ts.map` beside each file; with it, an editor's \"go to definition\" in a project that uses your package can land in your `.js` source instead of the `.d.ts`, provided the source files are published too." ] }, { "id": "package-json", "heading": "Pointing package.json at the types", "body": [ "TypeScript finds a package's types through its `package.json`. With an `exports` field, put a `types` condition first in each entry; TypeScript's 4.7 release notes say it should always come first." ], "snippets": [ { "file": "package.json", "from": "config/declaration-emit", "lang": "json", "code": "{\n \"type\": \"module\",\n \"exports\": {\n \".\": {\n \"types\": \"./types/geometry.d.ts\",\n \"default\": \"./src/geometry.js\"\n }\n },\n \"files\": [\"src\", \"types\"]\n}" } ] } ], "gotchas": [ "A second config that `extends` a `jsconfig.json` inherits `noEmit: true` even though the base file never writes it, and `noEmit` quietly wins: nothing is written and nothing is reported. Set `\"noEmit\": false` explicitly.", "`emitDeclarationOnly` needs `declaration` (or `composite`) on; on its own it is a config error.", "Types you never wrote down can surprise you: an untyped parameter becomes `any` in the `.d.ts`. Check the output before you publish it." ], "faq": [ { "q": "Should the .d.ts files be committed to git?", "a": "Either works. Many packages write them just before publishing (an npm `prepack` script that runs `tsc -p jsconfig.types.json`) and keep the folder out of git, so the files can never be stale." } ], "related": [ "start/library", "config/no-emit", "tags/typedef", "tags/import" ], "sources": [ { "title": "TSConfig Reference: declaration", "url": "https://www.typescriptlang.org/tsconfig/#declaration", "publisher": "TypeScript" }, { "title": "TSConfig Reference: emitDeclarationOnly", "url": "https://www.typescriptlang.org/tsconfig/#emitDeclarationOnly", "publisher": "TypeScript" }, { "title": "TSConfig Reference: declarationDir", "url": "https://www.typescriptlang.org/tsconfig/#declarationDir", "publisher": "TypeScript" }, { "title": "TSConfig Reference: declarationMap", "url": "https://www.typescriptlang.org/tsconfig/#declarationMap", "publisher": "TypeScript" }, { "title": "TypeScript 3.7 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html", "publisher": "TypeScript handbook" }, { "title": "TypeScript 2.8 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html", "publisher": "TypeScript handbook" }, { "title": "TypeScript 4.7 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-7.html", "publisher": "TypeScript handbook" }, { "title": "Creating .d.ts Files from .js files", "url": "https://www.typescriptlang.org/docs/handbook/declaration-files/dts-from-js.html", "publisher": "TypeScript handbook" } ], "updated": "2026-10-20" }, { "id": "skipLibCheck", "slug": "skip-lib-check", "title": "skipLibCheck", "kind": "compilerOption", "option": "skipLibCheck", "category": "Checking JavaScript", "tsCategory": "Completeness", "type": "boolean", "default": "false", "jsconfigDefault": "true", "flag": "--skipLibCheck", "officialDescription": "Skip type checking all .d.ts files.", "since": "2.0", "startWith": "`\"skipLibCheck\": true` (the `jsconfig.json` default), and turn it off now and then if you write `.d.ts` files of your own", "summary": "skipLibCheck skips checking every .d.ts file, your own included. A jsconfig.json turns it on by default, which can hide a typo in a .d.ts you wrote.", "intro": [ "Every `.d.ts` file in the program is normally checked along with your code: the ones in `node_modules`, and any you write yourself. `skipLibCheck` skips checking all of them. Their types are still read and used; only errors inside the `.d.ts` files go unreported.", "A file named `jsconfig.json` turns it on by default, which saves time and spares you errors in dependencies that you cannot fix. The cost shows up when you write a `.d.ts` of your own: a mistake in it is skipped too." ], "examples": [ "config/skip-lib-check-off", "config/skip-lib-check-on" ], "sections": [ { "id": "your-own-dts", "heading": "Your own .d.ts files are skipped too", "body": [ "The examples declare a global in `globals.d.ts` and misspell its type. With `skipLibCheck` off, `tsc` reports `Dat`; with it on, the typo goes through, `BUILD_DATE` quietly becomes `any`, and `BUILD_DATE.getFullYear()` in `main.js` is not checked at all.", "If your project has `.d.ts` files of its own (globals, `declare module` blocks for untyped packages, CSS module types), run `tsc -p jsconfig.json --skipLibCheck false` from time to time, or in CI, to check them." ] }, { "id": "dependencies", "heading": "Why skipping dependencies is usually right", "body": [ "Errors inside `node_modules/**/*.d.ts` usually come from two packages that declare the same global differently, or a types package written for a newer TypeScript. You cannot fix them in your project, and they say nothing about your code. Skipping them also makes every run faster." ] } ], "gotchas": [ "Your `.js` files are always checked in full; `skipLibCheck` only concerns `.d.ts` files.", "A `.d.ts` file that TypeScript writes for you (see [`declaration`](/config/declaration/)) is output, not input, so this option does not apply to it." ], "faq": [ { "q": "Is skipLibCheck safe to turn on?", "a": "For dependencies, yes; it is the default in a `jsconfig.json` and in the config `tsc --init` writes in TypeScript 5.9. The one risk is your own `.d.ts` files, which are skipped as well." } ], "related": [ "config/allow-arbitrary-extensions", "config/max-node-module-js-depth", "config/declaration", "config/check-js" ], "sources": [ { "title": "TSConfig Reference: skipLibCheck", "url": "https://www.typescriptlang.org/tsconfig/#skipLibCheck", "publisher": "TypeScript" }, { "title": "TypeScript 2.0 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html", "publisher": "TypeScript handbook" } ], "updated": "2026-10-20" }, { "id": "resolveJsonModule", "slug": "resolve-json-module", "title": "resolveJsonModule", "kind": "compilerOption", "option": "resolveJsonModule", "category": "Checking JavaScript", "tsCategory": "Modules", "type": "boolean", "default": "false", "defaultNote": "(on when `module` is `nodenext`, `node20` or `preserve`, or `moduleResolution` is `bundler`)", "flag": "--resolveJsonModule", "officialDescription": "Enable importing .json files.", "since": "2.9", "startWith": "Usually nothing: `nodenext` and `bundler` turn it on. With other `module` settings, write `\"resolveJsonModule\": true`", "summary": "resolveJsonModule lets you import .json files and types their contents. nodenext and bundler turn it on; ES modules still need the json import attribute.", "intro": [ "`resolveJsonModule` lets an `import` (or `require`) of a `.json` file resolve, and gives the result the type of the file's contents: `{ \"port\": 8080 }` becomes `{ port: number }`. A typo in a property name is then an error like any other.", "In TypeScript 5.9 it is on by default when `module` is `nodenext`, `node20` or `preserve`, or when `moduleResolution` is `bundler`, which covers the setups on this site. With `module` set to `node16`, `node18` or an `es` version alone, write it yourself." ], "examples": [ "config/resolve-json-module-nodenext", "config/resolve-json-module-off" ], "sections": [ { "id": "import-attribute", "heading": "ES modules need the json import attribute", "body": [ "Node.js loads a JSON file from an ES module only with an import attribute: `import config from \"./config.json\" with { type: \"json\" };`. Under `module: \"nodenext\"`, the checker holds you to it and reports a JSON import without one ([TS1543](/errors/ts1543/)). CommonJS files load JSON with `require(\"./config.json\")` and need no attribute." ], "examples": [ "config/resolve-json-module-attribute" ] }, { "id": "json-types", "heading": "What type a JSON import gets", "body": [ "TypeScript reads the file and widens the values: strings become `string`, numbers `number`, arrays of mixed values a union. It does not keep literal values, so `\"port\": 8080` is `number`, not `8080`. To type a config more precisely, annotate the import's use with a `@type` or check it with [`@satisfies`](/tags/satisfies/)." ] } ], "gotchas": [ "A big JSON file is read and typed on every check. For large data files that you import, a JSDoc `@type` on a value read with `fs` can be faster.", "The typed JSON is the file as it is on disk when you check. A JSON file that changes at deploy time can differ from what was checked." ], "faq": [ { "q": "Why do I get TS2732 for a JSON import?", "a": "Your `module` and `moduleResolution` do not turn `resolveJsonModule` on (for example `module: \"node18\"`, or a `bundler` setup that sets it to `false`). Add `\"resolveJsonModule\": true`." } ], "related": [ "config/module", "tags/type", "tags/satisfies", "start/node-esm" ], "sources": [ { "title": "TSConfig Reference: resolveJsonModule", "url": "https://www.typescriptlang.org/tsconfig/#resolveJsonModule", "publisher": "TypeScript" }, { "title": "TypeScript 2.9 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html", "publisher": "TypeScript handbook" }, { "title": "Modules: ECMAScript modules, JSON modules", "url": "https://nodejs.org/api/esm.html#json-modules", "publisher": "Node.js docs" } ], "updated": "2026-10-20" }, { "id": "allowArbitraryExtensions", "slug": "allow-arbitrary-extensions", "title": "allowArbitraryExtensions", "kind": "compilerOption", "option": "allowArbitraryExtensions", "category": "Checking JavaScript", "tsCategory": "Modules", "type": "boolean", "default": "false", "flag": "--allowArbitraryExtensions", "officialDescription": "Enable importing files with any extension, provided a declaration file is present.", "since": "5.0", "startWith": "`\"allowArbitraryExtensions\": true` when you import CSS, SVG or other non-JavaScript files and write a declaration file for each", "summary": "allowArbitraryExtensions lets a .css or other non-JavaScript import use a declaration file such as theme.d.css.ts. Without it, that import is TS6263.", "intro": [ "Browsers and bundlers can import files that are not JavaScript: CSS module scripts, JSON, SVG and more. TypeScript cannot read those files, but it can read a declaration file that describes one. For `./theme.css`, that file is named `theme.d.css.ts`, and `allowArbitraryExtensions` is the option that lets TypeScript use it.", "Without the option, TypeScript finds the declaration file and still refuses the import, with TS6263. The option arrived with TypeScript 5.0." ], "examples": [ "config/allow-arbitrary-extensions-off", "config/allow-arbitrary-extensions-on" ], "sections": [ { "id": "naming", "heading": "Naming the declaration file", "body": [ "Put `.d` before the file's own extension and `.ts` after it: `theme.css` → `theme.d.css.ts`, `logo.svg` → `logo.d.svg.ts`. The file describes what the import gives you; for a CSS module script that is one `CSSStyleSheet` as the default export." ] }, { "id": "css-module-scripts", "heading": "CSS module scripts in the browser", "body": [ "The examples use a CSS module script, a web platform feature: `import sheet from \"./theme.css\" with { type: \"css\" }` gives you a `CSSStyleSheet` to adopt into the document or a shadow root. Browser support is still uneven, so check MDN before relying on it without a bundler." ] }, { "id": "wildcard", "heading": "One declaration for every file of a kind", "body": [ "The other way to type such imports needs no option: a `.d.ts` file with `declare module \"*.css\" { … }` covers every CSS import at once. Use it when all imports of a kind look the same; use per-file declarations with `allowArbitraryExtensions` when each file exports something different (CSS modules with class names, for example)." ] } ], "gotchas": [ "An import that binds nothing, such as `import \"./theme.css\"`, is not checked at all unless [`noUncheckedSideEffectImports`](/config/no-unchecked-side-effect-imports/) is on.", "Declaration files you write are skipped by [`skipLibCheck`](/config/skip-lib-check/), the `jsconfig.json` default, so a mistake in `theme.d.css.ts` goes unreported." ], "related": [ "config/no-unchecked-side-effect-imports", "config/skip-lib-check", "config/resolve-json-module" ], "sources": [ { "title": "TSConfig Reference: allowArbitraryExtensions", "url": "https://www.typescriptlang.org/tsconfig/#allowArbitraryExtensions", "publisher": "TypeScript" }, { "title": "TypeScript 5.0 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-0.html", "publisher": "TypeScript handbook" }, { "title": "import attributes (with)", "url": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import/with", "publisher": "MDN" } ], "updated": "2026-10-20" }, { "id": "strict", "slug": "strict", "title": "strict", "kind": "compilerOption", "option": "strict", "category": "Strictness", "tsCategory": "Type Checking", "type": "boolean", "default": "false", "ts6Default": "`true` ([TypeScript 6.0](/typescript/6-0/#defaults))", "flag": "--strict", "officialDescription": "Enable all strict type-checking options.", "since": "2.3", "startWith": "`\"strict\": true` for new code; on an existing codebase, start without it and turn it on once the first errors are fixed", "summary": "strict turns on the strict type-checking family with one switch: nine options in TypeScript 5.9. What each catches in a .js file, and how to turn one back off.", "intro": [ "`strict` is a shorthand. It turns on a family of checks that can each be set on their own: in TypeScript 5.9 that is `noImplicitAny`, `strictNullChecks`, `strictFunctionTypes`, `strictBindCallApply`, `strictPropertyInitialization`, `strictBuiltinIteratorReturn`, `noImplicitThis`, `useUnknownInCatchVariables` and `alwaysStrict`.", "In a JavaScript project the two that change the most are [`noImplicitAny`](/config/no-implicit-any/), which makes every untyped parameter an error (TS7006), and [`strictNullChecks`](/config/strict-null-checks/), which makes you handle `null` and `undefined`. TypeScript 6.0 makes `strict` the default, so write it either way to keep a config meaning the same thing across versions." ], "examples": [ "config/strict-on", "config/strict-off" ], "sections": [ { "id": "the-family", "heading": "What strict turns on", "body": [ "Each member except `strictBuiltinIteratorReturn` has its own page with the same code checked both ways:" ], "list": [ "[`noImplicitAny`](/config/no-implicit-any/): parameters and values that could only be `any`", "[`strictNullChecks`](/config/strict-null-checks/): `null` and `undefined` as their own types", "[`strictFunctionTypes`](/config/strict-function-types/): parameter types checked when one function type is assigned to another", "[`strictBindCallApply`](/config/strict-bind-call-apply/): arguments passed through `bind`, `call` and `apply`", "[`strictPropertyInitialization`](/config/strict-property-initialization/): class fields that are typed but never set", "[`noImplicitThis`](/config/no-implicit-this/): `this` with no known type", "[`useUnknownInCatchVariables`](/config/use-unknown-in-catch-variables/): `catch (err)` as `unknown`", "[`alwaysStrict`](/config/always-strict/): every file parsed in strict mode", "`strictBuiltinIteratorReturn` (TypeScript 5.6): the value a finished built-in iterator returns is `undefined`, not `any`" ] }, { "id": "turning-one-off", "heading": "Turning one check back off", "body": [ "An option you set yourself wins over `strict`. `\"strict\": true` with `\"strictPropertyInitialization\": false` keeps every strict check except that one. That is a reasonable middle step for a codebase with many classes, and the order you list them in does not matter." ], "snippets": [ { "file": "jsconfig.json", "lang": "jsonc", "code": "{\n \"compilerOptions\": {\n \"checkJs\": true,\n \"noEmit\": true,\n \"strict\": true,\n // every strict check except this one\n \"strictPropertyInitialization\": false\n }\n}" } ] }, { "id": "upgrades", "heading": "The family grows", "body": [ "New TypeScript releases add checks to `strict`: `useUnknownInCatchVariables` joined in 4.4 and `strictBuiltinIteratorReturn` in 5.6. Upgrading TypeScript can therefore report errors in code that passed before, without any change to your config. Read the release notes of each minor version before you move to it." ] }, { "id": "not-in-strict", "heading": "Stricter options that strict leaves off", "body": [ "These are not part of `strict` and are worth considering once it passes: [`noUncheckedIndexedAccess`](/config/no-unchecked-indexed-access/), [`exactOptionalPropertyTypes`](/config/exact-optional-property-types/), [`noImplicitReturns`](/config/no-implicit-returns/), [`noFallthroughCasesInSwitch`](/config/no-fallthrough-cases-in-switch/), [`noImplicitOverride`](/config/no-implicit-override/), [`noUnusedLocals` and `noUnusedParameters`](/config/no-unused-locals/), [`noPropertyAccessFromIndexSignature`](/config/no-property-access-from-index-signature/) and [`noUncheckedSideEffectImports`](/config/no-unchecked-side-effect-imports/). The strict level of the [jsconfig generator](/tools/jsconfig-generator/) adds the first four." ] } ], "gotchas": [ "Without `strict`, a `.js` file is checked loosely: untyped parameters are `any` without complaint and `null` fits any type. Code can pass `npm run lint` and still fail on the first `undefined`.", "A config with no `strict` line means `false` in TypeScript 5.9 and `true` in 6.0. Write the line." ], "faq": [ { "q": "Should I turn on strict in an existing JavaScript project?", "a": "Eventually. Start with `checkJs` alone, fix what it finds, then turn on `strict` (or `noImplicitAny` first, since it reports the most). The [checkJs page](/config/check-js/) describes the order." }, { "q": "Is strict on by default?", "a": "Not in TypeScript 5.9, where it defaults to `false`. TypeScript 6.0 changes the default to `true`." } ], "related": [ "config/no-implicit-any", "config/strict-null-checks", "config/check-js", "errors/ts7006", "tools/jsconfig-generator" ], "sources": [ { "title": "TSConfig Reference: strict", "url": "https://www.typescriptlang.org/tsconfig/#strict", "publisher": "TypeScript" }, { "title": "TypeScript 2.3 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-3.html", "publisher": "TypeScript handbook" }, { "title": "TypeScript 4.4 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-4.html", "publisher": "TypeScript handbook" }, { "title": "TypeScript 5.6 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-6.html", "publisher": "TypeScript handbook" }, { "title": "TypeScript 6.0 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-6-0.html", "publisher": "TypeScript handbook" } ], "updated": "2026-10-20" }, { "id": "noImplicitAny", "slug": "no-implicit-any", "title": "noImplicitAny", "kind": "compilerOption", "option": "noImplicitAny", "category": "Strictness", "tsCategory": "Type Checking", "type": "boolean", "default": "false", "defaultNote": "(on when `strict` is on)", "ts6Default": "`true`, through `strict` ([TypeScript 6.0](/typescript/6-0/#defaults))", "flag": "--noImplicitAny", "officialDescription": "Enable error reporting for expressions and declarations with an implied 'any' type.", "since": null, "startWith": "Leave it to [`strict`](/config/strict/), or write `\"noImplicitAny\": true` on its own as the first step on an existing codebase", "summary": "noImplicitAny reports values TypeScript can only type as any. In a .js file, that is mostly parameters with no JSDoc type and no default (TS7006).", "intro": [ "When TypeScript cannot tell a value's type and has nothing to infer it from, it gives up with `any`, which turns checking off for that value. `noImplicitAny` makes that an error instead. In a JavaScript file the usual case is a function parameter without a JSDoc type, reported as [TS7006](/errors/ts7006/).", "It is part of [`strict`](/config/strict/) and reports more in a typical JavaScript codebase than any other member of the family, which makes it a good first step on its own." ], "examples": [ "config/no-implicit-any-on", "config/no-implicit-any-off" ], "sections": [ { "id": "what-it-reports", "heading": "What it reports in a .js file", "body": [ "The common ones:" ], "list": [ "a parameter with no `@param` type and no default value (TS7006), including callback parameters when the array they come from is itself untyped, as in the example", "a destructured parameter with no type (TS7031)", "an import of a JavaScript package with no types (TS7016); see [`maxNodeModuleJsDepth`](/config/max-node-module-js-depth/)" ] }, { "id": "what-it-does-not", "heading": "Variables that start empty", "body": [ "A variable that starts as `null`, `undefined` or `[]` is not left silently `any` under `strict`: TypeScript 5.9 follows what is assigned to it. Reading `a.length` after `let a = null` is [TS18047](/errors/ts18047/), and an empty array the checker cannot follow, because a closure captures it, is [TS7034](/errors/ts7034/). With `strict` off, such variables are `any`. Annotate them with `@type` when the type matters, for example `/** @type {string[]} */ const names = [];`." ] } ], "gotchas": [ "A parameter with a default value is typed from the default (`function f(n = 0)` makes `n` a `number`), so it is not reported.", "An explicit `{any}` in JSDoc is not \"implicit\" and is never reported; it is a deliberate opt-out." ], "faq": [ { "q": "Do I have to type every parameter?", "a": "Every parameter TypeScript cannot type from context. Callbacks passed to typed functions (`[1, 2].map((n) => n * 2)`) get their types from the function they are passed to and need no JSDoc." } ], "related": [ "config/strict", "tags/param", "errors/ts7006", "errors/ts7053", "errors/ts7031", "errors/ts7034" ], "sources": [ { "title": "TSConfig Reference: noImplicitAny", "url": "https://www.typescriptlang.org/tsconfig/#noImplicitAny", "publisher": "TypeScript" }, { "title": "Type Checking JavaScript Files", "url": "https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html", "publisher": "TypeScript handbook" } ], "updated": "2026-10-20" }, { "id": "strictNullChecks", "slug": "strict-null-checks", "title": "strictNullChecks", "kind": "compilerOption", "option": "strictNullChecks", "category": "Strictness", "tsCategory": "Type Checking", "type": "boolean", "default": "false", "defaultNote": "(on when `strict` is on)", "ts6Default": "`true`, through `strict` ([TypeScript 6.0](/typescript/6-0/#defaults))", "flag": "--strictNullChecks", "officialDescription": "When type checking, take into account 'null' and 'undefined'.", "since": "2.0", "startWith": "Leave it to [`strict`](/config/strict/); write `\"strictNullChecks\": false` only to turn this one check back off", "summary": "strictNullChecks makes null and undefined types of their own, so a value that may be missing is checked before use. It reports TS18047 and TS18048.", "intro": [ "Without `strictNullChecks`, `null` and `undefined` fit every type, so a value that may be missing looks like it is always there. With it on, they are types of their own: `Map.get` returns `number | undefined`, `document.querySelector` returns `Element | null`, and using the result without a check is an error (TS18048 for \"possibly undefined\", TS18047 for \"possibly null\").", "It is part of [`strict`](/config/strict/), arrived with TypeScript 2.0, and catches one of the most common runtime errors in JavaScript: reading a property of `undefined`." ], "examples": [ "config/strict-null-checks-on", "config/strict-null-checks-off" ], "sections": [ { "id": "narrowing", "heading": "Checking before use", "body": [ "Ordinary JavaScript checks are what the checker understands:" ], "list": [ "`if (price !== undefined)` or `if (price)` before the use", "optional chaining, `price?.toFixed(2)`, which gives `undefined` instead of throwing", "a fallback with `??`: `(prices.get(\"coffee\") ?? 0).toFixed(2)`", "`instanceof` for DOM lookups: `if (el instanceof HTMLInputElement)`" ] }, { "id": "no-bang", "heading": "There is no ! in JavaScript", "body": [ "TypeScript files can assert \"not null\" with a postfix `!`. JavaScript cannot; [the alternatives](/types/non-null-assertions/) are a check, a fallback, or a cast in JSDoc." ] } ], "gotchas": [ "A variable that starts as `null` is followed, not left `any`: after `let a = null`, reading `a.length` is TS18047 in TypeScript 5.9. Give it a `@type` when it will hold something else later, so that assignments are checked too.", "Turning this on in an existing codebase reports many errors at once; [`noImplicitAny`](/config/no-implicit-any/) first, then this, is the usual order." ], "related": [ "config/strict", "types/null-and-undefined", "types/non-null-assertions", "config/no-unchecked-indexed-access", "errors/ts18048", "errors/ts18047" ], "sources": [ { "title": "TSConfig Reference: strictNullChecks", "url": "https://www.typescriptlang.org/tsconfig/#strictNullChecks", "publisher": "TypeScript" }, { "title": "TypeScript 2.0 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html", "publisher": "TypeScript handbook" }, { "title": "Type Checking JavaScript Files", "url": "https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html", "publisher": "TypeScript handbook" } ], "updated": "2026-10-20" }, { "id": "strictFunctionTypes", "slug": "strict-function-types", "title": "strictFunctionTypes", "kind": "compilerOption", "option": "strictFunctionTypes", "category": "Strictness", "tsCategory": "Type Checking", "type": "boolean", "default": "false", "defaultNote": "(on when `strict` is on)", "ts6Default": "`true`, through `strict` ([TypeScript 6.0](/typescript/6-0/#defaults))", "flag": "--strictFunctionTypes", "officialDescription": "When assigning functions, check to ensure parameters and the return values are subtype-compatible.", "since": "2.6", "startWith": "Leave it to [`strict`](/config/strict/); write `\"strictFunctionTypes\": false` only to turn this one check back off", "summary": "strictFunctionTypes checks parameter types when one function type is assigned to another. A string-only function cannot stand in for one that gets numbers.", "intro": [ "When you assign a function to a variable or property with a function type, `strictFunctionTypes` checks that the function can handle every argument the type allows. A function that only accepts strings cannot stand in for one that may be called with a number; without the option, TypeScript lets it through.", "It is part of [`strict`](/config/strict/) and arrived with TypeScript 2.6." ], "examples": [ "config/strict-function-types-on", "config/strict-function-types-off" ], "sections": [ { "id": "methods", "heading": "Methods are exempt", "body": [ "TypeScript's 2.6 release notes say the stricter rule applies to function types, not to methods. In JSDoc that is the difference between a property holding a function, `{ log: (value: string) => void }`, which is checked strictly, and the method shorthand, `{ log(value: string): void }`, which is not. Prefer the property form in a `@typedef` when you want the check." ] } ], "gotchas": [ "The example's `log(42)` would call `toUpperCase` on a number at run time; with the option off, nothing reports it." ], "related": [ "config/strict", "types/function-types", "tags/callback", "tags/type" ], "sources": [ { "title": "TSConfig Reference: strictFunctionTypes", "url": "https://www.typescriptlang.org/tsconfig/#strictFunctionTypes", "publisher": "TypeScript" }, { "title": "TypeScript 2.6 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-6.html", "publisher": "TypeScript handbook" } ], "updated": "2026-10-20" }, { "id": "strictBindCallApply", "slug": "strict-bind-call-apply", "title": "strictBindCallApply", "kind": "compilerOption", "option": "strictBindCallApply", "category": "Strictness", "tsCategory": "Type Checking", "type": "boolean", "default": "false", "defaultNote": "(on when `strict` is on)", "ts6Default": "`true`, through `strict` ([TypeScript 6.0](/typescript/6-0/#defaults))", "flag": "--strictBindCallApply", "officialDescription": "Check that the arguments for 'bind', 'call', and 'apply' methods match the original function.", "since": "3.2", "startWith": "Leave it to [`strict`](/config/strict/); write `\"strictBindCallApply\": false` only to turn this one check back off", "summary": "strictBindCallApply checks the arguments you pass through bind, call and apply against the function's own parameters, instead of accepting anything.", "intro": [ "`fn.call(thisArg, ...args)`, `fn.apply(thisArg, args)` and `fn.bind(thisArg, ...args)` call a function indirectly. Without `strictBindCallApply`, TypeScript accepts any arguments there; with it, they are checked against the function's parameters, exactly as a direct call would be.", "It is part of [`strict`](/config/strict/) and arrived with TypeScript 3.2." ], "examples": [ "config/strict-bind-call-apply-on", "config/strict-bind-call-apply-off" ], "sections": [ { "id": "where-it-matters", "heading": "Where it shows up in JavaScript", "body": [ "Older JavaScript leans on these methods: borrowing array methods with `Array.prototype.slice.call(arguments)`, binding event handlers with `this.onClick.bind(this)`, and `apply` to spread an array of arguments. With the option on, each of those calls is checked, and `bind` returns a function with the remaining parameters typed." ] } ], "gotchas": [ "The first argument, `thisArg`, is checked against a `@this` type when the function has one; see [`@this`](/tags/this/)." ], "related": [ "config/strict", "tags/this", "config/no-implicit-this" ], "sources": [ { "title": "TSConfig Reference: strictBindCallApply", "url": "https://www.typescriptlang.org/tsconfig/#strictBindCallApply", "publisher": "TypeScript" }, { "title": "TypeScript 3.2 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-2.html", "publisher": "TypeScript handbook" } ], "updated": "2026-10-20" }, { "id": "strictPropertyInitialization", "slug": "strict-property-initialization", "title": "strictPropertyInitialization", "kind": "compilerOption", "option": "strictPropertyInitialization", "category": "Strictness", "tsCategory": "Type Checking", "type": "boolean", "default": "false", "defaultNote": "(on when `strict` is on)", "ts6Default": "`true`, through `strict` ([TypeScript 6.0](/typescript/6-0/#defaults))", "flag": "--strictPropertyInitialization", "officialDescription": "Check for class properties that are declared but not set in the constructor.", "since": "2.7", "startWith": "Leave it to [`strict`](/config/strict/); write `\"strictPropertyInitialization\": false` only to turn this one check back off", "summary": "strictPropertyInitialization reports a class field that has a type but is never set, by an initializer or in the constructor (TS2564).", "intro": [ "A class field declared with a type, such as `/** @type {string} */ owner;`, promises that every instance has a string there. `strictPropertyInitialization` checks the promise: the field needs an initializer (`owner = \"\";`) or an assignment in the constructor. If it has neither, it starts out `undefined`, and TypeScript reports TS2564.", "It is part of [`strict`](/config/strict/), arrived with TypeScript 2.7, and needs `strictNullChecks`, which `strict` also turns on." ], "examples": [ "config/strict-property-initialization-on", "config/strict-property-initialization-off" ], "sections": [ { "id": "fixes", "heading": "Three ways to fix it", "body": [ "In a `.js` file:" ], "list": [ "give the field a value: `owner = \"\";`", "assign it in the constructor, as the example does for `balance`", "say it may be missing: `/** @type {string | undefined} */ owner;`" ] }, { "id": "constructor-only", "heading": "Properties set only in the constructor", "body": [ "Many JavaScript classes never declare fields; they assign `this.owner = owner` in the constructor, and TypeScript infers the property from that. Such properties are always set, so this check has nothing to report about them." ] } ], "gotchas": [ "TypeScript files can write `owner!: string` to say \"set elsewhere\". JavaScript has no such syntax; use one of the fixes above.", "Without `strictNullChecks` the option is a config error." ], "related": [ "config/strict", "config/strict-null-checks", "tags/type", "tags/class", "errors/ts2564" ], "sources": [ { "title": "TSConfig Reference: strictPropertyInitialization", "url": "https://www.typescriptlang.org/tsconfig/#strictPropertyInitialization", "publisher": "TypeScript" }, { "title": "TypeScript 2.7 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-7.html", "publisher": "TypeScript handbook" }, { "title": "Type Checking JavaScript Files", "url": "https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html", "publisher": "TypeScript handbook" } ], "updated": "2026-10-20" }, { "id": "noImplicitThis", "slug": "no-implicit-this", "title": "noImplicitThis", "kind": "compilerOption", "option": "noImplicitThis", "category": "Strictness", "tsCategory": "Type Checking", "type": "boolean", "default": "false", "defaultNote": "(on when `strict` is on)", "ts6Default": "`true`, through `strict` ([TypeScript 6.0](/typescript/6-0/#defaults))", "flag": "--noImplicitThis", "officialDescription": "Enable error reporting when 'this' is given the type 'any'.", "since": "2.0", "startWith": "Leave it to [`strict`](/config/strict/); write `\"noImplicitThis\": false` only to turn this one check back off", "summary": "noImplicitThis reports this inside a function where TypeScript cannot tell what it is (TS2683). In JavaScript, a @this tag says what it is.", "intro": [ "Inside a plain `function`, `this` depends on how the function is called, so TypeScript often cannot know its type and falls back to `any`. `noImplicitThis` reports those uses (TS2683), so a typo in `this.nmae` cannot slip through.", "It is part of [`strict`](/config/strict/) and arrived with TypeScript 2.0. Methods in classes and object literals are not affected: there `this` has a known type." ], "examples": [ "config/no-implicit-this-on", "config/no-implicit-this-off" ], "sections": [ { "id": "fix", "heading": "Saying what this is", "body": [ "Add a [`@this`](/tags/this/) tag, `/** @this {{ name: string, price: number }} */`, or move the function into the object or class as a method, where `this` is typed for you." ] } ], "gotchas": [ "A function that assigns to `this.something` is treated as a constructor function in a `.js` file, so its `this` is the instance and is never reported.", "Arrow functions take `this` from where they are written, so they are never the cause." ], "related": [ "tags/this", "types/this-parameter", "config/strict", "config/strict-bind-call-apply", "errors/ts2683" ], "sources": [ { "title": "TSConfig Reference: noImplicitThis", "url": "https://www.typescriptlang.org/tsconfig/#noImplicitThis", "publisher": "TypeScript" }, { "title": "TypeScript 2.0 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html", "publisher": "TypeScript handbook" } ], "updated": "2026-10-20" }, { "id": "useUnknownInCatchVariables", "slug": "use-unknown-in-catch-variables", "title": "useUnknownInCatchVariables", "kind": "compilerOption", "option": "useUnknownInCatchVariables", "category": "Strictness", "tsCategory": "Type Checking", "type": "boolean", "default": "false", "defaultNote": "(on when `strict` is on)", "ts6Default": "`true`, through `strict` ([TypeScript 6.0](/typescript/6-0/#defaults))", "flag": "--useUnknownInCatchVariables", "officialDescription": "Default catch clause variables as 'unknown' instead of 'any'.", "since": "4.4", "startWith": "Leave it to [`strict`](/config/strict/); write `\"useUnknownInCatchVariables\": false` only to turn this one check back off", "summary": "useUnknownInCatchVariables types the err in catch (err) as unknown instead of any, so you check what was thrown before using err.message (TS18046).", "intro": [ "JavaScript can `throw` any value, not only `Error` objects, so the variable in `catch (err)` can be anything. With `useUnknownInCatchVariables` it is typed `unknown`, and using `err.message` without a check is an error (TS18046). Without it, `err` is `any` and nothing is checked.", "It joined [`strict`](/config/strict/) with TypeScript 4.4, so code that passed under `strict` before 4.4 can report errors after an upgrade." ], "examples": [ "config/use-unknown-in-catch-variables-on", "config/use-unknown-in-catch-variables-off" ], "sections": [ { "id": "fix", "heading": "Checking what was thrown", "body": [ "Narrow before you use it: `err instanceof Error ? err.message : String(err)`. That handles `throw \"oops\"` and other non-errors too, which is the point of the check." ] } ], "gotchas": [ "Promise rejections in `.catch((err) => …)` callbacks are typed `any` regardless of this option; the option covers `catch` clauses only." ], "related": [ "config/strict", "types/any-and-unknown", "types/type-predicates", "errors/ts18046" ], "sources": [ { "title": "TSConfig Reference: useUnknownInCatchVariables", "url": "https://www.typescriptlang.org/tsconfig/#useUnknownInCatchVariables", "publisher": "TypeScript" }, { "title": "TypeScript 4.4 release notes", "url": "https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-4.html", "publisher": "TypeScript handbook" } ], "updated": "2026-10-20" }, { "id": "alwaysStrict", "slug": "always-strict", "title": "alwaysStrict", "kind": "compilerOption", "option": "alwaysStrict", "category": "Strictness", "tsCategory": "Type Checking", "type": "boolean", "default": "false", "defaultNote": "(on when `strict` is on)", "ts6Default": "`true`: setting it to `false` is deprecated ([TypeScript 6.0](/typescript/6-0/#deprecated))", "flag": "--alwaysStrict", "officialDescription": "Ensure 'use strict' is always emitted.", "since": "2.1", "startWith": "Leave it to [`strict`](/config/strict/); write `\"alwaysStrict\": false` only to turn this one check back off", "summary": "alwaysStrict parses every file in JavaScript strict mode, so reserved words such as package cannot be names. ES modules are strict anyway.", "intro": [ "JavaScript has a strict mode with tighter rules: some words are reserved, `with` is forbidden, deleting a plain variable is an error. ES modules and class bodies are always strict; older scripts are strict only with a `\"use strict\"` line. `alwaysStrict` makes TypeScript parse every file as strict and report what strict mode forbids, such as `package` used as a variable name (TS1212).", "It is part of [`strict`](/config/strict/). Its other job, writing `\"use strict\"` into output files, does not apply with `noEmit`. TypeScript 6.0 treats all code as strict and deprecates turning it off." ], "examples": [ "config/always-strict-on", "config/always-strict-off" ], "sections": [ { "id": "who-it-affects", "heading": "Which files it affects", "body": [ "Only scripts: files that are not modules, such as classic `