TypeScript 4.5 Support

[bradzacher]

https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-rc/

This issue is just to track all of the new features and their implementation state in this project.
As with all releases, we will not necessarily to support all features until closer to the full release when everything the features are stabilised.

Please be patient.

type Modifiers on Import and Export Names

import { someFunc, type BaseType } from "./some-module.js";
//                 ^^^^^^^^^^^^^

type T = 1;
export { type T };

This will require AST changes.

Babel: babel/babel#13802

• PR: feat(typescript-estree): support type-only module specifiers #4076

This will require updates to scope analysis:

• PR: feat(scope-manager): support TS4.5 import/export specifier kind #4234

This will require updates to rules:

• consistent-type-exports
  • PR: feat(eslint-plugin): [consistent-type-exports] support TS4.5 inline export specifiers #4236
• consistent-type-imports
  • PR: feat(eslint-plugin): [consistent-type-imports] support TS4.5 inline import specifiers #4237
• no-shadow
  • PR: feat(eslint-plugin): [no-shadow] support TS4.5 inline import specifiers #4239

Private Field Presence Checks

class Person {
    #name: string;
    constructor(name: string) {
        this.#name = name;
    }

    equals(other: unknown) {
        return other &&
            typeof other === "object" &&
            #name in other &&
//          ^^^^^^^^^^^^^^
            this.#name === other.#name;
    }
}

This will require AST changes.

ESTree: https://github.com/estree/estree/blob/master/es2022.md#binaryexpression

• PR: feat(typescript-estree): support private fields in-in syntax #4075

Import Assertions

import obj from "./something.json" assert { type: "json" };

This will require AST changes.

ESTree: https://github.com/estree/estree/blob/master/stage3/import-assertions.md

• PR: feat(typescript-estree): support Import Assertions #4074, fix(visitor-keys): add missing import assertion keys #4178

lib.d.ts Changes

Will require regeneration of @typescript-eslint/scope-manager types.

• PR: feat(scope-manager): update lib types #4240

Better Editor Support for Unresolved Types

This might break a few tests due to the type printer printing something that isn't any.

---

Other changes with no impact to us

• Supporting lib from node_modules
• The Awaited Type and Promise Improvements
• Template String Types as Discriminants
• --module es2022
• Tail-Recursion Elimination on Conditional Types
• Disabling Import Elision
• Faster Load Time with realPathSync.native
• New Snippet Completions
• Better Editor Support for Unresolved Types
• Inference Changes from Awaited
• Compiler Options Checking at the Root of tsconfig.json
• Restrictions on Assignability to Conditional Types

[bradzacher]

4.5rc has released
https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-rc/

[bradzacher]

4.5 has officially released
https://devblogs.microsoft.com/typescript/announcing-typescript-4-5/

[Josh-Cena]

In terms of consistent-type-imports / consistent-type-exports — I'm most looking forward to these features and am willing to contribute if I have the bandwidth. Consider this:

import React, {ComponentType} from 'react';

I think it would just be autofixed as:

import React, {type ComponentType} from 'react';

Instead of the old way with two lines of import right? Should we also autofix those that were split into two lines to make this rule happy and merge them into one line?

[bradzacher]

I think it would just be autofixed as ... Instead of the old way with two lines of import right?

I think that should be an option (default false), not the default for a few reasons:

• not everyone will be on 4.5, so we don't want to use broken syntax.
  • could do version detection, but I think for now we should just not jump the gun for now so we don't have differing behaviours.
• not everyone likes the inline syntax, and some people like to separate type imports from value imports.
• the existing behaviour is to do non inline, so to change the style in a minor would be a breaking change.

Should we also autofix those that were split into two lines to make this rule happy and merge them into one line?

That would be the concern of a rule like no-duplicate-imports, not consistent-type-imports.

Happy to accept a PR to add an option to do that - please raise a separate issue for that so we can track it - it's an additional feature request and isn't required for 4.5 support so it isn't covered by this issue.