Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove "opinionated" and allow more config? #620

Open
JohnnyMorganz opened this issue Nov 15, 2022 · 7 comments
Open

Remove "opinionated" and allow more config? #620

JohnnyMorganz opened this issue Nov 15, 2022 · 7 comments
Labels
requires option This feature request would require option configuration rfc/in discussion This issue is currently in discussion, comments are welcome!
Milestone

Comments

@JohnnyMorganz
Copy link
Owner

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?

@JohnnyMorganz JohnnyMorganz added the rfc/in discussion This issue is currently in discussion, comments are welcome! label Nov 15, 2022
@JohnnyMorganz JohnnyMorganz pinned this issue Nov 15, 2022
@Betelgeuse1
Copy link

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
Copy link
Owner Author

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
Copy link

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
Copy link
Contributor

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
Copy link

@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
Copy link
Contributor

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
Copy link

alerque commented Dec 12, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
requires option This feature request would require option configuration rfc/in discussion This issue is currently in discussion, comments are welcome!
Projects
None yet
Development

No branches or pull requests

5 participants