fix(js_formatter): ensure flat conditional content is always written in RemoveSoftLinesBuffer
#1357
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
Fixes #1356. I don't feel like this should've actually solved the issue, but it was still an underlying trap in
RemoveSoftLinesBuffer
that conditional content was still conditional. Technically that is correct for what the name of the buffer implies, but the actual functionality that it's going for is "force all elements to print in flat mode", not just "remove lines". By keeping the conditional in place, it'd be possible for a group to break and cause theif_group_fits_on_line
condition to fail, omitting the content, even though the intent is to just print that content and assume that it fits. Or rather, the goal is to test if it fits in the context of the rest of the content being printed in the buffer, normally as part of something likebest_fitting!
.This was exactly the case that happened in #1356, where the content was just long enough that the group containing the object type annotation wouldn't fit and ended up breaking, and because the semicolon was optional, it ended up being omitted as part of the
if_group_fits_on_line
condition. Now that the condition is elided and the flat content is just printed no matter what, the semicolon will always render regardless of whether the group ends up breaking, and the result comes out as expected (at least, matching Prettier).For some reason this doesn't feel like the intuitive solution to me. It feels more like there is some logic in calculating fit that's incorrect, but knowing my gut, that's likely not the case and this is the real solution.
Test Plan
Added a spec test specifically covering the issue case, ensuring that the semicolons still get printed.