Break lines before binary operators#7111
Conversation
|
/cc @prettier/core will be great if you look at this |
|
I thought there was a consensus that 2.0 would be focused on deprecating old Node versions etc. Updating to 2.0 should not lead to massive code reformatting. Otherwise too many people might prefer to keep using 1.x. |
|
The main 2.0 thread(s) have mainly talked about Node versions, but there have also been many comments on not introducing changes that there is disagreement or lack of consensus on. But there seems to be a very strong consensus on the proposed fix to #3806. The only argument offered against the change is that it would be breaking and shouldn't be implemented in a minor version. However, for the change itself, there is widespread agreement both in the issue thread and in the JavaScript community. AirBnB Issue: airbnb/javascript#1281 StandardJS (based on ESLint, widely used): https://standardjs.com/rules.html |
|
@BrianHVB You completely miss the point of why the ex-2.0 was renamed to 3.0. I'm not saying that there is no consensus about this change, only that first things first. |
e16f758 to
7d88fb8
Compare
|
Anyone considered break line both before and after? const isEventTarget = value != null
&&
typeof value.addEventListener === "function"
&&
typeof value.removeEventListener === "function"
&&
typeof value.dispatchEvent === "function"
&&
typeof value.dispatchEvent === "function"
-
Also_Nice_With_A_Shorter_Operator_Inside
?
SOME_OTHER_EXPRESSION
??
SOME_OTHER_EXPRESSION
instanceof
Even_Longer_Operator |
ba9d939 to
300b900
Compare
|
@btmills There is still a conflict |
| (isAnyValueSelected | ||
| && node.getAttribute(radioAttr.toLowerCase()) === radioValue) | ||
| || (!isAnyValueSelected && values[a].default === true) | ||
| || a === 0; |
There was a problem hiding this comment.
Would it be possible to also change this case where the multiline operators are nested? When I encounter such a case in my code, I usually refactor it so that prettier doesn't make it ugly like that. If I was writing it manually I would write something like:
(
isAnyValueSelected
&& node.getAttribute(radioAttr.toLowerCase()) === radioValue
)
|| (
!isAnyValueSelected
&& values[a].default === true
)
|| a === 0;There was a problem hiding this comment.
I'm trying to keep this change as small as possible to improve the odds the team decides to merge it. Based on the volume of 👍s on #3806, putting binary operators at the beginning of lines has pretty widespread support. It helps that the logic change to do that exclusively deletes code. I'm concerned that expanding the scope could reduce the chance it gets merged at all.
There was a problem hiding this comment.
Sure. I didn't mean this comment to show as a "review" of this PR. It was just a random question 😅 This needs a separate issue.
@VincentLanglet I'm not surprised one of the snapshots has been updated since I last rebased. Rebasing the branch takes several minutes, so I haven't been actively monitoring this PR to keep it up to date. If the team indicates they're interested in merging, I'll certainly do another rebase as soon as possible! |
f5f93ae to
8723d6b
Compare
|
I’ve rebased this on top of |
|
Hi, it looks like the conflicting files are just snapshots and this for years. There has been a lot of discussion around this PR I think it is a quite important one. Thank you! |
|
Any chance of merging this ? 🥹 |
Refs prettier#3806 These cover a few edge cases I encountered while maintaining `@btmills/prettier` over the last few years. I'm adding them up front to demonstrate that the `experimentalOperatorPosition` changes in a later commit have no effect on this formatting when the flag is not enabled.
Refs prettier#3806 This merely defines the flag. A future commit will use it in updated logic.
Right now, this flag isn't implemented, so these tests duplicate the existing behavior. I'm adding them now so that when I implement the flag's logic in a future commit, the changed formatting will be obvious in the diff and easier to review.
Fixes prettier#3806 as requested in prettier#7111 (comment) The flag's tests were already added in a previous commit, so the test changes you see in this commit are specifically due to the new flag's implementation.
This clones TypeScript's type union operator tests in `union-parens.ts` and swaps the operators (& <-> |) to test the the type interesection operator. It also runs intersection tests with the new `experimentalOperatorPosition: "start"` flag. This does _not_ yet update the implementation to consider the flag; to ease review, I'll make that change in the next commit to isolate the impact of the change.
The type union operator was already formatted at the beginning of lines by default, so that logic didn't need to be updated.
I rebased from 1dfe28f to c706678 to fix test failures related to prettier#16601. The rebase applied cleanly, and this was the only change to tests. Since the PR has already been approved, I'll keep this as a separate commit rather than squashing into the prior commits.
|
I rebased from 1dfe28f to c706678 ( |
commit: |
|
CI is failing due to causes unrelated to this PR. |
On Friday, @evilebottnawi requested a PR to resolve #3806 in v2.0 by breaking lines, where necessary, before binary operators rather than after them, putting the operators at the beginning of each line.Previously, there was special case logic to break lines before pipe operators but after all other operators. I removed the special case handling so that line breaks occur before all operators.I left the implementation, tests, and changelog as separate commits to help ease review. Happy to squash or make any other changes as necessary to help get this in!
fixes #3806
docs/directory)changelog_unreleased/*/pr-XXXX.mdfile followingchangelog_unreleased/TEMPLATE.md.✨Try the playground for this PR✨