Option to retain multi-line props in JSX/HTML

[damassi]

Right now I'm finding that Prettier collapses JSX attributes onto a single line, up until the column width. This (in my opinion) feels much harder to read as it requires the eyes to constantly scan left to right rather than "glance" at a single block.

Would you be open to an option that disables this forced single-line output?

Prettier 1.7.4
Playground link

Input:

const f = () => (
  <Foo
    hello={baz}
    how={are}
    you={a}
    hi={c}
  />
)

Output:

const f = () => <Foo hello={baz} how={are} you={a} hi={c} />;

Expected behavior:
Retain line breaks.

Update:

I opened this a long while back but after two years of using Prettier I absolutely, without question, and without hestitation, support the settings currently in Prettier and further -- believe that all of these personal preferences simply vanish from sight after using Prettier for more than a few days, as if one never even had them. They vanish into the delight of not having to worry about preferences anymore, and all of the energy / time savings that come from that. I am a 👎 on adding additional configuration in this regard.

[suchipi]

Maybe we should treat these the same way we treat object literals?

[damassi]

@suchipi - my thought exactly.

[SimenB]

The more of these "respect input" are added, the more I'm rooting for #2068.

[lydell]

I'm pretty sure this has been discussed somewhere else, but I can't find it right now. And I think somebody also suggested "max 3 props per line", a bit like we do method chaining.

[suchipi]

"max 3 props per line" sounds like a good heuristic to me.

[damassi]

Ideally this would respect line breaks similar to object literals and apply no heuristic at all.

[duailibe]

This has been discussed before indeed, and this #2668 (comment) explains the rationale behind the decision.

[ivarni]

"max 3 props per line" sounds like a good heuristic to me.

That sounds like something there could be an option for. I personally like 1 per line though I can see the arguments for more but I'd love to be able to override a default of 3 if at all possible.

[j-f1]

I think that means that if there are 1, 2, or 3 props, they’ll all be on one line (if they fit), but after that, they’ll be split so that there’s one on each line.

[ivarni]

Then I would set it to 1 and get the results I want, sorry if I was unclear but that's exactly the option I'd like to have.

[j-f1]

@ivarni so you always want props to break?

<div
  className="foo"
>
   ...
</div>

[ivarni]

@j-f1 No, I was thinkin that with 1 it's fine on one line. I'll try to explain my reasoning

<div className="foo">
    ...
</div>

is fine, there's only 1 prop so the only logical thing I'd want to do is to add one more or remove it.

<div className="foo" aria-hidden="true">
    ...
</div>

With two props I'd much prefer to have it rewritten to

<div
    className="foo"
    aria-hidden="true"
>
    ...
</div>

Because it's now easier to

