Deprecate formatting rules

[baseballyama]

Conclusion

Ultimately, we maintainers have decided not to actively maintain formatting rules. However, we welcome PRs from the community.

---

Description

Styling rules can be handled by Prettier. I think we don’t need to support such rules in ESLint.
If possible, I’d like to deprecate all formatting-related rules in v3. What do you think?

Styling issues: https://github.com/sveltejs/eslint-plugin-svelte/issues?q=is%3Aopen+is%3Aissue+label%3Aformatting

[marekdedic]

Hi, as a user of this plugin and prettier, I'd maybe support the removal of formatting rules such as indent - that one's better handled by things like prettier. 2 thoughts, though:

• I'd keep stylistic rules that are not related to formatting (I think the naming of these is confusing, e.g. eslint-stylistic in my opinion only contains formatting rules and not any other stylistic rules). By that I mean things like derived-has-same-inputs-outputs, prefer-*-directive, shorthand-*
• Some people prefer to use things like eslint-stylistic instead of prettier (I'm not one of them, but I think it's a legitimate preference). I think it'd be good to support that as well. That means that IMO rules that are not svelte-specific should be left to projects such as eslint-stylistic (maybe it'd be good to check that things like its indent rules work with svelte-eslint-parser?). On the other hand, there is no replacement for things like sort-attributes, which is Svelte-specific and therefore outside of the scope of other stylistic plugins (eslint-stylistic explicitly says it doesn't want to support framework-specific things, eslint-plugin-perfectionist removed support for them in the last major version etc.)

[baseballyama]

The term “styling rules” was ambiguous.🙏 What I meant was that I want to remove rules from ESLint that can be handled by “prettier.” In other words, rules that do not modify the AST.

[marekdedic]

Yeah, that's what I meant by "formatting rules", the naming here sucks generally :) That leaves my second point - some people prefer to use eslint rules over prettier and that I think is a valid choice as well...

[baseballyama]

some people prefer to use eslint rules over prettier and that I think is a valid choice as well...

This depends on our policy, and deciding that is exactly the purpose of this issue.

[baseballyama]

To clarify, this issue does not propose removing stylistic rules. It suggests considering the removal of rules that can be enforced by Prettier.

related: #193

[AlbertMarashi]

I am really opposed to being forced to use an entirely different formatting tool which is very opinionated

I gave prettier a shot, but it created more annoyance for me than it solved.

Here are my arguments against requiring an additional tool in the development stack:

• complicates CI/CD by adding yet another check to perform (svelte check, npm run lint)
• creates surface area for conflicts between formatting rules in eslint vs prettier
• eslint is perfectly capable of performing formatting changes
• prettier is opinionated, and I prefer to have my own opinions about how I want to perform things such as indentation.
• more plugins, code and extensions to install to get things properly working
• I already spend more time than I'd like dealing with environment setup instead of focusing on actual productivity.

Do we have another option: Having eslint-plugin-svelte handle template-related formatting, whilst leaving typescript and javascript linting to their relevant, respective plugins such as @stylistic/ts/indent and so on.

Edit
Linking for reference

• Indentation bug when using svelte/indent (RangeError: Maximum call stack size exceeded) #998

[ota-meshi]

I wrote a comment on another issue, but maybe I should have commented here 😓
#783 (comment)

So I'm reposting the same comment here.

In my opinion, support for stylistic rules is still needed.
Prettier is opinionated, so it might not be good for some projects.
ESLint is not a formatter, but the ESLint rule options are flexible, so I think the stylistic rules implemented in the ESLint plugin are still a good option for some projects.

However, maintainers have limited resources, so we give low priority to fixing/adding stylistic rules. I hope that those in the community who want to do it will submit a PR.

[AlbertMarashi]

I think to ease the load of stylistic rules for eslint-plugin-svelte we should completely focus specifically on the markup-related stylistic rules which should in theory be much easier to support.

ESLint rules for formatting Typescript code already exist, and I feel and believe that there is no need for the svelte/indent rule for example to worry about how script code should be formatted.

This removes much of the complexity of essentially having to write a whole bunch of code that is capable of handling indentation for all the typescript nodes (which is error prone, complex and even may conflict with other stylistic typescript ESLint rules)

[ota-meshi]

If that's a possible idea, feel free to submit a PR :)

[baseballyama]

Close this issue because we have reached an agreement on the conclusion.