TS 4.7 syntax regression: ';' expected.

[MichaelMitchell-at]

Bug Report

🔎 Search Terms

typeof syntax missing semicolon generic

🕗 Version & Regression Information

This changed between versions 4.6.2 and 4.7.0-beta

⏯ Playground Link

Playground link with relevant code

💻 Code

This is a minimal repro, for a real-world example of a breakage, see https://raw.githubusercontent.com/pmndrs/react-spring/master/packages/types/interpolation.d.ts

interface Example {
  (a: number): typeof a

  <T>(): void
}

🙁 Actual behavior

Syntax errors:

Type 'number' has no signatures for which the type argument list is applicable.

Return type of call signature from exported interface has or is using private name 'T'.

';' expected.

🙂 Expected behavior

No syntax errors

[Josh-Cena]

This is new ASI hazard introduced by instantiation expressions, because typeof a<T> is now a valid parse.

[MichaelMitchell-at]

This is new ASI hazard introduced by instantiation expressions, because typeof a<T> is now a valid parse.

I'm surprised that instantiation expression syntax can be used in a type context.

[Josh-Cena]

That's one of the chief purposes of instantiation expressions. For example, you can do ReturnType<typeof fn<string>> to get string from fn: <T>() => T extends string ? string : number

[RyanCavanaugh]

We need to add this to the blog post

[MichaelMitchell-at]

Just going to throw out an overly-wishful idea that could maybe save the TS community a lot of effort when breaking syntax changes come out. What if:

• the TS compiler shipped with a set of transforms to convert old supported syntax into new supported syntax, i.e. the opposite of downlevel-dts.
• use typesVersions in package.json to detect what TS versions a package was originally written for (maybe fallback to using package release date as a heuristic since most packages don't specify typesVersions)
• when tsc typechecks your project it automatically transforms third-party package files in-memory using the information from above when type-checking them

[RyanCavanaugh]

Just going to throw out an overly-wishful idea...

To set expectations, I don't think we were even aware of the fact that this was a breaking change 🙃. It's quite rare for this to happen.

[MichaelMitchell-at]

True, though something like that idea would also be really helpful for enabling exactOptionalPropertyTypes, since it's really difficult when third-party types are written with exactOptionalPropertyTypes being disabled in mind.

[ahejlsberg]

We could consider requiring no line breaks between typeof xxx and a type argument list. Very simple fix, doesn't seem like an unreasonable rule.

[nicolo-ribaudo]

Note that requiring no line break is consistent with what TS already does in other cases (I was going to open an issue suggesting to require it to make ASI consistent, then I found this issue already opened!):

// valid, a type alias followed by a JSX element
type A = b
<c></c>

// this should be valid too
type A = typeof b
<c></c>