Acknowledgement

• I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

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

Executive summary

• Some changes to our TypeScript code are required to fix compilation.
  Specifically, we anticipate adding a significant number of @ts-ignore
  comments throughout our codebase.

Impact summary

The Announced column indicates whether we were able to connect the observed
change with a section in the TS5.9-beta announcement.

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

Changes which were announced

Editor UX improvements

We anticipate our internal VSCode users will appreciate the following changes

• Summary Descriptions in DOM APIs
• Expandable Hovers (Preview)
• Configurable Maximum Hover Length

Other changes

The following changes are largely irrelevant in our codebase and we don't have
anything to add about them:

• Minimal and Updated tsc --init
• Support for import defer.
• Support for --module node20
• Cache Instantiations on Mappers
• Avoiding Closure Creation in fileOrDirectoryExistsUsingSource

Unannounced changes

We found a surprising number of breaking changes given that none were explicitly
mentioned in the beta announcement. While we generally expect some breakages
from .d.ts changes, a few of the changes outlined below had wide enough impact
that it would probably be worth calling them out directly in the release
announcement.

ArrayBuffer no longer assignable from typed arrays (#60150)

Previously ArrayBuffer was a supertype of the various typed arrays
(Uint8Array, etc), but #60150 made it a separate unrelated type. This broke a
large number of assignments and direct downcasts (across ~0.08% of our builds).
We will roll out @ts-ignore suppressions for these.

Element.textContent getter no longer nullable

The textContent getter for Element was narrowed to never return null.
While this seems mostly innocuous, it ended up breaking a large number of tests
(0.03% of all builds, and a higher proportion of tests) that wrote expectations
like expect(el.textContent).toContain(someNumber). This passed previously
because Jasmine's expect fallback for an unknown subject was very permissive
in its toContain method, whereas narrowing to a non-nullable string meant that
toContain also expected exactly a string. We will suppress these with
@ts-ignore.

Reported error lines changed between property and top-level objects/arrays

TS2345 (and rarely a few others) errors moved from being reported on the
relevant property to instead being reported at the start ({) of the object
literal containing the property. This broke 0.02% of our builds that had a
@ts-ignore invalidated by the moved error message. We will move the
suppressions to the correct line to work around this.

There were also a few cases where TS2322 changed from being reported at the
start of the object to being reported on an individual property.

HTMLElement.autocorrect property added

This .d.ts addition broke some assumptions made by Polymer and made
CustomElement no longer a subclass of HTMLElement, breaking assignments and
direct casts in 0.005% of our builds. While we suspect it might have been better
as boolean|undefined (or optional), we will fix the issues by updating the
Polymer types to be compatible, and our internal Polymer maintainers will fix
any remaining issues.

Parameter decorators can no longer forward-reference arguments

We use legacy decorators with a custom transpilation that only accesses
parameter decorator arguments lazily. A small fraction of users ran afoul of
this new check (0.003% of builds). This typically looks like

@Injectable({providedIn: 'root'})
export class FooService {
  constructor(@Inject(OTHER_SERVICE) private readonly otherService?: OtherService) {}
}
export const OTHER_SERVICE = new InjectionToken<OtherService>('MY_OTHER_SERVICE');

While the errors are spurious in our codebase, they're trivially fixable by
manually hoisting the late definition to the top of the file.

Improved detection of non-nullable LHS for ?? (#59217?)

A small handful of cases (0.001% of builds) run afoul of the improved detection.
This is legitimately suspicious code and we will suppress the new errors with
@ts-ignore until code owners can clean them up.

New declarations push some types over the complexity limit

We have a few internal projects with extremely complex types. We've informed
them that they will see type checking degradation when the new version rolls out
with @ts-ignore suppressions.

PR #61668

This change caused a handful of type inference changes and regressions, which
were quite difficult to diagnose, since it seemed like some types simply changed
out from under us. In some cases, they were quite complex type transformations,
but in at least one case it was actually a pretty simple inference of a function
returning Promise.all on a basic tuple of statically-known types that was very
surprising to have broken - we have reported this in #62071.

Removal of AbortSignal.abort static method

This API is considered Baseline Widely Available and it's unclear why the
declaration disappeared. We had a few use sites depending on it and will
need to work around until it returns.

Other lib.d.ts Changes

A handful of additions conflicted with existing DefinitelyTyped usage, other
cases of more local custom declarations, or interface implementations.