• Typescript 4.2 Released, Improves Types and Developer Experience
  • Originally written by Bruno-Couriol
  • Translation from: The Gold Project
  • This article is permalink: github.com/xitu/gold-m…
  • Translator: Hoarfroster
  • Proofreader: Lsvih, Zenblo

The TypeScript team has just released TypeScript 4.2! This version of TypeScript has more flexible type annotations, stricter checks, additional configuration options, and a number of other major changes. We can now use Rest arguments anywhere in the tuple’s type definition (instead of just at the end)! Type aliases are no longer extended in type error messages, giving us developers a much better experience.

TypeScript 4.2 supports Rest Parameters anywhere in a tuple type:

type T1 = [...string[], number];  // Any string and a number
type T2 = [number. boolean[],string.string];  // A number, followed by any Boolean, followed by two strings
Copy the code

In previous versions, Rest parameters could only be used at the end, for example, type T1 = [number,…string[]]; , so we cannot use a strong type definition for a parameter set that contains Rest parameters but ends with a fixed type parameter.

function f1(. args: [...string[].number]) {
    const strs = args.slice(0, -1) as string[];
    const num = args[args.length - 1] as number;
    // ...
}

f1(5);
f1('abc'.5);
f1('abc'.'def'.5);
f1('abc'.'def'.5.6);  // Error
Copy the code

F1 takes an indefinite number of string arguments, followed by an argument of type number. We can now define exactly the type of the F1 parameter. Of course, we still can’t use more than one Rest parameter, and the optional element can’t come before the required element or after the Rest of the elements. The following parameter type definitions are supported:

type Tup3<T extends unknown[], U extends unknown[], V extends unknown[]> = [...T, ...U, ...V];

type TN1 = Tup3<[number].string[], [number>;// [number, ...string[], number]
// Optional element following required element
type TN2 = Tup3<[number], [string?], [boolean>;// [number, string | undefined, boolean]
type TN3 = Tup3<[number].string[], [boolean? ] >;// [number, ...(string | boolean | undefined)[]]
type TN4 = Tup3<[number].string[].boolean[] >;// [number, ...(string | boolean)[]]
type TN5 = Tup3<string[].number[].boolean[] >;// (string | number | boolean)[] 
Copy the code

TypeScript 4.2 also gives us a better development experience when using type aliases:

The previous example showed that the type alias BasicPrimitive in some cases be carved or standardization (for example for number | string | Boolean type), but not now. The release notes also highlight improvements to the TypeScript developer experience in different places:

You can avoid displaying some of the dreaded long type definitions – type aliases are now commonly found in quick messages and signature help, as well as in translated.d.ts file output. This can make TypeScript more newbie friendly.

The abstract modifier can now be used on constructor signatures, for example:

abstract class Shape {
    abstract getArea(): number;
}

// This is a mistake! We cannot instantiate an abstract class
new Shape();

interface HasArea {
    getArea(): number;
}

// This is a mistake! We cannot assign an abstract constructor type to a constructor type that is not abstract
let Ctor: new  () => HasArea = Shape;

// This is great
let Ctor: abstract new () => HasArea = Shape;
/ / ^ ^ ^ ^ ^ ^ ^ ^
Copy the code

The new semantics of the abstract modifier allow us to write the constructor for mixin Factories in a way that supports abstract classes.

We can now explicitly mark deconstructed variables as unused, whereas some developers used to write:

const [Input, /* state */./* actions */, meta] = input 
Copy the code

For better maintenance and readability, instead of using this:

const [Input, , , meta] = input 
Copy the code

Developers can now precede unused variable names with an underscore:

const [Input, _state, _actions, meta] = input
Copy the code

The new TypeScript version also provides more stringent checks on the in operator: “foo” in 42 will trigger a type error. The TypeScript not call a function to check now applies to && and | | expression. When type has a string index sign, noPropertyAccessFromIndexSignature flag no longer USES the dot operator (such as a person. The name), let’s enable an attribute access, The explainFiles compiler flag (e.g. TSC –explainFiles command) allows the compiler to produce more detailed information about the files being solved and processed:

TS_Compiler_Directory/out/lib/lib. Es5. Which s Library referenced via'es5' from file 'TS_Compiler_Directory/out/lib/lib. Es2015. Which s'TS_Compiler_Directory/out/lib/lib. Es2015. Which s Library referenced via'es2015' from file 'TS_Compiler_Directory/out/lib/lib. Es2016. Which s'. More Library References... foo.ts Matched by include pattern'* * / *' in 'tsconfig.json'
Copy the code

TypeScript 4.2 also includes some significant changes: Type parameters in JavaScript are not parsed as type parameters, which means that valid TypeScript code f

(100) is parsed into a JavaScript file (f

(100) according to the JavaScript specification. At the same time, the.d.ts extension cannot be used in import paths (for example, import {Foo} from “./foo.d.ts;). , and we can substitute any of the following:
)>

import {Foo} from "./foo.js";
import {Foo} from "./foo";
import {Foo} from "./foo/index.js";
Copy the code

TypeScript 4.2 implements the goal of writing JavaScript more accurately at any size or location, but TypeScript adds complexity with every distribution. As one developer points out:

Concerns over TypeScript’s numerous updates have raised the question of whether TypeScript has become too complex to understand all of its problems, as C++ has done.

There are other major changes and new features in TypeScript 4.2, and developers are welcome to read the full release notes. TypeScript is open source software under the Apache 2 license, and we encourage contributions and feedback through TypeScript projects on GitHub that follow the TypeScript Contribution Guidelines and Microsoft’s Open Source Code of Conduct.

If you find any errors in the translation or other areas that need improvement, you are welcome to revise and PR the translation in the Gold Translation program, and you can also get corresponding bonus points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

Diggings translation project is a community for translating quality Internet technical articles from diggings English sharing articles. The content covers the fields of Android, iOS, front end, back end, blockchain, products, design, artificial intelligence and so on. For more high-quality translations, please keep paying attention to The Translation Project, official weibo and zhihu column.