TypeScript 7.0 for JavaScript users

A native tsc

Install typescript 7 and run tsc as before. Parsing, checking and writing output run in parallel; the experimental --checkers option sets how many type-checking threads run (4 by default), --builders does the same for project references, and --singleThreaded turns parallelism off. Watch mode was rebuilt on a new file watcher.

npm install --save-dev typescript@7
npx tsc -p jsconfig.json

The 6.0 defaults, and no deprecated options

7.0 checks like TypeScript 6.0 with stableTypeOrdering on: strict on, types empty, module: esnext, noUncheckedSideEffectImports on. The options 6.0 deprecated are now errors, among them baseUrl, moduleResolution: node and classic, target: es5, esModuleInterop: false and alwaysStrict: false. TypeScript 7.0.2 reports them as removed: TS5102 for a removed option, TS5108 for a removed value, such as allowSyntheticDefaultImports: false on the esModuleInterop page.

JSDoc that 7.0 no longer reads

The port's list of changes says JavaScript files are now analyzed like TypeScript files with a different syntax for types, and drops most Closure-specific support. For JSDoc that means:

• A value's name is not a type. {defaults} must become {typeof defaults} (TS2749 otherwise).
• @enum is an ordinary tag. Type the values with a @typedef over the object, as below.
• @class and @constructor no longer make a function a constructor, and constructor functions with prototype assignments are not modeled: write a class.
• Closure function types such as {function(string): number} are not parsed; write {(s: string) => number}.
• {?} is not a type (write {any}), and the postfix ! is not supported.
• A JSDoc rest type, {...number}, means number[] and no longer makes a parameter a rest parameter; write ...values in the parameter list. Using arguments no longer lets callers pass extra values either.
• Smaller changes from the same list: a @param tag no longer types more than one function, a @type cast no longer narrows the variable it is written on (as a cast in a .ts file does not), and @overload on an arrow function or function expression is ignored.

export const Status = /** @type {const} */ ({ Draft: "draft", Live: "live" });

/** @typedef {(typeof Status)[keyof typeof Status]} StatusValue */

/** @param {StatusValue} status */
export function label(status) {
  return status.toUpperCase();
}

CommonJS patterns

The same list narrows what TypeScript reads in CommonJS files:

• A module uses either module.exports = … or module.exports.name = …, not both.
• const mod = module.exports aliases and this.name = … at the top level of a module are not read as exports; write exports.name.
• require("fs").readFile is not followed; destructure instead: const { readFile } = require("fs").
• Nested exports such as exports.a.b = 1 need exports.a declared first.

Declaration files written from JavaScript

Declaration output and JavaScript parsing were largely rewritten, and the port's notes say .d.ts files written from .js files will differ from 6.0's; matching the old output exactly is not a goal. A library that ships types written from its JSDoc should compare its .d.ts files before releasing with 7.0. 6.0's stableTypeOrdering previews the new ordering.

Editors and tools

VS Code has a TypeScript 7 extension that becomes the default, with commands to switch between the 7 and 6 language servers; Visual Studio picks 7 per workspace; other editors talk to the new language server over LSP. 7.0 ships without a programmatic API, which 7.1 is meant to bring, so tools that call TypeScript as a library keep using 6.0 through the @typescript/typescript6 package and its tsc6 command. Editor support for Vue, Svelte, Astro, MDX and Angular templates still needs 6.0.