Resist adding configuration

[gaearon]

You’re going to be under a lot of pressure to make X, Y, and Z, configurable.
Configuration is a perfect example of tragedy of the commons.

Everybody wants to add just a tiny piece of configuration to satisfy their use case. As a result we end up with inconsistently designed tools, with unexpected combinations that don’t work correctly, with bugs and regressions that, when fixed in one configuration, break something else with another configuration.

The requests for configuration are vocal. The requests to stay simple are often silent.

I just wanted to take a moment to say there are some of us who actually appreciate tools with limited scope that don’t attempt to solve everybody’s use case, and instead do a specific thing well.

[sapegin]

If we as a community could find the most common JavaScript code style, I’d try to adopt it in my projects. I see a lot of benefits in that for me as a maintainer and for contributors of my projects.

[gaearon]

The thing is, I don’t even care about “most common” here as much. I’m fine with @jlongster making common sense decisions as long as it’s something consistent and as bug-free as possible. These style differences don’t really matter, people care way too much about them.

[sapegin]

The only reason for the most common style is to make less people adapt to a new one ;-)

[gaelollivier]

@gaearon Agree that style differences don't really matter and any crazy style that has auto-format support is better than one without.

However, for a project that is about formatting I think style questions should be taken seriously. If it's about defining a "standard" that would be used by many people, would be better to chose one that looks nice (to as many people as possible) :)

[jlongster]

@gaearon I totally agree. Thanks for opening this issue because we need to discuss here what the real goal of the project is (and put it in the readme). I see three different goals:

1. Converge on generally a single style (with very few basic options to help align with existing projects, like single/double quotes)
2. Cater to a few large demographics (support tabs or spaces, semi or no-semis)
3. Make it completely configurable/pluggable, possibly reading in eslint config and trying to adhere to that

I definitely don't want to do #3. There's just too much complexity already in making sure everything is consistent and I guarantee I will burn out (probably others too) if we attempt that and this project won't work.

I'm not sure about #2. The two most divisive issues in JS are tabs/spaces and semis/no-semis. There are already issues about them: #12 #34. I'm tempted to try to support those two options as a way to bring everyone together. Heck, if you wanted to turn on semis or switch to tabs it's a simple config switch. And like you, I just don't really care anymore which ones people use.

As I noted in the issues though, there are real problems trying to support those styles. Trying to emit semicolon-less JS means we need to detect where we have to emit a semicolon to avoid collapsing code where it shouldn't. Things like that.

When it comes to how function calls, object expression, etc are formatted, yes, I don't think we are going to change anything from how it already is. I'm not going to sit around and argue about specific styles. I'll change something if the majority of the community is asking for it, but otherwise, people don't need to worry so much about the minutiae of syntax.

For the time being, I think we should focus on #1. I'd love any advice for the tabs/spaces & semicolons issues though. I don't think we should do it until this project is clearly succeeding and a large group of people feel like they're missing out. My preference is to let projects evolve slowly so I'll resist until we feel it's right to make those decisions.

[natew]

Well, to speak for the commons, I'll throw in my 2c.

First, thank you very much for this project, it's exactly what we should be working on, well done, and will be extraordinarily useful for devs everywhere.

My vote is for at least implementing #2, and generally for making it as configurable as is tolerable for maintainers.

Why? Well, simply this: we are all different, and have different use cases. The more configurable it is (towards real-world desires, see issues + reactions for a good guage), the more helpful it is.

Second: the whole point of formatting is to allow people to have their code look how they want. If you make it look how you want, then you're not really serving the purposes of a community formatter very well, you're serving the purpose of the loudest/most well known/your desired formatter.

To me, luckily, this is not a big issue. We have a great system for tracking desires, we can debate them as they come up.

I also appreciate @gaearon for opening this, because it's good to know that some people desire to limit configurability. I can see one upside for that use case: the global look of JS becomes more similar. But, to me, that is not big enough to warrant subjugating the desires of every user to potentially help beginners, perhaps, though I doubt semis/no-semis and other similar ones make a big difference. Plus, if we're allowing line-length and other config, it's already making decisions on configurability, so drawing lines autocratically seems like a pretty unfriendly decision.

