TypeScript 6.0 beta makes implicit project inputs explicit

TypeScript's next performance transition begins with deciding what belongs to a project. The TypeScript 6.0 beta announcement, published on February 11, changes defaults for ambient type inclusion and output layout. The planned Go implementation remains TypeScript 7.0. This beta prepares existing projects while retaining the current JavaScript compiler implementation.

The distinction matters because an upgrade can expose configuration assumptions before it delivers the native compiler's expected speed. TypeScript 6.0 is a transition release with compatibility work of its own. Treating it as merely another syntax update misses why the team is changing longstanding defaults.

My appreciation for TypeScript comes largely from the web ecosystem it supports. Careful framework code can produce interfaces whose behavior and appearance fit together well. That work benefits from tooling that understands the intended project without collecting unrelated declarations merely because they happen to be installed nearby.

Ambient declarations become a deliberate input

The beta changes the default types value to an empty array. Previously, the compiler automatically included packages under node_modules/@types in the global scope. That convenience made globals available without explicit imports, but it could also bring a large number of declarations into a project unintentionally.

The announcement identifies flattened dependencies in multi-project workspaces as a source of that cost. A project can encounter type packages that entered the installation through indirect dependencies. The compiler's effective global environment then becomes broader than the application's own requirements suggest.

An explicit array narrows that input. A Node-targeted project needing Node globals can state that requirement directly.

{
  "compilerOptions": {
    "types": ["node"]
  }
}

This setting concerns packages included in the global scope. It does not mean ordinary imported dependencies disappear from the type checker. Keeping those mechanisms distinct explains why an upgrade can produce missing-global errors while imported application modules still resolve.

For a test project, its required global declarations may differ from the production project's. The configuration can express that difference instead of relying on a shared installation to make every runner's globals visible everywhere. The result is a more specific statement about which environment each compiler invocation describes.

The beta provides types: ["*"] to restore enumeration. That preserves a compatibility path, but it also preserves the broader input selection. The announcement recommends explicit names for predictability and performance. The wildcard makes the old choice visible rather than leaving it implicit.

The output root stops depending on the whole file set

The default rootDir now becomes the directory containing tsconfig.json. Earlier behavior inferred a common directory from non-declaration input files. That inference made the output layout depend on the source set the compiler discovered.

The beta announcement gives a practical symptom. A project that previously emitted dist/index.js may now emit dist/src/index.js when its configuration sits above src. Explicitly setting rootDir to ./src retains the intended relative layout for that project.

This is separate from deciding which files belong in the program. The announcement explains that the earlier inference could require loading and parsing a project before determining whether a file belonged to it. The new default removes that inferred common-root calculation from the normal configured case.

A stable output layout matters to consumers outside the compiler. A package entry point or deployment command names an output path. If that path depended on an inferred root, the configuration contained an unstated assumption. The beta turns it into a value that can be written next to outDir.

The compiler invocation must acknowledge configuration

Another change concerns tsc with explicit file arguments. Previously, an invocation such as tsc example.ts ignored a tsconfig.json in the directory. The beta reports an error in that situation instead of silently compiling the file without the configuration.

The new --ignoreConfig flag expresses an intentional standalone compilation. This is a useful distinction for a small experiment whose settings should differ from the surrounding repository. It also prevents a troubleshooting command from accidentally becoming evidence about a project configuration it never loaded.

These changes share a concrete property. Installed ambient packages, inferred output roots, and command-line file selection previously influenced compilation through behavior that was easy to overlook. The beta makes those choices more visible at the configuration or invocation point.

The native transition has an earlier history

Anders Hejlsberg's March 2025 native-port announcement established the plan for a Go implementation and the separate TypeScript 6 and 7 lines. It tied the work to project-load latency and checking performance, including editor scenarios. The February beta follows that roadmap rather than announcing the native implementation as complete.

That direction is consistent with what I value in TypeScript tooling. Faster checking is useful when it preserves a complete view of the code under development. Reducing accidental inputs also improves the meaning of that view. In this beta, the immediate migration is a more explicit account of the globals and paths that the project actually requires.