Tools: Use .editorconfig for file formats like spaces vs tabs 💭

[CodeByCorey]

When you run rome init it adds an .editorconfig

Some projects and companies have policies where you are required to use spaces over tabs.

It would be nice to know I can change my editorconfig to spaces.
Running rome check would then use the spaces over tabs.

[CodeByCorey]

I understand Rome is supposed to be very opinionated but there are a few things that would be nice to customize.

[ematipico]

There was a discussion here https://github.com/romefrontend/rome/issues/425

[CodeByCorey]

That looks like it's just a discussion of forcing Tabs over original spaces. But never about allowing the user of Rome to decide what they want to use with some sort of config.

[bitpshr]

I definitely understand the initial desire to configure various lint rules within Rome to match existing code styles.

The rules that Rome has chosen to enforce have been approached objectively, and have been added to the toolchain specifically to push consumers towards best practices that tangibly offer objective advantages. For example, if any consumer - company or otherwise - has chosen to adopt spaces over tabs, they're probably doing so at the cost of usability for many developers. I would argue that such consumers should try to understand the reasoning behind the decision within Rome and to change their practices accordingly. In my mind, that's the very purpose of an opinionated toolchain, and a key differentiator of Rome from past projects. Note that some rules will still have to allow configuration by necessity.

If this ever proves too restrictive, and a consumer still wishes to use different conventions, they can still do so locally; just run rome check --apply before committing, similar to how go fmt universally-formats Go code with zero configuration. This essentially facilitates a universal coding style (regardless of what local coding preferences are used) and makes switching between unrelated projects even easier across the ecosystem.

[sebmck]

Rome being opinionated doesn't necessarily mean we don't need to have configuration. However, for this specifically, I don't expect us to have any way to configure formatting options.

If you're going to adopt the Rome formatter then it's likely going to cause an extreme amount of formatting churn anyway since we do not aim to match Prettier, which is the predominant code formatter and likely what you might already be using. Since that's the case, switching to tabs isn't actually anymore difficult.

Changing code style is something that is actually relatively easy to technically do, but requires an extremely high amount of social buy-in. I hope that using Rome can be a forcing function to encourage more inclusive formatting standards.

I'm not sure if this has been said explicitly, but the idea is for Rome to be so useful and advantageous in so many other ways, that people with strong opinions and constraints will be willing to change them to use it.

[estevanmaito]

I'm not sure if this has been said explicitly, but the idea is for Rome to be so useful and advantageous in so many other ways, that people with strong opinions and constraints will be willing to change them to use it.

Off topic, but I think this should be fixed somewhere, or at least be highlighted in Philosophy.

It's like "explain it like I'm 5".

[sebmck]

I'm open to including it in the intro. The "Rome has strong conventions and aims to have minimal configuration" paragraph would be good to clarify. If anyone is opening to making the change, then you can make it to README.md, and then run ./rome run scripts/generate-all-files which will also update the website homepage markdown.

[Blocked]

Asking every other editor to follow .editorconfig, while Rome won't do the same is hypocrisy. There should be a way to configure to whatever style users want to use, regardless of the default superior objective opinion. Opinions shouldn't be forced.

[ljharb]

Regardless of what Rome decides to allow to be configured, it does seem like Rome should error when an editorconfig exists that it's not going to comply with - iow, Rome should either obey an editorconfig, or should force the editorconfig to match "what Rome does".

[sebmck]

@Blocked You aren't being somehow oppressed by this decision. The inability to customize something doesn't make it hypocritical to enforce other tools/editors to follow the same convention. There are many configuration options we could theoretically have, and their omission isn't some grandiose statement. Delete the .editorconfig if you want, nobody is forcing you to use it. We create it during rome init so people have a more consistent experience. Most people will not even notice they're using hard tabs.

We will likely be publicly pressured into supporting additional configuration for formatting and disabling lint rules, largely to increase commercial adoption. Unless you're going to commit to working on Rome and maintaining the things you're aggressively proposing, trying being kinder vocalizing your criticism, especially when the rationale has been explicitly stated and we're all working on this for free in our spare time.

[sebmck]

For what it's worth, anecdotes are the most useful here, since organizational blockers that would prevent adoption are the most serious issue. I am less likely to engage in hysterics and it just causes work in these areas to be deferred since I'd rather work on things that don't make people pissed off and post overtly negative comments.

[CodeByCorey]

I understand the decisions you guys made.

You want to follow best practices and make sure everyone else is too.

The argument where tabs are the better choice because it allows every user to change the "size" of their tabs without affecting the code base is valid. I guess I just stick to spaces because that is required for python and it keeps me from having to switch between projects. I know that isn't the best excuse because you can use the .editorconfig to automate all that for you.

[sebmck]

We are most likely going to add indentation options but the default will stay as a hard tab. I expect this to happen when we add a bunch of other options (such as disabling lint rules etc).

[ematipico]

The options have been added. We can close.