Description
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!",<
7A7A
/span> "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
inOperator 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
--explainFilesto understand why files have been included in a program- Relaxed Rules Between Optional Properties and String Index Signatures
- Declare Missing Helper Function
noImplicitAnyErrors Apply to LooseyieldExpressions- Type Arguments in JavaScript Are Not Parsed as Type Arguments
- TypeScript’s lift Callback in visitNode Uses a Different Type