Remove "opinionated" and allow more config?

[JohnnyMorganz]

A discussion which continues to happen offline is the decision against config options for StyLua, so I've decided to open an issue on it.

My main goal has always been to have "sane" defaults in the formatting, but it is impossible to suit every case.

I wonder if being an "opinionated" formatted is still beneficial. It's main selling point has been to reduce bikeshedding, but in practice, I'm not sure if that actually rings true.

Rustfmt highlights an example where it's very configurable, but works pretty well (and from what I've seen, most people don't actually bother configuring, but maybe because there are so many options 😅).

Maybe we should just allow more (reasonable) configurations?

[Betelgeuse1]

I just used stylua for the first time in a project and the available configuration didn't strike me.
I think being opinionated is beneficial, at least for me. Keeps me from thinking too much about small code appearance details.

What type of extra configuration you had in mind ?

[JohnnyMorganz]

I think being opinionated is beneficial, at least for me. Keeps me from thinking too much about small code appearance details.

Agreed IMO.

I am still unsure about what we do need to configure, some examples include #555 or #276.
There are also very minor ones such as #313, which I don't think are completely worthwhile to change the philosophy for, but I respect that people have different style ideals

[Betelgeuse1]

I don't know if it is possible in current code implementation (pretty sure it's not), but maybe stylua should stay opinionated with a way to implement custom rules as go-ruleguard.

That way, a user who really want a certain rule can always write it themselves.

[LastTalon]

I think rustfmt benefits heavily from pushing a conventional approach to writing code using it. Its generally very well accepted that the defaults are very good and sensible defaults and the agreement within the ecosystem is an important aspect of using the formatter.

I think the same can be used here as well. Formatting Lua code is unfortunately still very young and it'll take time for people to catch on and it'll take time for people to realize that certain patterns are very useful for writability and not very useful for readability and a formatter allows you to always favor readability.

[Kampfkarren]

@LastTalon FWIW Rustfmt needs configs more than StyLua because Rustfmt treats changing how code formats as a breaking change (such that you should be able to update cargo fmt and, if your entire codebase was on it before, get no diffs)

[LastTalon]

Returning to this a bit to make my thoughts a bit more explicit here.

Rustfmt treats changing how code formats as a breaking change

I completely agree here. And I guess maybe I should be clear. I think the decision needs to be on one end here or the other. It either needs to be opinionated with very little configuration, or treat formatting changes as breakage and allow configuration, but leading with convention.

The longer I consider it, the more firmly I find myself in the latter camp, and this is one of the reasons. I think treating formatting changes as breakage is a good thing. As it stands that's really difficult with stylua since updating means it will format things differently in your code base.

[alerque]

I agree with the premise of this issue that "opinionated" is not necessarily a selling point. Consistency/repeatability certainly is and the very important thing to me is that I can always run it and just accept the output as gospel truth. This means as a maintainer I can lint for it and enforce it on projects and avoid the bike shedding about how a specific case should be written, it should always be formatted with the formatter.

I would actually like to see a few more options and appreciate the ones that are there. But not having edge cases that have to be handled manually is far more important than any one style choice.

[alerque]

Because rustfmt has been brought up here and elsewhere as a case study for an opinionated formatted that has been quite successful, I'd like to note a couple things.

1. Yes it is wildly successful and basically the de facto way to format all Rust code.
2. It is true that it is opinionated, but it is not true that it is not configurable. It has a whole slew of configuration options that can be used for projects and situations where the defaults are not preferred. See https://rust-lang.github.io/rustfmt
3. Most people don't even know it has so many options largely because the defaults are pretty good and widely regarded as good.
4. It had the advantage of growing up in sync with the language itself and getting established by early adopters.

In relation to that I'd like to suggest that stylua can rightly be opinionated by having good defaults, but that it would benefit from being more configurable. It has the disadvantage of coming late to the party and existing code bases have established guidelines already. Making them automatic/consistent/repeatable would be a huge bonus, but many/most projects are resistant to just adopting an all new style.Some project maintainers have been writing Lua for decades with other styles and are not going to just ditch that easily. If stylua could be configured more, many more projects would be able to adopt it for the advantages that automation brings.

[ZegWe]

Some project maintainers have been writing Lua for decades with other styles and are not going to just ditch that easily. If stylua could be configured more, many more projects would be able to adopt it for the advantages that automation brings.

Totally Agree.

[alerque]

The project has already agreed to head that direction, and several options have been added to the development branch that are not yet in a release tag.