TypeScript 6.0 RC | lilting channel

TypeScript 6.0 RC was released in March 2026. Although it is a major version upgrade from the TS 5.x series, the highlight is not so much the new features but the fact that it has “implemented all the disruptive changes that had been postponed until now”. 6.0 is designed as a bridge version to TypeScript 7.0 (a native version rewritten in Go), and 7.0 will completely remove options that were deprecated in 6.0.

@@CODE0@@

Major changes to default settings

In 6.0, the default values of tsconfig will change all at once.

Settings	Old default	New default
`strict`	false	true
`module`	commonjs	esnext
`target`	es2020	es2025
`types`	All automatic enumeration
`rootDir`	Inference	.(current directory)

Among them, the biggest impact is making strict: true the default and changing types: []. With strict enabled by default, there are cases where existing projects are full of type errors. Changing types is even more effective. Previously, all type definitions under node_modules/@types were automatically loaded, but from 6.0 onwards, they are not loaded unless explicitly enumerated.

@@CODE1@@

rootDir is also worth paying attention to. In projects that have previously relied on inference, an unintended location may be interpreted as rootDir.

Deprecated options

The following options were deprecated in 6.0. Removed in 7.0.

deprecated option	reason/alternative
`target: es5`	Deprecation of ES5 downcompilation
`--downlevelIteration`	—
`--moduleResolution node` (old node10)	Use bundler or node16/nodenext
`--module amd / umd / systemjs / none`	Unification to ESM
`--baseUrl`	Replaced by `paths`
`--moduleResolution classic`	—
`esModuleInterop: false` / `allowSyntheticDefaultImports: false`	Fixed to true
`--alwaysStrict false`	Due to strict default
`--outFile`	Leave it to Bandra
`module` keyword (old syntax for namespace)	Use `namespace`
`asserts` (old syntax of import attribute)	Use `with`

Replacing --baseUrl with paths.

{
  "compilerOptions": {
    "paths": {
      "@app/*": ["./src/app/*"],
      "@lib/*": ["./src/lib/*"]
    }
  }
}

During the transition period, you can continue to use the deprecated option during 6.0 by setting ignoreDeprecations.

{
  "compilerOptions": {
    "ignoreDeprecations": "6.0"
  }
}

However, in TypeScript 7.0, this option itself will disappear, so a fundamental response is unavoidable.

New language features

`this` Improved type inference for functions without

Changed type inference to be less context sensitive if the function does not reference this. Method syntax and arrow function handling are unified.

callIt({
  consume(y) { return y.toFixed(); },  // 以前は型エラーになるケースがあった
  produce(x: number) { return x * 2; },
});

Node.js `#/` subpath import support

{
  "imports": {
    "#": "./dist/index.js",
    "#/*": "./dist/*"
  }
}

Add type definition for ES2025 API

RegExp.escape: Escape function for regular expressions
Promise.try: Wrapper that can also catch exceptions thrown synchronously
Iterator methods (map, filter, take, etc.)
Set methods (union, intersection, difference, etc.)

Temporal API support

The Temporal proposal, which has been stuck in Stage 3 for a long time, has finally been added to the type definition. It is an API that fundamentally solves the design problems of the Date object (time zone, daylight saving time, calendar support, etc.), and what has been discussed on a yearly basis becomes actually usable.

let yesterday = Temporal.Now.instant().subtract({ hours: 24 });

Map/WeakMap upsert (getOrInsert)

Implemented the upsert proposal that entered ECMAScript Stage 4. The operation “If the key does not exist, insert and retrieve it, if it exists, return the existing value” can be written in one line.

// 旧来の書き方
if (!map.has(key)) map.set(key, defaultValue);
const value = map.get(key);

// 6.0以降
const value = map.getOrInsert(key, defaultValue);

DOM type integration

lib.dom.iterable and lib.dom.asynciterable, which were previously managed as separate lib files, have been integrated into lib.dom. It is no longer necessary to specify each one from the lib enumeration.

`--stableTypeOrdering` flag

Flag to fix an issue where type ID assignments depend on declaration order. This is to prevent the type check result from changing due to code rearrangement, and is also intended to smooth the transition from 6.0 to 7.0.

CLI changes

Passing a file name on the command line in a directory where tsconfig.json is present now results in an error. If you want to ignore it, use --ignoreConfig.

Tried with Astro project

I confirmed the impact in tsconfig.json of this blog (Astro 5 + TypeScript 5.9). Since it inherits Astro’s strict preset, the settings are as follows.

{
  "extends": "astro/tsconfigs/strict",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": { "@/*": ["./src/*"] },
    "strictNullChecks": true
  }
}

target: ESNext, module: ESNext, moduleResolution: Bundler, strict: true, esModuleInterop: true are already set inside Astro’s strict preset. Comparing with the default changes in 6.0:

Settings	6.0 New Defaults	This Project	Impact
`strict`	true	true (Astro preset)	None
`module`	esnext	ESNext (Astro preset)	None
`target`	es2025	ESNext (Astro preset)	None
`moduleResolution`	—	Bundler (Astro preset)	None
`esModuleInterop`	Fixed true	true (Astro preset)	None
`baseUrl`	deprecated	Configuring `"."`	Action required

Only baseUrl is caught. However, since paths has already been written, you can simply delete the baseUrl: "." line. Since the path of paths is written as a relative path to ./src/*, the resolution destination remains the same even if baseUrl is not present.

@types There are three packages in use: @types/better-sqlite3, @types/hast, and @types/node. In 6.0, the default of types changes to [] (empty), but this may have an effect if types is not explicitly specified on the Astro preset side. If you get a type not found error when building, just add "types": ["node"].

It is unified by ESM and there is no require(). CommonJS related deprecated also has no effect. Astro + Vite projects generally play well with 6.0.

Relationship with TypeScript 7.0

TypeScript 7.0 is planned to be released immediately after 6.0, and 7.0 will be a native implementation rewritten in Go. You can currently try the preview version in the @typescript/native-preview package. Eliminating dependencies on options deprecated in 6.0 now will minimize the cost of migrating to 7.0. If the scale of the project is large, a realistic way to proceed would be to temporarily overcome it with ignoreDeprecations: "6.0" and then gradually replace it.