Google feedback on TypeScript 4.3-rc

[h-joo]

This GitHub issue contains feedback on the TS 4.3-rc release from the team that is responsible for keeping Google's internal software working with the latest version of TypeScript.

Executive summary

• We do not expect to have significant difficulty in upgrading Google to TS 4.3.
• Some changes to our TypeScript code are required to make it compile with TS 4.3.
  • More than half of the new errors reported by TS 4.3-rc are clearly related to announced changes.
  • About 25% of new TS error messages report legitimate source code errors that were previously missed by TS 4.2.
  • About 25% of new TS error messages seem to have been caused by the improvement/different behavior in the control flow analysis.
  • Detail sections below explain the changes to our code we expect to make to unblock the upgrade.

Impact summary

Change description	Announced	Libraries affected
lib/d.ts Changes	yes	0.011%
Bracket indexing after existence check in objects	no	0.003%
'never' type inference on variables which have a type explicitly annotated	no	0.003%
Errors on Always truthy or falsy checks	no	0.002%
Union Enums Cannot Be Compared to Arbitrary Numbers	yes	0.002%
Require type on class attributes	no	~0
Assignability check failure between compatible types	no	~0
Always-Truthy Promise Checks	yes	~0
Disallow duplicate identifier in classes	no	~0
Assignability check fails on union of enum and numeric	no	~0

The Announced column indicates whether we were able to connect the observed change with a section in the TS4.3-rc announcement.

The following sections give more detailed explanations of the changes listed above.

Changes which were announced

lib/d.ts Changes

We support the typing improvements. Generally it's clear what's changing.

Our fix will be casting away the errors in existing code.

We observed the following breakdown within this category :

• window.opener related breakages : 65%
• Object.defineProperty return type changes : 20%
• Compiler interface changes : 4%
• Others : 10%

Changes which were not announced

Bracket indexing after existence check in objects

• Github issue link

This triggers when the type of the variable is known to not have a certain property. Doing a dynamic check for that property, followed by a bracket access to that property fails.

Our fix would be casting arrays into another type to silence the errors.

'never' type inference on variables which have a type explicitly annotated

• Github issue link

This happens when a literal is assigned to a union type and can be modified as a side effect of function calls. The compiler recognizes that it can only be the literal that has been assigned in the beginning, as it doesn't see the side effects.

Our fix would be casting the type, so that the control flow analysis sees the type as the user intended

Assignability check failure between compatible types where only the type of the property is different

• Github issue link

This triggers when the assignability check needs to be done on the property level and when one is a (null|otherType) and the other is null

interface A<T> { field : T | null; } type assignTo = A<string[]>;
interface assignToExtended extends A<string[]> {}

function foo () : A<null> { return { field : null }; }

// This consistently fails on all versions.
const a : assignTo = foo();

// This used to work, but now starts to fail from 4.3.1-rc const b :
const assignToExtended = foo();

Our fix would be to cast the compatible types arrays into another type to silence the errors.

Assignability check fails on union of enum and numeric

• Github issue link

This triggers when a variable is compared to a numeric literal where the type of the variable is a union of enum and that exact numeric literal that it is being compared to.

Our fix will be to cast the first assignment to the variable with its own type as proposed in the issue.

enum A {
    A0 = 0,
    A1 = 1,
}
function foo(param) {
  // before : const abc : (A | -1) = param;
  // fixed : casted to '(A | -1)' to not make the control flow analysis confused
  const abc = param as (A | -1);
  // now okay
  if (abc === -1) {}
}