How can I prevent prettier from taking multi-line array to a single line?

[ghost]

Hi,

I can figure out how to prevent prettier from flatting out the below into a single line.

I want to keep this.
imports: [
BrowserModule,
AppRoutingModule
],

I don't want this.
imports: [ BrowserModule, AppRoutingModule ],

What setting do I need to change? Thank you!!!!!!!!

Karl

[CiGit]

It's not possible with prettier.
With eslint, this may help you: https://eslint.org/docs/rules/array-element-newline

[vesper8]

I too am having the same problem. Isn't it possible to disable this behaviour of prettier??

Did you figure out a solution that doesn't involve completely disabling Prettier @kdawg1406 ?

[ghost]

@vesper8 nope never did. Just disabled it.

[deanvaessen]

Workaround: https://prettier.io/docs/en/ignore.html :)

[RobinMalfait]

Currently the comment from @deanvaessen is the only workaround.

[tobi-or-not-tobi]

Is there an option to control the multiline behaviour on the roadmap?

[RobinMalfait]

Not that I know of. Here is a list of issues on the prettier repo itself about multi line. https://github.com/prettier/prettier/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+multi-line+

[goldengecko]

Yeah, this one is annoying me too. Would much rather have a rule rather than having to use the ignore option.

[AlexJWayne]

I've taken adding a textless comment to the first item in the array to force it a multiline layout.

[
  item1, //
  item2,
  item3,
]

[ThePlenkov]

[ThePlenkov]

looks weird.. the previos method - is the only working now after deactivating prettier for the whole block...

[ThePlenkov]

what it could be useful: to support "array-element-newline": ["error", "consistent"], cause now it works like "never". meanwhile it supports "always" - which helped me to solve the case here

[galki]

to add to @ThePlenkov it can support minItems and also be applicable to objects. in fact, because prettier already seems to use something like minItems internally, it makes sense to let the user decide what minItems can be.

For example, by setting minItems: 0 the user would be able to disable this formatting. this is exactly how tslint's array-element-newline works and if prettier's current internal value of minItems is set as the default value this would cause no breaking changes.

I think this logic warrants reopening this issue.

[license2e]

A simple hack is to add comments after the first item in the array:

const myList = [
  'a', //
  'b',
  'c',
  'd',
];

[galki]

@license2e thank you. also the widespread use of this hack is just more reason to reopen this issue because hacks aren't prettier.

[alxkhr]

There is a paragraph in the prettier documentation about multi-line-objects, saying that "Prettier instead keeps objects multiline if there's a newline anywhere inside it in the original source code".

Is this not supported in the vscode plugin, or am i missing something?

Other plugins, like the prettier plugin for Atom, are supporting multiline objects, if i have a newline in the code to format.

[galki]

@alxkhr just the other day ive found out about the following vscode settings:

"html.format.wrapLineLength": 80,
"html.format.wrapAttributes": "force-expand-multiline" // or "auto", "force", "force-aligned", "aligned-multiple"

it didnt occur to me that my editor settings would play a part in prettier formatting. while with the above settings i do get better formatting, does this mean that if everyone on a team has different editors/settings the prettier formatting would not be constant?

or is this because prettier doesnt support html yet, and once it does it will override the above settings (ie printWidth will override html.format.wrapLineLength)?

[AlexJWayne]

@alxkhr That setting seems to apply to objects, not arrays. Maybe the same logic around new lines in the original source code should apply to arrays, too.

[slikts]

I've been using the "hack" as well; this is hands-down the worst feature of Prettier that it keeps jumping between single and multiple lines. Collapsing the lines makes it harder to edit and creates obvious diff churn. The response to just close this is also really unfortunate.

[IT-CASADO]

+1 for re-open this issue.

[jeffersoneagley]

+1 this has been causing lots of problems for me as well.

[slikts]

@RobinMalfait Could there at least be an explanation for why this issue was closed?

[bfmatei]

Bump!

Came here to say that for Angular projects and RxJS-based projects this is an essential feature. Static arrays are extremely common: ng modules, combining multiple observables etc.

