Tools: Reconsider the preferFunctionDeclarations lint rule

[yassere]

The preferFunctionDeclarations lint rule warns against const functions like const foo = () => {} in favor of function declarations like function foo() {}

While I do personally like this rule, it's contentious enough that it may drive some people away since it can't be disabled and isn't practical to suppress globally.

And while that's the sort of tradeoff that opinionated tools can and do make, I don't believe that preferFunctionDeclarations provides enough value to justify the cost in potential users.

[sebmck]

What’s the cost to users? It’s auto fixable in all cases, and those that it isn’t we don’t emit an error.

What’s the bar for when a lint rule is considered inconvenient? I think a similar argument can be made for almost all the rules.

The idea behind having strong autofixes and autofix suggestions is that we can justify having conventions that would otherwise be tricky to enforce with a lot of mental overhead.

[yassere]

I don't think this rule is inconvenient for anyone who chooses to use Rome. But I do think this rule could be more of a deal-breaker for some people than most other rules.

Most of the lint rules are related to code quality, mistake prevention, or accessibility. There are only a handful that are style-related and they don't seem very controversial.

In contrast, people seem to have stronger, differing opinions about function style.

There's nothing wrong with a project being as opinionated as it wants to be, but I'd just wanted to hear people's thoughts on if it's worth picking a side on this particular issue.

[bitpshr]

When it comes to format-based or style-based lint rules and their enforcement, I tend to think of Rome as a code standardizer rather than a linter or a formatter. I feel that consumers should be able to code locally in any style that they choose, and that they should be able to confidently rely on rome lint --save to format their code in a standard manner before pushing. In this sense, Rome does not have to be used for local, as-you-go formatting if it doesn't produce output that aligns with a given style. But it should be used to then sanitize that given style before pushing code to a Rome-formatted repository. "Rome-formatted" repositories then become almost a pseudo-standard code style, and provide developers with uniformly-formatted code when stepping into new projects. This is similar in mantra to Prettier's original intention and it's also similar to other languages' builtin formatters that are simply not configurable, e.g. go fmt.

I feel that if any rule annoys consumers enough to prevent adoption, that Rome is either 1) failing to describe its effectiveness or its intention in its documentation, or 2) failing to provide an auto-fix that is sufficiently effective or frictionless.

[sebmck]

I think it would be good to establish some consistent criteria for the conventions we want to enforce. It might be worth having something in the governance document on how we build consensus. Right now it's been really adhoc and nothing has been too radical. We've benefited largely by not having a release. I anticipate a release probably in July (only blocker is the website) so we should have something figured out before then, especially if there's any existing rules that people feel are overzealous.

A lot of this hasn't been tried before in the JavaScript ecosystem. Prettier deliberately chose not to do any AST manipulation (which is actually a lie eg. quoted property keys can become unquoted which is "technically" an AST transformation). I don't know how much of that is just a technical limitation though.

If there's an opportunity to converge on multiple conventions then I think we should. Some of the other ones I've been thinking about include:

• Enforcing interfaces instead of object type aliases. We use object type aliases throughout Rome which is a holdout from when Rome used Flow where this is the convention. We can easily autofix them, so why not? (There are a few semantic differences but I don't think they're a blocker for having a "recommended fix").
• Arrow functions instead of function expressions, unless they use this (uncommon). Similar to preferFunctionDeclarations.
• Template literals instead of strings (extremely controversial)

These may feel arbitrary but it's reducing variance throughout a codebase and making it more homogeneous without shifting the burden to the developer and doing it automatically. Others might have the same wider epiphany of cognitive reduction that many did with code style when using Prettier.

I actually think the more controversial decisions are going to be styling decisions such as the usage of hard-tabs and double quotes. We benefit right now from establishing this philosophy prior to a release. If we appropriately set expectations then we can mitigate a lot of this criticism.

I've avoided saying it literally since it sounds pretty curt, but for some users there will definitely be decisions that feel arbitrary, and may even be personal blockers for them using it. The general idea is for Rome in aggregate will be so useful that they will just get over it.

[yassere]

It's a great idea to have an official process for establishing conventions.

For the most part, I think they should be decided by the project steward(s), but I think it's important that these decisions are made deliberately and explicitly, and that everyone feels comfortable providing feedback. Sometimes there are points that might not have been considered, and we should make sure that people have an opportunity to voice them.

For example, I didn't prefer hard tabs until I saw the compelling accessibility arguments in favor of them.

I'd suggest that any discussions about unrelated conventions each have their own thread so that the conversation can’t "move past" a particular convention that someone might want to discuss, and so that there's an easily-searchable history of the official decision.

[yassere]

I'll close this because this particular issue seems settled. I think that if we want to discuss conventions, either specifically or in general, we can open new issues for that.