Prettier: Placing operators at the beginning of lines

[599316527]

Prettier 1.10.2
Playground link

# Options (if any):
--print-width=22
--tab-width=4

Input:

var a = '123354535435' + '2342423153';

Output:

var a =
    "123354535435" +
    "2342423153";

Expected behavior:

var a
    = "123354535435"
    + "2342423153";

[azz]

I don't think we should add an option for this, but just change the current behaviour. Put the operator on the left for arithmetic operations, but the other logical/binary operators should remain on the right.

https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator

[j-f1]

My expected behavior, if we’re going to change this:

var a =
    "123354535435"
    + "2342423153";

[mmarti]

It'd be awesome if logical operators were included as well. Placing && or || at the start of lines rather than the end is very similar to trailing commas in that it produces cleaner diffs.

[ryanwoodcox]

Is there any traction on this? At the very least when using prettier-eslint with prettier.eslintIntegration to to true, the operator-linebreak option should be respected and it is not.

[duailibe]

@ryanwoodcox Prettier doesn't read any ESLint configuration

[ryanwoodcox]

@duailibe So what is the point of the prettier-eslint package and the prettier.eslintIntegration option?

[duailibe]

@ryanwoodcox I think it's pretty clear already in prettier-eslint's README and (assuming you're talking about VSCode) in prettier-vscode README

[trash]

Mayhap I'm beating a dead horse here but I think this should become a part of the opinionated standard. As commented earlier, there's a great argument for leading with operators for readability but I can't really find any arguments for why trailing operators would be better. It seems to objectively just be harder to parse.

Totally understand punting on this for not wanting to open an opinion-haver's **storm but my guess would be that not many people are attached to this option so switching this in a v2 wouldn't cause a big hoopla.

(Either way, I've started using the wonderful @btmills fork!)

[salonnlee]

I've had this problem recently. There are conflicts when working with Prettier and ESLint to format code. May I ask if the problem has been solved ?

[lydell]

@salonnlee We recommend turning off all linter rules that conflict with Prettier. See https://prettier.io/docs/en/eslint.html

[salonnlee]

The problem is that our team shares one ESLint setting. I should delete Prettier and not somebody else delete ESLint. If I keep using Prettier, I will create conflict with other members.

That's why I agree to make "operator-linebreak" configurable.

[lydell]

@salonnlee I know what you mean, it's sad when you're forced to follow a an ESLint config or styleguide and the rest of the team isn't willing to use Prettier. One day you might be able to convince them, though! Until then, according to the ESLint documentation for operator-linebreak it supports autofix (at least partially) so you might be able to use prettier-eslint!

[btmills]

Though the pull request (#5108) was declined, I did end up taking the recommendation in the feedback there, and I just published a fork with this change as @btmills/prettier. (Disclaimer: it's for my own convenience, use at your own risk, etc.) If the decision ever changes and the maintainers want to make this change in Prettier itself, I'd welcome the chance to re-submit a PR!

[daliusd]

I hope something will happen with this. Our team is using @btmills/prettier branch now but that has stopped us from using pretty-quick.

[aikeru]

Please reconsider this (and bring it in line with the way ternary operators are formatted).

// Please do this - read vertically down :)
const foo = barValue
            && checkBazValue()
            && qux.isTrue()

// Please stop doing this - scan entire line :(
const foo = barValue &&
            checkBazValue() &&
            qux.isTrue()

[joshlongerbeam]

The thing that bugs me most is what @aikeru pointed out: it's inconsistent with how ternary is currently formatted.

Prettier 1.15.2
Playground link

--parser babylon

Input:

if (
  longVariableName === "this"
  || longVariableName === "that"
  || longVariableName === "something else"
) {
  a =
    longerVariableName
    + deeply.nested.variable
    - even.deeper.nested.variable
    + another.variable;
  b =
    longVariableName === "this"
      ? a
      : longVariableName === "that"
      ? a + 1
      : longVariableName === "something else"
      ? a - 1
      : 0;
}

Output:

if (
  longVariableName === "this" ||
  longVariableName === "that" ||
  longVariableName === "something else"
) {
  a =
    longerVariableName +
    deeply.nested.variable -
    even.deeper.nested.variable +
    another.variable;
  b =
    longVariableName === "this"
      ? a
      : longVariableName === "that"
      ? a + 1
      : longVariableName === "something else"
      ? a - 1
      : 0;
}

[j-f1]

Pointing that out makes the style make somewhat more sense, but I still think we shouldn’t change this since it changes a lot of printed code.

[aikeru]

@j-f1 From your comment, it seems that decisions are made w.r.t. changing prettier conventions based on how much existing code they might change. Am I misunderstanding something? :(
If this is correct, it is surprising to me.

[j-f1]

That was the rationale for closing #5108. We don’t want to make upgrades too difficult and noisy for our users.

[jleclanche]

A default-off option would be fully backwards compatible, right?

[j-f1]

Yes, but we try to avoid adding options since they make the code harder to test: https://prettier.io/docs/en/option-philosophy.html

[0az]

What about implementing this as a major version bump?

[fiblit]

I agree with @trash, considering the virtually universal acceptance of this change within this issue (except from the project maintainers who seem somewhat unjustifiably worried about a backlash).

Were this marked as a major version bump as @0az suggests, any worry from changing many lines among projects is mitigated. Furthermore, common style guides like AirBnB already do this, so it might even appeal to some people who haven't already adopted Prettier.

Technically, this would be a complete benefit for being more consistent and readable, as many have noted. And besides that, Prettier should at least try to be consistent about its opinions rather than obstinate (and, as was strongly approved of in the issue to resist configuration, the items chosen should be consistent and look nice).

[mmarti]

@j-f1 While I completely understand the rationale for not wanting noisy updates or new options—if there were ever a case for doing it, this appears to be a pretty solid example. Could you clarify whether this will ever be considered (major version bump or otherwise)? If not, could we close the issue to make it clear this won't be changed?

[ackvf]

my two cents: (taken from https://github.com/prettier/prettier/issues/5932)

Positioning logical operators and brackets at the end of lines makes the code pretty unreadable, since each logical operator is at different position and blocks start ad hoc without context. One then needs to scan the whole code to understand dependencies and the flow.

Before:

Here in this example the code is structured quite well. It is apparent from the use of brackets that there are two blocks A and B as well as their relationship. Moreover, it is clear that block A consists of a logical chain.

After:

This code turns everything on its head. It looks like a sequence of some statements, that start looking like an Array. Block B starts out of nowhere and it is absolutely necessary to scan the code and find that there are actualy two blocks, because it looks as a single block of code. Logical operators of the first blocks's chain are scattered through the code and hard to find.

Input:

            {
              ( comments[0]
                && comments[0].type === CommentTypeEnum.STATUS_MESSAGE
                && comments[0].text === RequestStateEnum.OPEN
              ) || <InfoMessage date={createdAt} text={t('request.userSubmittedReq')} />
            }

Output:

            {(comments[0] &&
              comments[0].type === CommentTypeEnum.STATUS_MESSAGE &&
              comments[0].text === RequestStateEnum.OPEN) || (
              <InfoMessage date={createdAt} text={t('request.userSubmittedReq')} />
            )}

[tohagan]

I like using prettier but this one kinda kills the joy. please fix.

[adrienharnay]

Hey,

Considering existing options (trailing comma, JSX brackets, arrow parentheses, ...), I can't quite understand how this would not be beneficial behind a new option. @ackvf has done a great job explaining why this is not just a "personal preference", but really a way for a human to parse and understand code faster. You could argue that I'm biased and this is my personal preference, but I hope you will reconsider. Thank you!

[adrienharnay]

As a workaround, feel free to use this fork, up to date with master:

"prettier": "npm:@brigad/prettier",

[BrianHVB]

Our code base makes frequent use of multiple line conditionals, often intermixed with ternary operations. Having all types of operators on the left is very important for readability and maintainability.

We would like to use prettier to adjust spacing and line lengths on code check-in, but the inability to stop the reformatting of our operators is a block.

[Parthchokshi]

I agree with putting logical operators on next line rather than scanning whole line to find one. Putting logical operator on new line also helps in determining if there is an operator between two variables faster. Scanning the current formatted code just feels as if there are two different parameters passed to a function unless you scan whole line to find out an operator at the end.

[SoulsD]

Hey,

Considering existing options (trailing comma, JSX brackets, arrow parentheses, ...), I can't quite understand how this would not be beneficial behind a new option. @ackvf has done a great job explaining why this is not just a "personal preference", but really a way for a human to parse and understand code faster. You could argue that I'm biased and this is my personal preference, but I hope you will reconsider. Thank you!

Consider also versioning: trailingComma: 'all' and jsxBracketSameLine: false are useful because if you need to add/delete attributes/lines, the file history is kept clean and modification are only related to the currently modified line

Considers this diffs:

...
    name: "",
+   value: 42,
  }
...

```diff
dummyAttributes=""
id="dummy"

• style={}
  />

On the other side, having the obligation to put operator at the end of the line will always end like this:
```diff
var mybool =
looooooooooongstuff &&
- mooooooooorestuff
+ mooooooooorestuff &&
+ someresult

[TiredFalcon]

I'm setting up Prettier and ESLint configurations for my company's codebase and this is literally the only issue in the entire configuration that gives us a problem.

There are ONLY arguments toward changing this (or supporting an option); the code becomes more beautiful, more readable, and results in better diffs.

The only (weak) argument against this is that a lot of people have been using prettier until now and will need to change.
How is this a good argument? Most people use prettier to format automatically, they wouldn't even notice, and if they notice they would be happy about the change.
For now, we will be forced to use a fork, which is a shame; if anything, at least could you give this issue or the forks more visibility for people who are actively searching about this issue? I spent hours trying to find a solution to this before finding this issue.

[phaux]

It's also inconsistent with:

type Type =
  | string
  | number
  | boolean

[thorn0]

Should we consider this for Prettier 2.0?

[daniel-seitz]

I used to put a lot of effort of writing this nicely. Using this package had big benefits (especially when it comes to other developers who don't focus on beautiful code as much) ...but it totally destroyed my work here.

I am craving for v2

[alexander-akait]

@thorn0 yep, let's consider this for 2.0

[lydell]

For v3, I’d say.

[alexander-akait]

@lydell why 3?

[dmitryrn]

We should have it

[TiredFalcon]

@thorn0 yep, let's consider this for 2.0

When I click on the 2.0 link on here it redirects me to 3.0, why is that?

[alexander-akait]

We don't have enough time to implement this and test, if somebody want this, feel free to send a PR

[thorn0]

@TiredFalcon Because now we have the new 2.0: https://github.com/prettier/prettier/issues/6888

[btmills]

@evilebottnawi I'm willing to resurrect #5108 this weekend - will that be sufficient to get it in v2.0? (I've also been keeping a parallel branch with just that change in btmills/prettier. At least as of [email protected], the diff was small, but I haven't updated for [email protected] yet.)

[btmills]

I submitted PR #7111 into the next branch for 2.0.

[mat813]

I got bitten by this today when I added the prettier plugin to eslint in one of my app today.

const filter = (row, column, cellValue) =>
  column.name === "net_demande"
  && cellValue != null
  && cellValue !== 0,

got changed to:

const filter = (row, column, cellValue) =>
  column.name === "net_demande" &&
  cellValue != null &&
  cellValue !== 0,

I really find this a lot less readable.

[TiredFalcon]

@mat813 just use @btmills version of Prettier, it's the exact same as Prettier but with operators at the beginning of lines (where they should be).

[aikeru]

Wow. Amazed and very disappointed this didn't make it into 2.0. This issue has been open for over 2 years now and PRs opened to fix it since about 1.5 years ago. There's tons of support for getting this fix in, and clear and obvious benefits to getting this fixed that affect extremely common use cases.
From all I can tell, the 3.0 milestone doesn't have a target date, and because this is marked "needs discussion", it seems this isn't an item prettier is even fully committed to.
I hope this comment will raise more awareness of this glaring issue that prevents me and many others from using prettier.

[TiredFalcon]

Wow. Amazed and very disappointed this didn't make it into 2.0. This issue has been open for over 2 years now and PRs opened to fix it since about 1.5 years ago.

I feel the same.
I think that it's possible the maintainers do not agree with this change, and will postpone it indefinitely.
An argument against this change has been that, well, it would change a lot of existing code.
That argument is absolutely invalid because Prettier 2.0 already does change a lot of existing code thanks to various changes to defaults.

I would like to have a sincere explanation by the maintainers, and not some vague excuse and indefinite postponing of this change.
If they don't agree with the change, they could say so, and it would be fine: I'd just use the forked version.

P.S.: "needs discussion" – well, here are 2 years of discussion.

[ntkoopman]

P.S.: "needs discussion" – well, here are 2 years of discussion.

I don't see any discussion here. Everybody is arguing for the same thing.

[ackvf]

@ntkoopman Well obviously, when everyone is disappointed. Maybe it would help if somebody outlined what is an expected outcome and who should actually contribute?

This feels like a discussion to me.

[Yurickh]

it would help if somebody outlined what is an expected outcome

There's an active fork for two years now with the expected outcome pretty much outlined. All the contributions are pretty much in place, it's just about the prettier team agreeing to getting them in, as far as I understand.

[lydell]

Everybody is arguing for the same thing.

People on the other side don’t usually come to these discussions, unfortunately. They appear after we’ve released a change are very upset :/

[Zamiell]

@lydell Prettier is self-defined as an "opinionated code formatter". If there are:

• good arguments to use prefix operators (e.g. the ones outlined above over the course of the last two years) and
• no good arguments to use suffix operators (or any arguments, really)

Then isn't it prettier's job to be opinionated and choose prefix operators over suffix operators? Of course, to be fair, I guess this depends on your definition of what "opinionated" means.

As you say, people will be mad over any changes that you implement in Prettier that introduce diff-noise in their codebase. And in particular, this change has the potential for a lot of diff-noise. But isn't people's madness assuaged by the fact that there are no actual arguments to use suffix operators over prefix operators? It's not like this is an arbitrary change that you don't have a leg to stand on, as the expression goes.

[flightless-katie]

@lydell Prettier is self-defined as an "opinionated code formatter". If there are:

• good arguments to use prefix operators (e.g. the ones outlined above over the course of the last two years)
• no good arguments to use suffix operators (or any arguments, really)

Then isn't it prettier's job to be opinionated and choose prefix operators over suffix operators? Of course, to be fair, I guess this depends on your definition of what "opinionated" means.

As you say, people will be mad over any changes that you implement in Prettier that introduce diff-noise in their codebase. And in particular, this change has the potential for a lot of diff-noise. But isn't people's madness assuaged by the fact that there are no actual arguments to use suffix operators over prefix operators? It's not like this is an arbitrary change that you don't have a leg to stand on, as the expression goes.

Sadly it seems painfully obvious that the "opinion" in prettier is that of the owners of the project, no matter what.

[Yurickh]

Not sure if someone already mentioned, but I'd like to leave the rationale behind this suggestion in python's official style guide here as well.
Not something to be adopted _because_ python uses it, mind me, these are completely different languages.
But I think the rationale for it is really sound and applies to JS as well.

[macgyver]

Speaking as someone who has convinced my team to implement Prettier now on
two projects, one with ~32k lines of js and one with ~50k, I'd prefer to
deal with some diff noise in exchange for prettier code.

On Sat, Apr 18, 2020 at 6:47 PM Yurick [e-mail] wrote:

Not sure if someone already mentioned, but I'd like to leave the
rationale behind this suggestion in python's official style guide
https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator
here as well.
Not something to be adopted because python uses it, mind me, these are
completely different languages.
But I think the rationale for it is really sound and applies to JS as well.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prettier/prettier/issues/3806#issuecomment-615968810,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAAJC3MNEJ5S3HT4GACFKDRNIUYNANCNFSM4ENKY4WQ
.

[Yurickh]

If prettier introduces this as a (opt-in) setting, then the noise is reduced to almost zero, right? And also, it avoids being a breaking change.
I understand every new setting weakens the "opinionated" description, but this seems like a good situation for it. 🤔

[Lavariet]

Any updates from the Team whether the pull request https://github.com/prettier/prettier/pull/7111 is going to be accepted soon?
Or is there a reason why it can't be accepted yet?
The PR seems to pass the provided tests and would finally resolve this issue from over 2.5 years ago.

[flightless-katie]

Any updates from the Team whether the pull request #7111 is going to be accepted soon?
Or is there a reason why it can't be accepted yet?
The PR seems to pass the provided tests and would finally resolve this issue from over 2.5 years ago.

Next time anyone chooses prettier, I think this issue and how it has been handled by the owners of this project, should be fresh on everyone's mind.

[alexander-akait]

We can't do breaking change.

@Lavariet @flightless-katie do you see milestone on right side of the issue on the top?

[flightless-katie]

We can't do breaking change.

@Lavariet @flightless-katie do you see milestone on right side of the issue on the top?

Yes and the fact that this has been continually put off in spite of having active community contribution and participation is exactly what I'm talking about when I say it should be on everyone's mind.

Your short reply doesn't help change the appearance of things here.

[alexander-akait]

Your short reply doesn't help change the appearance of things here.

Then I won't answer and no problem

[jdufresne]

We can't do breaking change.

If there is agreement from the prettier developers, could a breaking change come with a new major version?

[Yurickh]

Hey, good to see the thread getting attention back :)~

We can't do breaking change.

This is a really poor response. Since @btmills' PR, there was at least one breaking change published, with huge rewritings due to them (you can read them in the breaking changes blog post) and that haven't stopped them.

Not only that, but as discussed earlier in the thread, this change can be implemented with no breaking changes, by adding an opt-in config setting and leaving the current behaviour as the default.

[alexander-akait]

We try to avoid big changes for no reason, sometimes we have regressions, but we fix them, but here is big change, so we postpone it for 3 version. No new options.

[Yurickh]

Do you think 3 years worth of discussion and requests with almost two hundred upvotes on a feature is "no reason"?

I understand postponing it to 3, if the path chosen is to make it a breaking change, but this feature has already been envisioned for version 2 and nothing really came out of it.

I just don't want the same to happen again.

[tattali]

We try to avoid big changes for no reason, sometimes we have regressions, but we fix them, but here is big change, so we postpone it for 3 version. No new options.

I think everyone here agrees that this feature would be great by default.

[alexander-akait]

@Yurickh Sorry, but I'm tired of aggression and constant attacks, only :-1: and etc, all I tried to do was to help you, exactly at my request was it was added https://github.com/prettier/prettier/pull/7111#issue-350531246 (first paragraphs), when we were on the 2 version, we found many regression (most of fixed, you can see what @btmills does good work), and we had big problems with many dependencies, so we focused on our main problems, sorry, most of use have job and and don't get paid for the work here, so we cannot solve all the problems fast.

Sometimes I just can't understand some developers, it seems like many people just like to argue and attack.

Same story here https://github.com/prettier/prettier/issues/5377, I resolved this, I heard as much aggression from developers as I have never heard from anyone in my life, and that in the end - no one has sent PR, no activity.

[alexander-akait]

I think everyone here agrees that this feature would be great by default.

Other developers will think differently, so it's not that easy as you think, it is potential holy war imporvement

[tattali]

There are almost 200 likes on the first post. Could you do something like a form request or a poll on your social media to ask the users if it's a good or bad idea to implement it as default?

Maybe on your website?
I'll be glad to help

[Yurickh]

@evilebottnawi I understand maintaining an open source project is hard work and can be really frustrating at times, I'm deeply thankful for the dedication you and the rest of the prettier team put into this tool.

To me a big part of the frustration regarding this issue is about the uncertainty of what's going to happen to it. Do we have a working branch or any ongoing work of an rfc for the prettier v3?

@tattali I get the intention here, but I believe a poll or a form request would hardly achieve the desired effect. Most people that consume prettier and that would be affected by the change are not really active in the community and wouldn't participate. Unfortunately I don't think there's any good way of measuring the water temperature for the acceptance of breaking changes as this one.
Maybe @evilebottnawi knows some strategy that the prettier team used last time?

[alexander-akait]

@tattali Voting is often a false positive action, it often does not show real numbers, this does not mean that we do not take this into account, most of :+1: and :heart: votes only who love this style, developers who do not like this style most likely did not go here, they are not interested in this, so they are not looking for this problem. There are no developers who are right or wrong, there are just different preferences.

You can always use branch in package.json https://github.com/prettier/prettier/pull/7111

[Yurickh]

it is potential holy war imporvement

In the other hand, I'm yet to hear a single argument defending putting operators at the end of the lines. Prettier is the only code styleguide/formatter that I've worked with to this date that does it, so I'm really reluctant at accepting that this is holy war material.

[alexander-akait]

@Yurickh yes, you are right, the only good strategy is probably metrics from github, we can write parser most of popular js/ts projects from github and see what style they prefer, but it may turn out that this is not the preferred style for most of developers, and then we will have to think about new options, which I honestly would not want at all, I hope you understand the philosophy of prettier. But I would start by taking metrics

[btmills]

you can see what @btmills does good work

Thanks @evilebottnawi :heart:

Hi all. I appreciate the support expressed here for #7111. As a maintainer of another significant open-source JS tool, I can empathize with the Prettier team how emotionally draining some of these discussions can be, so I've intentionally stayed out of much of this thread to date because I don't want to pile on. Without quantitative metrics, the arguments around readability and consistency have already been made. I contributed what I can with #7111 and a :+1: here, for whatever the latter is worth.

I've also intentionally avoided any promotion, but solely to alleviate some of the pressure on the Prettier team here, if this issue is a blocker for you, "prettier": "prettier@npm:@btmills/prettier@^2.1.1" in package.json with yarn should function as if #7111 had been merged. That's how I've been dogfooding the PR.

[tattali]

@evilebottnawi that greats news! I think that a good idea.

For what it's worth, [Airbnb styleguide] (https://github.com/airbnb/javascript#control-statements) uses operators at the beginning of the lines

To be honest I'm not a huge fan of all of their recommendations but this is probably the most complete and used styleguide.

[alexander-akait]

@tattali this adds weight to changing this default, because this is a fairly popular style, but I'm not a huge fan of all of their recommendations too :smile: But most of them used by me

[hackel]

I'm curious, are there any actual arguments in favour of trailing operators other than avoiding breaking changes and rewrites? Why was this decision made in the first place? I'm certain the developers had a reasonable justification for it originally. Since most of us here want this change, we're in a bit of a bubble. From my perspective, the argument for a customizable option is certainly more compelling than obscure options like "quote props."

[lydell]

@hackel I can’t think of any arguments in favour of trailing operators either, other than “it’s common” (which is a bad argument).

I don’t think it was a conscious decision. Implementing a pretty-printer from scratch to a usable state is a lot of work – if you’d stop and think over every piece of syntax it would take forever. I think James just cranked out operator printing in the way he was used to seeing them.

The main problem is that at this point changing anything is really hard. As a maintainer it’s often much easier to focus on fixing bugs and supporting new syntax (such as TypeScript 4.1) than making big decisions, so issues like this can stall. I’ll leave the discussion there, because I’m not very good at such community handling stuff. 🙏

[ntkoopman]

Playing Devil's advocate: in some languages placing the operator at the beginning of the line doesn't work (e.g. Go and Kotlin). Placing it at the end gives a more consistent behaviour across languages.

(I only noticed this issue after running Prettier on some Java code, where basically every style guide will tell you to put them at the front)

[janaagaard75]

We're discussing adding an option to place operators at the beginning of the lines, right? All the arguments favoring one syntax over the other belong to an issue where the default behavior is discussed, and adding them here makes an optional formatting feature look unnecessarily controversial.

[lydell]

We're discussing adding an option

It’s unclear.

[TiredFalcon]

People on here seem to often discuss two reasons:

1. Changing the default behavior would cause some issues to some codebases which would see a lot of changes in their code.

2. Adding an option would go against the philosophy of Prettier, which wants to have the fewest amount of options possible.

Reason number 2 means that there likely won't be ever an option for operator placement.
Reason number 1 instead is not a real reason, considering that Prettier 2.0 changed three defaults. This is because reason number 1 is not a reason for dismissing this issue, but for postponing it to a large release. And this is exactly what is planned for this feature, since it is listed in the milestone for version 3.0.

And yes, sure, this issue was first planned for version 2.0 and then postponed, but that's stuff that happens.
So, just be patient, and if you can't wait just use btmills' fork.

[am0wa]

OMG, 80+ comments and you still hesitate to solve this issue in one way or another.
Common, nobody needs prettier that brakes the ESlint rules and can't be tuned ☠️
Please, listen what community asks...

[lydell]

(@am0wa Since you mentioned ESLint: Compatibility with ESLint rules is never an argument for Prettier – we recommend turning off all conflicting rules: https://prettier.io/docs/en/integrating-with-linters.html. So if making ESLint play nice with Prettier is your goal the solution is easy, if you prefer operators at the beginning of lines there’s no way currently than https://github.com/prettier/prettier-eslint)

[am0wa]

@lydell thank you for the informative answer.
Yes. Prettier is not obligated to be compatible with ESLint. Yet, imho, the code formatting tool supposed to be flexible enough to allow users to specify in which way they want to place operators, without workarounds or ESLint at all.

[zachmmeyer]

That is the point of Prettier. It is their opinion. It's not supposed to be completely flexible. It is obvious that if you change the setting in ESLint, then it is no longer an issue.

[gruckionvit]

(@am0wa Since you mentioned ESLint: Compatibility with ESLint rules is never an argument for Prettier – we recommend turning off all conflicting rules: https://prettier.io/docs/en/integrating-with-linters.html. So if making ESLint play nice with Prettier is your goal the solution is easy, if you prefer operators at the beginning of lines there’s no way currently than https://github.com/prettier/prettier-eslint)

ESLint rules can be turned off that's why...

[Jaffsterz]

Is there any update on when this will be fixed?