Yes, there are two workarounds: dummy comment and the disable directive. But those are only workarounds as the code can become bloated, the workarounds may interfere with other tools (tslint or eslint for example) etc.

[CiGit]

There is nothing we can do in this repository about that.

Solutions I can come up with are:

• A comment in the array
• // prettier-ignore
• printWidth set to a low value. (Which leads to some other changes)
• Don't use prettier.

[bfmatei]

Sorry @CiGit, you are right. I didn't see we're in the prettier-vscode repo. I arrived here from a Google search and I saw just the account name.

[steven87vt]

what it could be useful: to support "array-element-newline": ["error", "consistent"], cause now it works like "never". meanwhile it supports "always" - which helped me to solve the case here

I am using prettier-vscode with pretier-eslint integration and tried the following with no luck:

'array-element-newline': ['error', 'consistent'], 
'array-bracket-newline': ['error', 'consistent']

What am I missing here? I thought prettier would be invoked then eslint --fix. It seems to respect 'always' but then the line tabs get messed up and the array content is sitting on the start of the new line without any spacing.

[gkatsanos]

Dropping prettier because of this. Sorry, its borderline ridiculous to not be able to disable printWidth. eslint --fix is fine for me.

[waldyrious]

For those who are came to this discussion in the prettier-vscode project from a search, and were looking for discussion on the core Prettier project, you may want to take a look at:

• Newline for each item in JSON array prettier#2716 for arrays (and earlier discussion in Consistency in lists/objects prettier#74)
• Keep multi-line formatting for destructuring assignment  prettier#2550 for destructuring assignment (as well as Option Request: Multi-line formatting of object destructuring prettier#4384)
  • By the way, note that the behavior proposed in #2550 would match the way Prettier already handles multi-line objects, and for the same reasons.

[alamothe]

@waldyrious Thank you for the summary, sir!

Do you know if a similar issue for JSX exists? Basically, the situation is the same: Prettier will combine multiline JSX into a single line.

[waldyrious]

Do you know if a similar issue for JSX exists? Basically, the situation is the same: Prettier will combine multiline JSX into a single line.

According to @narkowicz in this comment, there's prettier/prettier#3101 for JSX. Not sure if there are others.

[steven87vt]

So now when I want prettier to not inline things like arrays I add a blank comment inside the structure and it stays chomped.

something: [
  // force chomp using comment
  {staysPut: true}
]

[SebastianMieszczanczyk]

It is not working with updated options on vscode. Tried to use these:
"eslint": "^6.7.2",
"eslint-plugin-nuxt": "^0.5.0",
"eslint-plugin-prettier": "^3.1.2"
and configs:
"eslint-config-airbnb-base": "^14.0.0",
"eslint-config-prettier": "^6.9.0",

Config seems good so it is probably the settings of vs code.
I tried to replace the old (deprecated) settings options with new ones but it is not working and still formatting code.

prettier/issues
Tried to do as this suggestion:
vuejs/eslint-plugin-vue/issues

[sylver]

Just came here having the same issue trying to figure out how to configure Prettier.
This issue is a basic need and is 2 years old, unresolved and closed. That's silly.

Having to use hack and add useless comments in my code to actually avoid an arbitrary non-configurable behavior is absolutely out of the question.
I don't see the point of using this if it only messes with my code instead of doing what I want.
Did you guys figured it out or just dropped it ?

[G33kNoob]

still waiting the magic to solving this bug

[Pointotech]

Why is this closed? It doesn't seem solved at all. Ugly hacks are no way to configure formatting behavior in a formatter.

[waldyrious]

Why is this closed? It doesn't seem solved at all.

@Pointotech this repo is just for the prettier-vscode integration, not for Prettier itself. Please refer to this comment for links to the issues in the Prettier project where this can actually be addressed.

[Vadorequest]

This kind of decision is the reason why prettier is garbage.

When the people maintaining this lib will finally understand that code quality matters more than their damn "opinion" then it'll become something useful.

I've wasted several days on Prettier, and I truly wish it hadn't become so much popular, because it's just a bad tool.

