-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix handling of comments with decorators before export
#15032
Fix handling of comments with decorators before export
#15032
Conversation
nicolo-ribaudo
commented
Oct 10, 2022
•
edited by gitpod-io
bot
Loading
edited by gitpod-io
bot
Q | A |
---|---|
Fixed Issues? | Fixes #12276 |
Patch: Bug Fix? | |
Major: Breaking Change? | |
Minor: New Feature? | |
Tests Added + Pass? | Yes |
Documentation PR Link | |
Any Dependency Changes? | |
License | MIT |
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/53238/ |
792f629
to
4acb0d3
Compare
// comments between `export` and `class` as leading comments of the | ||
// class declaration node. | ||
// This is needed because the class location range overlaps with | ||
// `export`, and thus they would me marked as inner comments of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// `export`, and thus they would me marked as inner comments of | |
// `export`, and thus they would be marked as inner comments of |
// `export`, and thus they would me marked as inner comments of | ||
// the class declaration. | ||
// @dec export /* comment */ class Foo {} | ||
// See [parseDecorators] for the hanling of comments before decorators |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// See [parseDecorators] for the hanling of comments before decorators | |
// See [parseDecorators] for the handling of comments before decorators |
lastTokEndLoc: { index: lastTokEnd }, | ||
} = this.state; | ||
|
||
if (this.input.slice(lastTokStart, lastTokEnd) === "export") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move the comments manipulation to
finalizeComment(commentWS: CommentWhitespace) { |
So that comments manipulation are placed within a single file and we probably don't have to do an export
lookback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved the logic to comments.ts, but I'm not sure about how to do it in finalizeComment. Specifically, I don't think we can distinguish /* 1 */
and /* 2 */
when finalizing the comments of the class node:
@dec export default /* 1 */ class /* 2 */ extends X {}
(I just realized that this PR doesn't support the default
case, I'll add it)
c28374d
to
0a7c85d
Compare
I completely rewrote how decorators are attached to classes:
By doing so we don't need any custom comment adjustment logic. While doing so I also removed the |
There are still some generator bugs |
Before this PR: @dec export class A {}
^^^^^^^^^^^^^^^^^^
ExportDeclaration
^^^^^^^^^^^^^^^^^^^^^^
ClassDeclaration
^^^^
Decorator After this PR: @dec export class A {}
^^^^^^^^^^^^^^^^^^^^^^
ExportDeclaration
^^^^^^^^^^^^^^^^^^^^^^
ClassDeclaration
^^^^
Decorator (in both cased the nodes hierarchy if The "unusual" comment attachment only happens when there is
|
592e9d0
to
4007d8c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job!
Also the E2E test failure is related, I'm not sure if that is expected.
Co-authored-by: liuxingbaoyu <[email protected]>
@fisker / @sosukesuzuki How does prettier decide when to print decorators before |
I believe e2e test is breaking because prettier uses location of first decorator versus the attached class node to detect decorators before export: |
Uhm ok. I can restore the original location of the export declaration, but I believe it's wrong and in Babel 8 we should make it include decorators again (because the a node should always start before is children and end after). If prettier uses tokens when printing, they can check if the |
prettier/prettier#12806 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the new location setting makes sense to me. Since prettier has pinned @babel/parser
so it should be fine even if we ship as-is. Can prettier support the new location setting here? If so we don't have to defer to Babel 8.
Another option that prettier has is to check if |
New location make sense, don't need worry about us, we'll tweak logic. |
End up with |