Inclusion of barely-more-than-formatting rules?

[JoshuaKGoldberg]

Following up on eslint/eslint#17522 & #19: I think there is a small discrepancy between the name (stylistic) of this plugin and what it's going to be used by most devs as at time of announcement (formatting). eslint/eslint#17522 mentions several rules that aren't covered by some or all formatters, but debatably may fall into the category of stylistic rules this plugin should cover:

• curly
• padding-line-between-statements
• no-unexpected-multiline
• no-mixed-operators

Would it be reasonable to include these rules in eslint-stylistic, but only enable them in a dedicated config for non-formatting stylistic rules? If not, and this config really is just for the formatting rules, maybe it should be named eslint-formatting after all? (is that a false dichotomy?)

For anecdotal context/evidence, in https://github.com/JoshuaKGoldberg/create-typescript-app (which uses Prettier for formatting):

• curly is provided by https://github.com/JoshuaKGoldberg/prettier-plugin-curly (https://github.com/JoshuaKGoldberg/create-typescript-app/blob/ae148f607cdd79e829d8c7dfcec28045a3eb3953/.prettierrc#L7)
• @typescript-eslint/padding-line-between-statements is being run in ESLint (https://github.com/JoshuaKGoldberg/create-typescript-app/blob/ae148f607cdd79e829d8c7dfcec28045a3eb3953/.eslintrc.cjs#L163)

cc @bradzacher

[ljharb]

All of those are stylistic - stylistic rules objectively prevent bugs, despite the incorrect belief of some that they’re purely aesthetic.

[JoshuaKGoldberg]

@ljharb I agree but don't see how that's relevant here? Does part of this issue imply otherwise accidentally?

[ljharb]

ah, maybe i misread.

I think that it's better for the scope of this plugin to be stylistic and not just formatting, since it's likely that eslint will continue to remove swaths of rules over time and punt the work to the community.

[antfu]

From my point of view, I named it ESLint Stylistic instead of ESLint Formatting because I want to be inclusive, as sometimes the border between stylistic and formatting could also be ambiguous. Naming as Stylistic means that we are welcoming stylistic rules that could go beyond a bit of pure formatting.

curly to me is a "formatting" rule (despite that Prettier doesn't want to handle it). Under the name ESLint Stylistic, it doesn't matter whether it's been categorized as "formatting" or "stylistic" - we are happy to have it either way.

I think the current problem might not be "how we categorized them", but rather "what ESLint would let go". If ESLint team wants to keep maintaining curly et al. it makes less sense for us to port and maintain them because "we don't want to duplicate the effort" but rather "we don't think it's in the scope of ESLint Stylistic".

In short, I'd be happy to have them here as long as ESLint team also agrees on that.

[antfu]

Close in favor of eslint/eslint#17681