Skip to content
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(js_formatter): fix some random indention inconsistencies #1162

Merged
merged 1 commit into from
Dec 12, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -539,30 +539,40 @@ impl Format<JsFormatContext> for ArrowChain {
// rest of the arrows in the chain need to format their
// comments manually, since they won't have their own
// Format node to handle it.
if !is_first_in_chain
&& f.context().comments().has_leading_comments(arrow.syntax())
{
// A grouped layout implies that the arrow chain is trying to be rendered
// in a condensend, single-line format (at least the signatures, not
// necessarily the body). In that case, we _need_ to prevent the leading
// comments from inserting line breaks. But if it's _not_ a grouped layout,
// then we want to _force_ the line break so that the leading comments
// don't inadvertently end up on the previous line after the fat arrow.
if is_grouped_call_arg_layout {
write!(f, [space(), format_leading_comments(arrow.syntax())])?;
} else {
write!(
f,
[
soft_line_break_or_space(),
format_leading_comments(arrow.syntax())
]
)?;
let should_format_comments = !is_first_in_chain
&& f.context().comments().has_leading_comments(arrow.syntax());
let is_first = is_first_in_chain;

let formatted_signature = format_with(|f: &mut JsFormatter| {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole diff is a little bit weird, but this just moves the leading comment inside of the signature formatting, ensuring that it picks up the potential indention that's applied below (line +590).

It fixes this:

foo(
  () =>
  // a comment
    () => {}
)

which should actually be formatted to

foo(
  () =>
    // a comment
    () => {}
)

where the leading comment lines up with the following parens.

if should_format_comments {
// A grouped layout implies that the arrow chain is trying to be rendered
// in a condensend, single-line format (at least the signatures, not
// necessarily the body). In that case, we _need_ to prevent the leading
// comments from inserting line breaks. But if it's _not_ a grouped layout,
// then we want to _force_ the line break so that the leading comments
// don't inadvertently end up on the previous line after the fat arrow.
if is_grouped_call_arg_layout {
write!(f, [space(), format_leading_comments(arrow.syntax())])?;
} else {
write!(
f,
[
soft_line_break_or_space(),
format_leading_comments(arrow.syntax())
]
)?;
}
}
}

let formatted_signature =
format_signature(arrow, is_grouped_call_arg_layout, is_first_in_chain);
write!(
f,
[format_signature(
arrow,
is_grouped_call_arg_layout,
is_first
)]
)
});

// Arrow chains indent a second level for every item other than the first:
// (a) =>
Expand All @@ -578,7 +588,7 @@ impl Format<JsFormatContext> for ArrowChain {
write!(f, [formatted_signature])?;
} else {
write!(f, [indent(&formatted_signature)])?;
}
};

// The arrow of the tail is formatted outside of the group to ensure it never
// breaks from the body
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -530,6 +530,7 @@ impl AnyJsBinaryLikeExpression {
| JsSyntaxKind::JS_THROW_STATEMENT
| JsSyntaxKind::JS_CALL_EXPRESSION
| JsSyntaxKind::JS_IMPORT_CALL_EXPRESSION
| JsSyntaxKind::JS_CALL_ARGUMENT_LIST
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When a binary expression is part of the call arguments, its grand parent is JsCallArgumentList, not just JsCallExpression. These intermediary nodes make it kind of hard to compare directly to prettier, but come up consistently (other places also have to check like JsParameterList instead of JsFunctionDeclaration, for example).

Adding this here means that binaries are formatted consistently whether they're the receiver or an argument to a call expression:

foo(
  someCondition === true ||
  anotherCondition === false
);

should actually indent the right hand side, but wasn't because the grandparent is JsCallArgumentList, but this was only checking for JsCallExpression directly. Now it matches Prettier as:

foo(
  someCondition === true ||
    anotherCondition === false
);

| JsSyntaxKind::META
)
})
Expand Down

This file was deleted.