6.0 Deprecation Candidates (original) (raw)

We're planning the following set of deprecations for TypeScript 6.0. While TypeScript 6.0 will follow the same "soft deprecation" strategy as TypeScript 5.0, these options will be removed entirely in TypeScript 7 (the native TypeScript port).

Please let us know if these would be unreasonably disruptive for you by leaving a comment here.

In the two years since TypeScript 5.0, we've seen ongoing shifts in the JavaScript ecosystem:

Modernization

Newer Default Values

--outFile removed

Removed for implementation simplicity's sake.
External bundlers or transpilers do this job faster, better, and more configurably.

Removed Flag Values

This also implies dropped support for the amd-module directive, which will no longer do anything.

Legacy module syntax

Early versions of TypeScript used this construct

which was later aliased to the modern preferred form

module blocks are a potential ECMAScript proposal which would conflict with this syntax, so we're fully deprecating using module where namespace is expected.

The ambient module declaration form

declare module "some-module" {

remains fully supported.

See #61450 for RWC results

DOM tweaks

"lib": ["dom"] will now automatically include dom.iterable as well

Performance

libReplacement defaults to false

This flag incurs a large number of failed module resolutions, which in turn increases the number of locations we need to watch under --watch and LSP scenarios. In a new project, libReplacement never does anything until other explicit configuration takes place, so it makes sense to turn this off by default.

rootDir default

Currently rootDir, if not specified, is inferred based on the set of root files found (unless composite is set).
In 6.0, the default rootDir will always be the directory containing the tsconfig.json file.
If a non-config-based build occurs, rootDir will be inferred as before.

This lets us go faster because we don't need to compute the set of input files in order to determine the structure of the output directory.

types default

Currently, the types value defaults to "enumerate everything in node_modules/@types". This is potentially very expensive as a normal repo setup these days might transitively pull in hundreds of @types packages. Modern projects almost always need only @types/node, @types/jest, or a handful of other common global-affecting packages.

In 6.0, the default types value will be [].
This will affect many projects; you will likely need to add "types": ["node"] or a few others.

This will prevent projects from unintentionally pulling in hundreds or even thousands of unneeded declaration files at build time. Many projects we've looked at have improved their build time anywhere from 20-50% just by setting types appropriately.

Cross-namespace value qualification

In TypeScript today, you can write this code:

namespace Foo { export const bar = 10;
}

// Possibly in another (non-module) file const bar = "hello"; namespace Foo { const x = bar; }

In this program, the initializer of x actually refers to Foo.bar (value 10), not the outer const bar (value "hello").
Depending on your background, this is somewhere between "expected" and "a huge surprise".
It's also a big implementation problem for us, since it means name resolution of bar in x = bar can't proceed until all files in the program are known.

In TypeScript 6.0, this behavior will be removed, and bar will refer to the outer const (or be a name resolution error if that variable isn't there).

enum merging

It's been possible to merge value enums, but this functionality is very rarely used since it can't cross module boundaries.

See #61262 for RWC run.

alwaysStrict

The alwaysStrict flag refers to inference of the "use strict"; directive. In TypeScript 6.0, all code will be assumed to be in "strict mode", which is a set of JS semantics that mostly affects syntactic corner cases around reserved words.

This lets us be faster because it's no longer necessary to look ahead or repase on constructs like

which is legal "sloppy mode" referring to a variable named await. This also reduces the number of flags which possibly prevent sharing of source files between projects with different compiler settings.

See #61888 for RWC run; we found one codebase that used static as a parameter name.

Behavorial Tweaks

no-default-lib directives

No one really understands what this does or uses it correctly.

Specifying commandline files when tsconfig.json exists is an error

Currently if you run tsc foo.ts in a folder where a tsconfig.json exists, the tsconfig file is completely ignored. This is very confusing. The intended meaning of this is also unclear; it could be that you want to use the compilerOptions of the config but not the files and/or include and/or exclude.

For clarity, in 6.0, if you run tsc in a directory with a tsconfig.json, an error will be issued instead.

tsconfig.json is present but will not be loaded if files are specified on the commandline. Use --ignore-config to skip this error

See also #27379

JS Modernization

The asserts keyword was added to the JS language and then removed; in 6.0 this will be a parse error. See also #58453

Conditional imports/exports fallback lookups are deprecated; see #50762
If your name isn't Andrew Branch and you know what this even is about, please let us know.

See also #51000 / #51424 / #51909 / #54500