TypeScript 4.2 Syntax Support

[bradzacher]

https://devblogs.microsoft.com/typescript/announcing-typescript-4-2-beta/

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.

---

Leading/Middle Rest Elements in Tuple Types

let foo: [...string[], number];

foo = [123];
foo = ["hello", 123];
foo = ["hello!", "hello!", "hello!", 123];

let bar: [boolean, ...string[], boolean];

bar = [true, false];
bar = [true, "some text", false];
bar = [true, "some", "separated", "text", false];

This will not require any AST changes.

Smarter Type Alias Preservation

This will not require any AST changes.

Having a quick look on ts-ast-viewer, it looks like the types API continues to work as it did previously, but there is additional information stored on the type (the internal origin property) which stores the de-normalised union.

I don't think this will impact any of our rules, but we'll find out with tests.

Template Literal Expressions Have Template Literal Types

This will not require any AST changes.

Having a quick look on ts-ast-viewer, it just means the types will be template literal types.

I don't think we've gone through and fully checked compat with our rules and template literal types yet - but given this will increase the prevalence of template literal types, we might have to go through and check our rules.

abstract Construct Signatures

let Ctor: abstract new () => HasArea = Shape;

This will require AST changes.

--noPropertyAccessFromIndexSignature

This will not require any AST changes.

The dot-notation extension rule will require work so that it can coexist with this compiler option (#3104).

Other changes with no impact to us

• Stricter Checks for the in Operator (The in Operator No Longer Allows Primitive Types on the Right Side)
  • Once we eventually have syntax errors in our parser (Parsing: strictly enforce the produced AST matches the spec and enforce most "error recovery" parsing errors #1852) we could expose this error
• --explainFiles to understand why files have been included in a program
• Relaxed Rules Between Optional Properties and String Index Signatures
• Declare Missing Helper Function
• noImplicitAny Errors Apply to Loose yield Expressions
• Type Arguments in JavaScript Are Not Parsed as Type Arguments
• TypeScript’s lift Callback in visitNode Uses a Different Type

[sosukesuzuki]

Hi, I'm implementing abstract constructor signatures for Babel (babel/babel#12628). Are you already thinking about new AST? In current Babel's PR, abstract property is added to TSConstructorType.

[bradzacher]

abstract constructor signatures ... abstract property is added to TSConstructorType.

It's a little bit of a breaking change on the side of lint fixers - because they now have to handle the new case, and if they don't then they'll break code.

Hmmm... we also have TSConstructorType and TSFunctionType, which semantically mean different things, but syntactically are identical, aside from the leading new.
Should we follow suit here and add TSAbstractConstructorType?

Another example - we have TSAbstractClassProperty and ClassProperty (and the same for MethodDefinition).

I'm not sure what is better.

I think it's probably best to just go with adding the abstract: boolean property to TSConstructorType.

[sosukesuzuki]

I think it's probably best to just go with adding the abstract: boolean property to TSConstructorType.

I think so too. However, I concern that if adding abstract: boolean to TSConstructorType is a breaking change, then typescript-eslint will have to do a major version upgrade for it. Are you okay?

Also I'm personally not positive about adding TSAbstractConstructorType...

[bradzacher]

semver gets kind of fuzzy in this regard.

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API.

But exactly what the definition of a "backwards incompatible change" isn't well defined.

From an AST POV - this is purely a feature additon (minor bump), and for all consumption cases it's consistent and non-breaking.

It's only breaking for those that are making code emission decisions based off of the AST.
In the ESTree repo, they strive for a delineation between the AST consumption use case, and the "eslint fixer" use case - effectively ignoring the latter when making changes.

I don't know - it's the first time I've had to make one of these decisions 😅 .
I'm comfortable going with just adding the property and not treating it as a breaking change here.

[sosukesuzuki]

Thank you. So let's add abstract: boolean to TSConstructorType 👍

[tao-cumplido]

the abstract keyword seems to be only valid in callback types but not in callback interfaces

type A = abstract new () => object;

interface B {
    abstract new (): object; // 'abstract' modifier cannot appear on a type member. (1070)
}

would this restriction have implications on AST design?

[bradzacher]

No. Method signatures are an entirely different AST node to function types.

[Torhal]

The noPropertyAccessFromIndexSignature flag, if turned on and code is changed to appease tsc, causes the @typescript-eslint/dot-notation rule to be triggered.

I'm mentioning it here because that flag is under the Other changes with no impact to us section.

[bradzacher]

As that is not syntax, I have filed #3104. Happy to accept a PR!
This issue is mostly for noting the syntax changes we need to support.

[Torhal]

As that is not syntax, I have filed #3104. Happy to accept a PR!
This issue is mostly for noting the syntax changes we need to support.

That's what I get for skimming the issue title and focussing on 4.2... Thanks, and sorry about that!

[armano2]

i started working on this and there seem to be some additional changes:
microsoft/TypeScript#37421 - namespaced jsx is now supported

new node will be needed JSXNamespacedName