You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 31, 2023. It is now read-only.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR adds a pre-processing step to the formatter that can be used to bring the tree into a shape that better suits the formatter and adds support for:
Removing unnecessary parentheses of logical expressions with a nested logical expression in the right hand side
Preserving parentheses if a node has a leading type cast comment
Rewriter
The JavaScript uses the pre-processing to:
Remove any parenthesized nodes except:
If the expression node has a syntax error (missing required child or has a skipped token trivia)
If the inner expression is an unknown node
If the expression has a closure type-cast comment
Re-balances logical expressions: a && (b && c) -> (a && b) && c so that it works nicely with the binary like expression flattening
The second significant part of this PR is the need for a source map to map printer markers to the original source positions and resolve the source text for a transformed node
For example:
// Source // Transformed(a+b)a+b
Resolving the source text of a + b should return (a + b) to ensure that the verbatim output (used when the node can't be formatted or if formatting is suppressed) doesn't drop the parentheses.
Check out the documentation of source map for a more in detail explanation.
This looks complicated
Yes, this PR introduces some complexity by adding a source map and transformation step to the formatter. In my view, the simplification that the transformation brings by no longer having to use resolve and resolve_parent inside specific formatter outweighs the added complexity that is local to the rome_formatter only. I see it as a trade of added complexity in the infrastructure in favor of simplifying individual formatters that tend to be complicated anyway.
This PR is huge
Yes, it is but most changes are
Removing the ExpressionNode and AssignmentNode implementations
I compared the numbers again and it's mainly checker and typescript that now differs significantly. I manually compared the commits before adding the Fx hash map for those two tests to see if there's a serious regression
The numbers are in the normal range which is why I think it's fine to go ahead with this PR to unlock further work.
As discussed offline with @ematipico There are a few things that we want to discuss offline and I'll create a follow up PR addressing the findings from that meeting.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a pre-processing step to the formatter that can be used to bring the tree into a shape that better suits the formatter and adds support for:
Rewriter
The JavaScript uses the pre-processing to:
a && (b && c)
->(a && b) && c
so that it works nicely with the binary like expression flatteningThis logic is implemented inside of the new
JsFormatSyntaxRewriter
.Source Map
The second significant part of this PR is the need for a source map to map printer markers to the original source positions and resolve the source text for a transformed node
For example:
Resolving the source text of
a + b
should return(a + b)
to ensure that the verbatim output (used when the node can't be formatted or if formatting is suppressed) doesn't drop the parentheses.Check out the documentation of source map for a more in detail explanation.
This looks complicated
Yes, this PR introduces some complexity by adding a source map and transformation step to the formatter. In my view, the simplification that the transformation brings by no longer having to use
resolve
andresolve_parent
inside specific formatter outweighs the added complexity that is local to therome_formatter
only. I see it as a trade of added complexity in the infrastructure in favor of simplifying individual formatters that tend to be complicated anyway.This PR is huge
Yes, it is but most changes are
ExpressionNode
andAssignmentNode
implementationsresolve
andresolve_parent
calls.I recommend you focusing on reviewing
Performance
Formatting
rome-classic
:main
: Formatted 3959 files in 216msthis pr
: Formatted 3959 files in 236msThe main bottleneck for formatting remains IO
Test Plan
Average compatibility: 82.68 -> 83.70
Compatible lines: 79.75 -> 80.79