Prettier does not respect existing method chain breaks
See original GitHub issuereferencing: Improved method chain breaking heuristic
I understand the motivation behind the recent change, and fwiw, I agree with your solution in 2.0 with one exception. I don’t think that code expressing chained methods across multiple lines should be automatically collapsed by prettier
.
Through each issue linked (#3197, #4765, #1565 and #4125) I didn’t interpret that the community wanted chained methods collapsed; they simply wanted inline chained methods to remain inline.
In the highest rated comment from #4125, one of @pvdlg’s suggestions is If the user write them on multiple lines => keep on multiple line
. In this comment, I think @pvdlg nailed it, and that’s exactly what I’m looking for too.
Prettier 2.0.2 Playground link
# Options (if any):
--print-width=120
Input:
cy.get(".ready")
.should("have.text", "READY")
.should("have.css", "background-color", "rgb(136, 228, 229)");
cy.get(".pending")
.should("have.text", "PENDING")
.should("have.css", "background-color", "rgb(253, 212, 90)");
cy.get(".live")
.should("have.text", "LIVE")
.should("have.css", "background-color", "rgb(175, 221, 255)");
cy.get(".draft")
.should("have.text", "DRAFT")
.should("have.css", "background-color", "rgb(255, 181, 181)");
cy.get(".scheduled")
.should("have.text", "SCHEDULED")
.should("have.css", "background-color", "rgb(222, 222, 222)");
Output:
cy.get(".ready").should("have.text", "READY").should("have.css", "background-color", "rgb(136, 228, 229)");
cy.get(".pending").should("have.text", "PENDING").should("have.css", "background-color", "rgb(253, 212, 90)");
cy.get(".live").should("have.text", "LIVE").should("have.css", "background-color", "rgb(175, 221, 255)");
cy.get(".draft").should("have.text", "DRAFT").should("have.css", "background-color", "rgb(255, 181, 181)");
cy.get(".scheduled").should("have.text", "SCHEDULED").should("have.css", "background-color", "rgb(222, 222, 222)");
Expected behavior:
For method chaining, manually inserted newlines should not be erased.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:223
- Comments:159 (26 by maintainers)
big +1 on the request. Previous discussions seemd to imply that pre-existing line breaks should have been preserved. That appears not to be the case.
IMO: it’s now as annoying as before for a different set of use-cases, notably fluent APIs.
As a library author with dozen builder types libs with fluent apis, hundreds of files are now beeing reformated in a non consistent / weird and not readable way.
I now need to go and edit all those files to add comments in the middle of each chain to ensure lines are broken correctly.
Is there a way to keep using the previous heuristic ?
here is an example I’m editing right now :
here is what it used to be
I see the reasoning behind what prompted the heuristics change, but on a daily basis the new heuristics are pretty annoying to use. I want my formatting to be consistent, not all over the place, which is the result of the current heuristics.
the code above annoyingly turns into
They do pretty much the same thing, except the 80+ example has one more method, I want to be able to easily read what they are doing and understand that they are both similar with one small change, but since they aren’t formatted the same it is harder to understand it at a glance.
I believe for method chain breaks manual multi-line should be kept.