When right-looking code becomes fucking mess because it's "opinionated better" then you know you ain't using the proper tools to do the job.

So many people are so happy with "not having to think" and "just let prettier do its job", but that's just nonsense when such behaviour makes PR review harder, and lower code quality.

There are several rules enforced by experienced devs that are similar to this one that cannot be configured by prettier, and this is a no-go for me.

I will not enforce such a tool in my company.

---

It's easy to complain like I do above. The current situation is quite frustrating, and I wish a proper fork of Prettier was made (or the author change their rules). I actually give it a try a few days ago, but the project is rather complex.

But we need a better alternative to Prettier. One that allows teams to work efficiently. Limiting configuration is a good idea, but you're taking it way too far, and it makes your whole project useless.

I wonder how many hours were wasted by devs on Prettier worldwide, but it surely ain't pretty.

[reimertz]

I randomly went here to figure out how tweak array breaks myself and was just about to leave accepting it can't be done. Not a big deal.

But then I saw your comment @Vadorequest.

I am sorry but I just feel like this is so out of touch and that the contributors of this AMAZING tool doesn't deserve this.

I think your message is the best of proofs why we need tools like prettier; the toxicity around what pretty code is and what makes code good is usually fought by a very selected few where the rest of us just want to code and create awesome stuff.

I will not enforce such a tool in my company.

Instead you are enforcing your own view of what pretty code is on the entire company. I promise you the majority of your buddies at work rather have prettier running then having to be afraid of being rejected by the CTO because one array wasn't newlined.

I wonder how many hours were wasted by devs on Prettier worldwide, but it surely ain't pretty.

I promise you it ain't more than the amount of hours, stress and overall mental sanity saved by not having to have these stupid syntax rage wars.

[Vadorequest]

You're completely right about the usefulness of tools like prettier. I'm not advocating against a formatting tool, my disappointment is rather focused against the biased opinion of what the limited set of rules prettier allows us to customise, supposedly meant to be for our own good: It is not, and contributes deeply to decrease code quality and make code reviews harder.

When you see issues like this one, sometimes open in 2017, you can see what I'm talking about. So many devs being limited by the limited set of option, and wasting years of discussions on stuff that would increase code quality. That's such a waste.

When I build open source, I don't expect people to be grateful for it, I expect them to be grateful for it, if it helps them, if it fits the needs.

And Prettier doesn't fit this need. How many people have above mentioned trying it out and quitting Prettier because of this?

Prettier has become some sort of a standard for code formatting, and is being enforced more and more, and it's saddening to see, from my point of view, considering how hard it has become to configure it properly, and still doesn't answer the needs of so many.

My feedback is that I've wasted days on trying to configure Prettier, and ended up in a situation where I'm not satisfied by its implementation and limitations.

Don't get me wrong, the purpose and vision behind Prettier are great. The implementation isn't.
Yes, it's free. Yes, it's open source. That doesn't mean it cannot become better. And it should, or it'll eventually be replaced by something better.

[alamothe]

Same here. Spent days trying to make Pretier work, but eventually gave up.

The most problematic part is merging of several lines into one, whether that's arrays, JSX, or function calls (there is a separate issue for each, but in truth it's the same problem). This makes code reviews harder, source history a mess, and code less readable.

In the end, we stuck with the Visual Studio formatter which is pretty good.

Note though that this is a repo for the VS Code extension, not the Prettier itself. Venting would be more useful in the original repo. 🙂

[Vadorequest]

The most problematic part is merging of several lines into one, whether that's arrays, JSX, or function calls (there is a separate issue for each, but in truth it's a single problem). This makes code reviews harder, source history a mess, and code less readable.

This is exactly my biggest pain with Prettier. I could live with the other rules imposed upon me, but not with that.

Note though that this is a repo for the VS Code extension, not the Prettier itself. Venting would be much more useful in the original repo. 🙂

You're right, I actually noticed it wasn't the main repo after commenting. 😅
My bad.

[Vadorequest]

@reimertz @alamothe I opened prettier/prettier#8507 to discuss about Prettier's motivation. I believe it may be more useful to the community, rather than venting out personal frustration like I did above.