JS with Types Start

Comment directive

// @ts-check

  • Applies to the whole file
  • Since TypeScript 2.3

// @ts-check is a comment that opts one JavaScript file into checking. Put it before the first line of code and the file is checked as if checkJs were on, using the rest of your config (strict, lib, types and so on). It arrived together with checkJs, with TypeScript 2.3.

It is the gentle way to start: no config change, one file at a time, and editors such as VS Code honor it with no jsconfig.json at all. Once most files have it, switch to checkJs and mark the exceptions with // @ts-nocheck instead.

At a glance

Write // @ts-check
Applies to The whole file, when it comes before the first line of code
With checkJs on Nothing more: every .js file is checked already
With checkJs off Checks this one file, with the options in your config

Examples

report.js Error confirmed 5.9.3 TypeScript 5.9.3, run 21 October 2026: report.js(5,22): error TS2551: Property 'lenght' does not exist on type 'string[]'. Did you mean 'length'? 6.0.3 TypeScript 6.0.3, run 21 October 2026: the same as 5.9.3. report.js(5,22): error TS2551: Property 'lenght' does not exist on type 'string[]'. Did you mean 'length'? 7.0.2 TypeScript 7.0.2, run 21 October 2026: the same as 5.9.3. report.js(5,22): error TS2551: Property 'lenght' does not exist on type 'string[]'. Did you mean 'length'? checked 21 October 2026 
// @ts-check
const names = ["Ada", "Grace", "Katherine"];

console.log(`${names.lenght} people`);error TS2551: Property 'lenght' does not exist on type 'string[]'. Did you mean 'length'?
One file opted in with // @ts-check.
jsconfig.json for this example 
{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": false,
    "noEmit": true,
    "target": "es2022",
    "module": "nodenext",
    "types": []
  },
  "include": ["*.js"]
}

Where it has to go

Anywhere before the first line of code: after a license header or other comments is fine, after an import or any statement is too late, and the comment is then ignored without a warning. If a file has both // @ts-check and // @ts-nocheck, the later of the two wins.

Without a jsconfig.json

When no config file applies, an editor checks a file with // @ts-check using its own default options, which need not match what tsc would use. A project that cares about the result should still have a jsconfig.json, so the editor and tsc -p jsconfig.json in CI agree.

Gotchas

  • .ts files are always checked; the comment does nothing there.
  • A comment after the first statement is ignored without a warning, so a misplaced // @ts-check looks like a file with no errors.

Questions

Should I use // @ts-check or checkJs?

checkJs for a project you control: every file is checked and new files cannot slip through. // @ts-check while migrating an existing codebase file by file, or for a single script that lives outside any project.

  • jsconfig.json option

    checkJs

    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.

  • Comment directive

    // @ts-nocheck

    // @ts-nocheck at the top of a file turns checking off for that file while checkJs stays on for the rest. The file's types still reach its importers.

  • Comment directive

    // @ts-expect-error

    // @ts-expect-error silences the errors on the next line, and reports TS2578 once that line has none, so a fixed problem cannot leave a stale comment.

  • Quick start

    Deno

    Type-check JavaScript with Deno: deno check, checkJs and JSDoc, a jsconfig.json Deno reads next to package.json, and when Deno checks types.

  • Editor setup

    VS Code

    Set up VS Code for type-checked JavaScript: how it reads jsconfig.json, using the project's TypeScript version, and listing errors in files you have not opened.

Sources

Last reviewed 20 October 2026.