Google employees Tucao TypeScript: I think your type checking is not very good

Google employee named Evan Martin recently published in GitHub repo TypeScript in to TypeScript the "Tucao" (that is, to mention a Issue ), said Tucao may not be appropriate, to be precise on  TypeScript 3.5 using feedback.

Although TypeScript 3.5 release for three months ( the latest stable version 3.6 has been released by the end of last month ), but the Google development team was recently upgraded to version 3.5. After a period of use, the developers feel compelled to speak, so there is high quality of this feedback. Yes, here that the project is being used by all Google - that only a code repository and has billions of lines of code in Google.

background

Project development teams face is to have billions of lines of code Google, within the team, all members are using the same version of TypeScript and the same group across all platforms compiler flags (compiler flag), To upgrade, members will help for everyone to upgrade these tags.

Evan said, he and everyone else would expect a new version of TypeScript upgrade can bring some improvements. For example, Evan said he hoped to welcome and improvement of the standard library, even if it may mean that similar but not compatible with the need to remove from the definition of the code base. But the team found that the extra workload TypeScript 3.5 upgrade to bring a lot more than the previous upgrade.

Evan believes version 3.5, there are three major changes to make the upgrade becomes especially difficult, he believes these changes are most of its objectives, and aimed at improving the type checking, but he also believes that TypeScript team always understood type checking but the trade-off between security and efficiency.

Evan hope TypeScript this large codebase using feedback to help TypeScript team to better assess future similar situation, and offer some suggestions.

Take a look at three major changes in version 3.5 Evan said impact to the team below.

Generic implicit default value (Implicit default for generics)

This feature belongs to the 3.5 release of destructive change , Evan think there cause problems that are not related to work with generic code that the code does. For example, assume there are some code having Promise resolved, but do not care values to be parsed Promise:

function dontCarePromise() {
  return new Promise((resolve) => {
    resolve();
  });
}

Because generics are not bound, in the 3.4  Promise<{}> code will be changed to 3.5 Promise<unknown>. If the user of this function anywhere to write this type of Promise:

const myPromise: Promise<{}> = dontCarePromise();

This will result in a type error.

In addition, there is called a "return only generic (return-only generics)" mode, in this case, only the generic function to use it in any mode return type. The problem here is the cause, there will be a lot of type inference accident. For example, in the case where only returns a generic, the following code:

expectsString(myFunction());

Can legally reconstructed in the following manner:

const x = myFunction();
expectsString(x);

But in the end we find that it does not work.

Boolean filters filter (Boolean)

TypeScript 3.5 Changing the Booleantype of the function, the function will be assigned to forcedboolean from

function Boolean(value?: any): boolean;

Changes to

function Boolean<T>(value?: T): boolean;

Both may look very similar. But imagine, a function that takes a predicate and returns an array of filters, and use the same code as above:

function filter<T>(predicate: (t: T) => boolean): (ts: T[]) => T[];
const myFilter = filter(Boolean);

In version 3.4, by definition, T from the  any changes myFilter, and becomes a of  any[]the  any[] function. But in the 3.5 version, T leaving only generics.

Collection ( the Set )

In TypeScript 3.4, the following code:

const s = new Set();

It will return a  Set<any>. TypeScript 3.5 but there was a change, so that  lib.es2015.iterable.d.ts with removal  any effect, and cause the generic changes described above, and the type is derived  unknown.

This change ultimately difficult to repair, because in the end the type of errors sometimes falls far short of the actual problem. For example, in the following code:

class C {
  gather() {
    let s = new Set();
    s.add('hello');
    return s;
  }
  use(s: string[]) { … }
  demo() {
    this.use(Array.from(this.gather()));
  }
}

We'll receive  Array.from prompt type of error, but the actual need to fix that  new Set().

At last

Evan said they were very satisfied with TypeScript, the use of feedback just hope that they will team to provide some reference in the design of new features to better develop TypeScript.