Fix compiling async arrows in uncompiled class fields#14752
Fix compiling async arrows in uncompiled class fields#14752nicolo-ribaudo merged 2 commits intobabel:mainfrom
Conversation
|
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/52489/ |
| let node; | ||
| if (path.isArrowFunctionExpression()) { | ||
| path = path.arrowFunctionToExpression({ noNewArrows }); | ||
| node = path.node as t.FunctionDeclaration | t.FunctionExpression; |
There was a problem hiding this comment.
Doesn't TS already infer path.node types here?
There was a problem hiding this comment.
No, it still includes t.ArrowFunctionExpression 😕
There was a problem hiding this comment.
Ah it is likely confused by the reassignment.
| noNewArrows?: boolean; | ||
| } = {}, | ||
| ) { | ||
| ): NodePath<Exclude<t.Function, t.Method | t.ArrowFunctionExpression>> { |
There was a problem hiding this comment.
path.arrowFunctionToExpression is an API, should we defer the changes to minor?
There was a problem hiding this comment.
I think we have modified these internal plugin APIs in the past even in patch releases, and this change isn't adding "new functionality" but just exposing more info from an existing functionality.
However, if you prefer to wait that's fine
JLHwung
left a comment
There was a problem hiding this comment.
The return value of arrowFunctionToExpression is practical. If someone reported that their workflow is broken by this PR, we can reland it in the minor.
| } from "@babel/types"; | ||
| import type * as t from "@babel/types"; | ||
|
|
||
| type ExpressionWrapperBuilder<ExtraBody extends t.Node[]> = ( |
There was a problem hiding this comment.
I have never work on a project where we needed such a custom type. It leave me suspicious.
I can confirm that this breaks our build. If using npx-quill (and possibly many other depedencies), the |
|
@Fre4ked Just to clarify: Before this PR Based the provided error message, I can't tell how the new behaviour will break your build. Can you open a new issue and provide a reproduction repo? |
|
The error happens when edit: I'm short on time coming days. I'll make a reproduction repo this weekend if it's still wanted. |
|
This is a compatibility issue between new |
This PR should be reviewed commit-by-commit: the first one is a refactor to help TS inference understand the types of different variables (we had three different logic paths with different types all mixed together); the second one is the bug fix.
The generated output for async functions in uncompiled class fields is ugly, but it's uncommon enough that it should be fine (but not too uncommon, because Angular forces async functions compilation).