• Add a new prop (it's just adding a new line)
• Remove a prop (I can just delete a line)
• Re-order the props (I'm just shifting lines around)

Edit: This also makes moving a prop from one element/component to another much easier if they're both having 1 prop on each line, I suppose that's a valid case for always breaking.

With <div className="foo" aria-hidden="true"> I'll have to navigate my caret to where I want to add/delete something or if I'm rearranging; mess around with marking blocks of text while moving my caret around.

I understand that not everonye sees the value in that and considers it a bit of a micro-optimization I would love it if I could say "max 1 prop per line" instead of "max 3 props per line" .

I really wouldn't mind having them always break either if that's something that's easier to implement or is already supported but I figured if there's a heuristic for it already it might be less work to make it configurable.

[damassi]

@ivarni - Curious about what you think about things simply being left alone? Meaning, no rule about breaking or single line, and leaving it up to the developer. My desire with this issue is to either remove auto-formatting completely or add an option to enable / disable for JSX. Like object literals, there are many contextual reasons to allow for single-line or multi-line formatting, and Prettier wisely takes a hands-off approach in this regard.

[ivarni]

@damassi I think that would open the door to a couple of difficult questions, like what to do if the line length exceeds the max column width or even how to deal with

<div foo="foo" bar="baz"
    zot="zot"/>

which I would personally prefer not to be left alone.

But I didn't mean to hijack this issue in any way, I just stumbled across while trying to figure out how to keep prettier from collapsing all my carefully formatted JSX properties since that's a show-stopper for me personally, I spend way to much time messing around with props to have them crammed into a single line.

I'll be over on the fence and see what comes out of this and similar issues :)

[damassi]

Similar to how object literals collapse when reaching the column width, the same would apply here.

[ivarni]

Fair enough, I'd like them to always collapse, not just when reaching the column width but I'd also like a Ferrari. Sometimes we can't have all we want :)

[j-f1]

@damassi Note that the reverse doesn’t happen — if you remove one or two keys from the output, it won’t go back to being a single line.

[j0xhn]

👍 I'd also love if I could tell prettier to leave my multi-line props alone... or pass in how many should be max -- I prefer 3

[cychiuae]

It is very difficult to do code review when without multi-line props options. I understand someone thinks it is better to have all the props lie on one line but, at least, please give us an option to config what we want.

[damassi]

Update: I filed this issue, and I don't necessarily want to close it since it has so many thumbs and is a legitimate point of discussion, but after using Prettier for a while I'm inclined to follow its default suggestions assuming the column width is set to 80, as they boldly call out on the settings page. This is absolutely key. The issue was that we were using a wider column width, which never led to the trigger being fired to expand wide code vertically. Now that things are at 80 I actually like the balance, and feel like the tradeoffs are valid. I've grown quite fond of the decisions that were made and feel like this is basically a non-issue that simply required some getting used to (IMO).

[Nantris]

Please, an option to fix this. This issue and #2550 are such deal-breakers.

[rhyek]

I support having an option that allows me to specify max amount of attributes allowed per line before automatically wrapping.

[mike-robertson]

I just want to say I love what prettier does, but I am pretty bummed that the pull request that asked to put this in was closed for further discussion. At the very least, it seems like there is enough demand for this to put it behind a configuration flag. It seems like it's not being put in because of personal opinions by big contributors, not because it doesn't provide value.

[mssngr]

More options = more power. Merging the pull request that will fix this issue will get more teams using Prettier. This, and similar issues regarding multi-line collapsing, are the main reasons my team stopped using Prettier.

[damassi]

Please move this issue to your own name please! I'll repeat again, the mute button does not work in my issue reader. Point the new issue at this one. Please respect my wishes and stop reopening.

It takes just a moment to open a new issue, copy and paste the text at the top, and to add a link back to here, which reasonable users invested in this issue will follow without a problem and track just like one tracks anything on Github.

[alexander-akait]

@damassi You are very nervous, maybe you need some relax

And yes, people still will write here and you will get notification anyway

/cc @thorn0 Should we open new issue

[lydell]

Just in case it helps, I’m not sure what ”mute” button we are talking about.

In the sidebar to the right on this page there’s this button:

Have you clicked ”Unsubscribe”? Then it should look like this:

Note that if you make a comment you are automatically subscribed again:

[damassi]

Thank you for clarifying @lydell. Yes, I know about the mute, and it's been repeated probabaly around ten times in this thread over the past three long years. It has no effect on my issue reader, which isn't a Github product.

We're veering off course however and I very much would like to avoid a tech support discussion. Please respect my repeated mutli-year-long wishes and move the discussion to another thread. As I said, I'm sorry for being grumpy, but it's very annoying when someone repeatedly reopens a closed issue for reasons that are entirely unnecessary. People know how to follow links -- expecially people who are championing new features for Prettier.

[thorn0]

IMHO we should close this issue without opening a new one. I think it's clear by this point that Prettier is going to stand its ground and not add such options. If someone needs it, they should fork Prettier. It's open source, its users are developers, so why is there so few active forks? We should encourage forking more. It's a perfectly valid solution to such problems. Also I don't believe it's possible to add something substantially new to the discussion in this issue. All that could be written seems to have been written.

[lydell]

(One downside of forking is that it’s not enough to fork just the prettier/prettier repo. You also need editor extensions. And if your team isn’t all using the same editor, or if your project is open source, you are going to need several editor integrations.)

[krokofant]

Beside forks, isn't plugins an approach as well?

---

It has no effect on my issue reader, which isn't a Github product.

So it might not even be a Github specific issue? 😕

Seems weird to close this issue to workaround issues with your issue reader, and even weirder when this thread might still get comments. If the thread is locked I suppose your issue will be mitigated even further.

[thorn0]

@krokofant Yes, I think it's possible to implement an alternative HTML printer as a plugin.

[michaeljota]

@thorn0 @lydell I've been following this issue for a while, and I don't really care if this happens or not, but I don't think this should be a new option per se. Maybe you can add this behavior as the JS object. I know it's not something experted, but most of the time what we would like is the same behavior that is currently happening with JS objects, if I set them in one line, format them in one line, if I want them in multiples lines, just put the first one in another line and then format all the others.

I think this is the best way of compromise. Users that don't want this to happen, will notice no difference. But those who want this, will have what they want.

[thorn0]

@michaeljota

But those who want this, will have what they want.

And those who don't will be stuck with attributes spread over multiple lines or will have to know to give a clue to Prettier somehow to collapse those attributes. Instead of simple automated formatting, we'll end up with a semi-automatic tool that requires esoteric knowledge of its inner workings to be used. This situation is already bad enough because of object literals, let's not make it worse.

[pjg]

And those who don't will stuck with attributes spread over multiple lines or will have to know to give a clue to Prettier somehow to collapse those attributes.

I think that ideally this should be a new option for html/jsx attributes formatting. I know you don't want new options, and I can understand the reasoning, but there seems to be a really big demand for this, especially for JSX. As things stand now, this looks like a stalemate. You don't want object-like splitting of JSX attributes, you don't want adding a new option, and you don't want to split all html/jsx attributes into multiple lines every time (as some people will definitely prefer multiple attributes per line).

Many developers want prettier's support for one attribute per line, but you're not giving us a solution, and you don't want to accept any of the proposed solutions. This results in an understandable resentment on both sides, which is not ideal.

Maybe having support for this via a plugin (developed in the prettier org) would be a satisfying solution for everyone? I know that this requires a non-trivial effort, and is not a top priority for the maintainers, so perhaps placing some incentive, like a sponsorship/patronite/donation just for having this would move things forward?

[michaeljota]

@thorn0

And those who don't will be stuck with attributes spread over multiple lines

As I said:

Users that don't want this to happen, will notice no difference.

Regarding this:

semi-automatic tool that requires esoteric knowledge of its inner workings to be used

I understand this is an issue, but it's the current behavior for the objects. It won't make it any worse. It is as it is. If the object issue ever get fixed, then the fix would be applied to this as well.

[alamothe]

I don't think it should even be an option. Prettier should not join multiple lines with a single argument per line, whether it's JSX, arrays or function calls. Never. If there's a return anywhere, Prettier should respect that and put each parameter on its own line.

[falcucci]

that's incredible how prettier didn't stand your hands to help with it.

Fork doesn't work aswell, isn't that simple.

Shame.

[TheFern2]

Just learning react, and I love prettier, but making all props into one liner is horrible for the eyes. 4 years and still no response.

[damassi]

Just stick with it @kodaman2 - its annoying until you don't even notice anymore.

[Darksubject84]

Looking at 5 attributes in a single line itches that same part of me that sees that es-lint red warning line on technically good code. I have to just.. keep.. scratching at it so I don't go insane... You know what I mean?

[bymoe]

I tried to stick with it for 2 months, maybe I'll use to it, But no, it's just annoying, like really annoying.

[TheFern2]

Is funny how everyone just says get used to it. This is a real issue. I will just uninstall prettier extension and format my own code, I'd rather it makes sense visually than to a bot.

Code should work with us, not against us.

[mattmischuk]

@kodaman2 I think it’s a domain that is dominated by strong opinions. In my experience, I’ve never worked on one team where everyone agreed on a set of rules so strictly. For this reason, having less configuration does indeed have advantages. Early in my career I was fairly dogmatic about syntax, after a while I realized I was focusing on the wrong problems and there was no benefit to the business starting internal arguments about syntax.

I think this is why a lot of people say "get used to it", I think because they’ve grown and seen that they value the "team" over the "individual" and want to focus on business problems rather than "individuals" personal code preferences.

If something really does matter to you, you can use eslint configs to override prettier.

I don't mean to come across snarky in this comment, I can promise you that’s not my intended tone here.

[TheFern2]

@mattmischuk This issue alone is plastered all over the internet. 1 or 2 props look like crap if it hasn't reach the width limit, no matter how much you'd like to deflect the issue.

"Get used to it", isn't solving anything. Us as developers should be looking forward for improving code readability which this issue is against. But I no longer have to "get used to it", I've uninstalled prettier from my machine. 👍😎

[damassi]

As the saying goes "Stubbornness makes everyone's job harder".

There is a greater good here, and that's saving ones energy to focus on things that matter, and to bring consistency to code everywhere independent of opinions. Prettier is more than just JSX.

If you're looking for more flexibility, see this fork: https://github.com/brodybits/prettierx

[ChadAltenberger]

I'm new to web development and am currently in week 18 of my coding bootcamp. My instructor encouraged me to use Prettier and so I've been using it for about 2-3 weeks now. I also was looking for a solution to this exact issue but realized I had initially changed the printWidth config setting from the default 80 to 5000. To be honest, I don't really remember doing that or why I would have. But I changed it back to 80 and find that that's perfect for breaking up multiple, lengthy props when need be. Not sure if this is helpful at all as this is just a basic setting with Prettier, but at least for me, I hadn't even thought about this option and am happy enough with the way Prettier will break into new lines when it gets too long. Thanks for all the great info!