Honoring trailing commas

[shushtain]

Hi,

It would mean a lot to me if trailing commas would behave similarly to Prettier and Black. I'm sure most people use them for the ease of adding items later, but I, by habit, add them when I expect a table (or even a function/class call in some languages) to be expanded by the formatter.

I would hugely appreciate an "honor_trailing_commas" option, or something similar. To be absolutely clear, what I'm proposing is to expand lines with trailing commas in addition to basic rules, NOT to ignore expanding lines without the trailing comma. So if the line is long -> expand, if there is a trailing comma -> expand at any line length.

Thanks,
Artem

P.S.: I did find a related topic in Issues, but there is no definitive conclusion except for something about... Roblox or whatnot. Sorry if I'm flogging 💅 a dead horse.

[JohnnyMorganz]

Thanks for the suggestion.

We already have something similar here where a newline after the opening { will force it to always be on multiple lines.

i.e.

local x = { 1, 2, 3 }

... written as ...

local x = {
  1, 2, 3 }

... will force formatting into, and keep it as ...

local x = {
    1,
    2,
    3,
}

This was inspired by the original way prettier set it up.

Trailing commas would be an interesting way to configure this too. Arguably maybe a bit more intuitive. However, not sure if there is value in having 2 ways to do the same thing

[shushtain]

Thanks, I'll try that! By intuition, I was breaking the line after 1, (and even after all items), expecting it to catch on my preferred style.

What you've shown is similar to the way the lines are split in CSS, but I did not know that Prettier targets the line break after the bracket as a "signifier" for that style. Was sure that it looks for any line breaks within a statement.

[shushtain]

Since there is already a way to achieve something similar, my suggestion is redundant.

[shushtain]

Oh, but shouldn't the same be applied to function calls then? Since we don't use trailing commas which would break them. I think that would be easier to read and "organize" at least in 2 cases:

1. There are many similar functions within a block, and half of them go over the line limit, so some arguments should be scanned through in the opposite direction, which is objectively harder.
2. Since tables honor hanging brackets, changing the table formatting inside a function call causes the whole thing to reflow, and now there are vertical table arguments, and horizontal other ones. Which is fine, but there should be an option to tweak it, I think.

Here are all those combinations together:

I hope you agree it's a mess.