fix issues 686 and 753 #754
Conversation
This change modifies `allows_inline_multi_line` to restrict arrow functions with expression bodies from being inline multi-line. This ensures that if such an arrow function overflows the line width, it forces the parent call expression to break its arguments onto multiple lines, rather than allowing a partial split that results in inconsistent formatting. Fixes dprint#753 Fixes dprint#686
adrian-gierakowski
force-pushed
the
fix-issues-686-and-753
branch
from
ab37dd7 to
fc1269f
Compare
naimonon77
left a comment
naimonon77
left a comment
There was a problem hiding this comment.
@adrian-gierakowski Let me just comment on one thing.
| @@ -0,0 +1,46 @@ | |||
| ~~ lineWidth: 80, indentWidth: 2, memberExpression.linePerExpression: true ~~ | |||
There was a problem hiding this comment.
@adrian-gierakowski
Let me just comment on one thing.
I think it should have a name starting with 0, like other files, like "issue0753.txt".
There was a problem hiding this comment.
Thanks.
Btw. I'm not sure of this is the correct fix. Please see my comments in related issue.
There was a problem hiding this comment.
In my environment, the behavior of the following test case changed when memberExpression.linePerExpression:
false was set. You may want to check this.
When you do, it's a good idea to incorporate the latest changes from the main branch and check them just to be sure.
There was a problem hiding this comment.
In my environment, the behavior of the following test case changed when memberExpression.linePerExpression:
false was set. You may want to check this.
Yes, the issue only manifests when memberExpression.linePerExpression: true. I think that's the reason @dsherret keeps ignoring it since this option is disabled in deno. I'm not interested in disabling this option as without it dprint allows formatting which is quite inconsistent, like:
a.b.c
.b.e
.fThere was a problem hiding this comment.
The main problem at this point is: what's the intended behaviour in #753 as that would determine if solution in this PR is valid or not
There was a problem hiding this comment.
As far as I can confirm, the intended behavior in #753 is fine.
There was a problem hiding this comment.
@dsherret would be great if you could confirm and merge if you agree with the above. Thanks!
2 participants
Modified
src/generation/generate.rsto returnfalseforNode::ArrowExprinallows_inline_multi_lineunless the arrow function body is a block statement. This prevents arrow functions with expression bodies from being formatted inline when they overflow, ensuring consistent multi-line formatting for function arguments. Verified with regression tests.NOTE: this PR was created with the assistance from an AI agent, see original PR on my for which was created by the agent: adrian-gierakowski#2
Fixes #753
Fixes #686