Finally: I hope that we can standardize on a lot of them, avoiding a lot of work for maintainers, & this is a very legit concern to balance.

Sincerely,
Someone who really hates semis 😛

Best of luck!

[dangoor]

Golang got around this question entirely by shipping gofmt early on. In JavaScript-land, we've got a long history now of people doing a wide variety of things.

Not implementing options for spaces/tabs and semis/no semis is a good thing to pushing toward a consistent standard across JS projects. The downside is that leaving those options out could hinder adoption among people who feel strongly about the opposing choices and open the door for a fork.

If I was leading this project: I would leave the options out and see where it goes, attempting to achieve for JS what gofmt brings to golang. JS isn't golang, so it's possible that's not the right choice for JavaScript, but I feel like there's little benefit to arguments over styling.

[munificent]

There is a very pragmatic concern around configuration: if you support, say 10 boolean config flags, then your test suite needs to be 2^10 bigger to cover all of the cases where those configurations interact. And they will, absolutely, interact, in nasty subtle ways.

Even when the formatter isn't configurable at all, there is already a long bug tail just with how different language features interact in the formatter.

Whether it's better for users or not (I personally lean on the side of not), configurability is a nightmare for the maintainer of the formatter itself.

[jlongster]

Thanks you @dangoor, that is good insight and I agree. Right now let's focus on making this solid for the demographic of people who use spaces and semicolons at least. We can go from there.

@munificent that's a fantastic point. I've already run into that with the current options, because I use Jest snapshot testing, but they are all generated only with the default options. If someone makes PR, I don't see how it affects the code if the options are turned on. And I'm definitely not going to have a 2^N number of tests folder where N is the number of flags.

[robertknight]

I can see only one upside for that use case: the global look of JS becomes more similar.

Speaking from what I've seen of the Elm, Go, Rust and Python communities, where style is highly standardized, this is a big upside and a desirable outcome. It means that when reading someone else's code you can focus on the more important higher level aspects and not get distracted by unimportant differences.

There are I think significant social benefits as well - it eliminates a source of confusion for beginners (how do I format this to align with this project's conventions?), a source of tension for new contributors to a project (your PR is fine but it doesn't matching the coding style conventions of this project) and it general it gives the whole community a more cohesive feel.

[jlongster]

@natew I empathize with your point at well. I don't think we need to do everything at once. If we try to do too much, there's a real chance this project will die, so all of our efforts are nullified. Right now I want to constrain the scope to make sure we make this robust, and we can go from there.

[matb33]

Allowing configuration is a tough call at this stage because this tool today offers two things: a better formatter (parsing into an AST) and an enforced style. I believe many users seeing this project are more interested in the benefits that the parser brings than the enforced style, since we all bring our style baggage with us.

So what it comes down to is to clearly identify what this project is. Is it primarily a great parser with configuration to allow other styles, or is it a specific style with a great parser?

It sounds like it's the latter. I think it's the correct choice to start. Bang out the bugs and edge cases. Someone else can always stand on this project's shoulders and build the former.

[swansontec]

I would like to point out the standard.js project, which provides a style guide and a no-configuration linter. Their idea exactly mirrors this thread - we should all just pick something and go with it, even if some people get annoyed. The benefits of tabs vs. spaces or whatever just aren't worth the bike-shedding and general confusion.

Of course, this attitude does no good if all the opinionated tools disagree. Prettier is pretty close to the standard.js style already, and wouldn't take too much work to become 100% compatible. At 10k daily downloads on NPM, standard already has a lot of users who are ready for no-bikeshed, just-works style tools. From testing on my own codebase, which uses standard already, I see the following differences with prettier:

• no semicolons
• indent case statements
• space after function keyword (annoys me too, but hey, standard!)

Single quotes are already supported, but as an non-default option, so that's OK.

[matthewp]

@swansontec People who argue "you shouldn't have an opinion on style" are always the people who themselves have an opinion on style.

Opinionated tools are great and I agree with the less configuration the better. Choose the style you like for your own tool. Just don't try and pretend like you're really doing everyone else a favor by making their decisions for them.