-
-
Notifications
You must be signed in to change notification settings - Fork 108
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: Wrong indent in some methods invocation #404
Conversation
Do you have the previous output ? |
ctx.primaryPrefix[0].children.fqnOrRefType[0].children.Dot !== | ||
undefined | ||
) && | ||
// indent when lambdaExpression |
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.
indent or dedent ?
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.
indent, we should not dedent when we have a lambdaExpression.
The results are not good.
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.
Do you have the previous output ?
The previous output is the content below // input.
I have used it to prettify the new version.
ctx.primaryPrefix[0].children.fqnOrRefType[0].children.Dot !== | ||
undefined | ||
) && | ||
// indent when lambdaExpression |
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.
indent, we should not dedent when we have a lambdaExpression.
The results are not good.
Hmm it looks a little odd for the chained method call to just be floating rather than anchored to the close paren, but I don't have a suggestion on how to format it better |
I am not sure to understand, what do you mean by floating and anchored ? |
Sorry if that was unclear, I'm referring to the chained method in an example like this: assertThat(
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa,
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa,
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa
)
.isEqualTo(); The someOtherMethod()
.assertThat(
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa,
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa,
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa
)
.isEqualTo(); Where the |
That was my first thought but I was not sure, thanks ! assertThat(
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa,
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa,
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa)
.isEqualTo(); It might be nicer (or not) to look but I don't know if it requires a lot of work on it. |
It seems like that would make it harder to read because Out of curiosity, I just tried this out in the prettier-js playground and it basically used the same format as this PR: assertThat(
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa,
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa,
useraaaaaaaaaaojzapjzpozjapjzpoajzpozaaaaaaaaaaaMapperlaaaaaaaaaaaaaaaaaaaaaaaa
)
.isNotNull()
.isEqualTo(); Since this PR matches the prettier-js behavior and I don't have any better suggestions, I'm on board with it 👍 |
What changed with this PR:
Fix #293
Example
Relative issues or prs: