Disallow newline after `as` after function instantiation

[nicolo-ribaudo]

🔎 Search Terms

as newline ASI function type parameters spec difference

🕗 Version & Regression Information

• This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play?#code/CYUwxgNghgTiAEAzArgOzAFwJYHtVJxwB4AVAPgAoBKALnhIChRJYFUoBbEAZwAcowCAGLwA3vBAAPXjhgZ4GAJ68EAcxAYMIGPAC88KKkXwAvk3DQ48CBoPc6hxQwY35kvQRzwi8AEzwyOwYhADp1TW0GIA

💻 Code

let x = foo < 2 > as
F.getter

🙁 Actual behavior

It is parsed as

let x = foo<2> as F.getter;

🙂 Expected behavior

It should be parsed as

let x = (foo < 2) > as;
F.getter;

Additional information about the issue

The linked code is valid JavaScript code, and it would be great if tsc could parse as such.

I know that TS is not in general a syntactic superset of JavaScript, but both Babel and SWC already parse this example (when in TS mode) according to JS semantics. We could change our parsers, but it would be better if this ambiguity could be solved in tsc.

cc @kdy1

[nicolo-ribaudo]

Additionally, TS reports a syntax error on these two valid JS examples:

let x = foo < 2 > as;
F.getter;

let x = foo < 2 > as
const y = 2;

[nmain]

This seems similar to #33639 and related linked issues there.

[ethanresnick]

I think this is probably a good idea — the fewer parsing differences between JS and TS the better, imo — but I want to point out that prettier frequently reformats code to put the type-being-asserted on its own line. E.g.,

const res = foo<2> as SomeLongTypeName | SomeOtherLongTypeName | SomeFinalTypeName;

will be formatted as:

const res = foo<2> as
  | SomeLongTypeName
  | SomeOtherLongTypeName
  | SomeFinalTypeName;

So maybe the rule change here could be narrower than disallowing new lines after as entirely?

Regardless, if some change happens here, prettier will probably need to be updated too.

[jakebailey]

FWIW esbuild parses this like TypeScript currently does: https://jakebailey.dev/esbuild-playground/#v3=DYUwLgBAHhC8EDMD2SIB4ICYID4IEMBnAKADEA6Ac3DBACcg

(I'm kinda curious how the types-in-js proposal parses this, too. Obviously consistency across tools is desirable.)

[nicolo-ribaudo]

It's likely that the proposal will use something like ::< ... > for type instantiation, so no ambiguity there.

The restriction here could be to disallow a newline if the next token is valid at the beginning of a statement.

[jakebailey]

Ah. Duh.