Repository navigation
[4.7-beta] Parsing failure for arrow function expr in conditional expr #48733
Description
Bug Report
🔎 Search Terms
conditional4.7 betasyntax error
🕗 Version & Regression Information
This is a crash- This changed between versions 4.6.3 and 4.7.0-beta
⏯ Playground Link
Playground link with relevant code
💻 Code
(false ? (param): string => param : null);🙁 Actual behavior
Parsing failure for arrow function expr that has type annotations for return type, but doesn't have type annotations for parameters, in conditional expression.
🙂 Expected behavior
Parsing successfull.
Activity
MartinJohns commentedon Apr 17, 2022
I can't reproduce this. Neither locally nor in the playground it crashes.
sosukesuzuki commentedon Apr 17, 2022
Sorry I forgot remove this from template.
jmcscript commentedon Apr 18, 2022
The OP's statement is accurate as the playground proves that there are no parsing errors in the version he mentions. However, if it helps resolve the problem, changing his code as follows resolves the error in the current version, leaving you with just the any type inference for param.
TS Playground Example
RyanCavanaugh commentedon Apr 18, 2022
I'd like Jake Bailey (@jakebailey) to confirm but this seems like it might be intentional. Your code might terminate at the legal JS expression
so parsing the
: stringas a type annotation might require "too much" lookahead.jakebailey commentedon Apr 19, 2022
No doubt this is #16241 / #47550, yes. The reason why the workaround in typescript-eslint/typescript-eslint#4829 works is because the parser can see the
:inside of the parens and says "that's definitely a parameter", and allows the colon before the return type.When the (what I can only describe as) heuristics don't "prove" that it's an arrow function, my change disallows the
:when parsing, preferring it to end the conditional.The test case in the issue is similar to one I wrote in my PR, but then throws an extra case on the end.
I'd have to think about how I might fix this; the "heuristic" I described previously mainly checks things to do with parameters. It doesn't go and parse all the way past an error expression.
The gotcha with lookahead is when conditionals are nested, though I can't seem to produce an example that actually parses in JS. I thought the following would be a counter example, but this fails to parse when I run it in node.
(If anyone can come up with an example, let me know. This is tricky.)
jakebailey commentedon Apr 19, 2022
Regardless, I think all of this is going to have to be figured out for the types-in-JS proposal, since all of these parsing choices will have to be made and our parser changed to fix any differences.
sosukesuzuki commentedon Apr 19, 2022
FYI here is a case of how this bug caused problems in a real product https://github.com/typescript-eslint/typescript-eslint/pull/4829/files#diff-d9d4dc5af184a093e1caab204aa0ed6da56d008309ff90294561a64bec2e6663
jakebailey commentedon Apr 20, 2022
SUZUKI Sosuke (@sosukesuzuki) Can you try taking a peek using the build on my PR here? #48788 (comment)
jakebailey commentedon Apr 21, 2022
To link it here, here are various variations of "fixes" to this: