Format using a formatter instead of ESLint formatting rules

[mightyiam]

ESLint formatting rules are going away. Use dprint, instead.

[voxpelli]

Or use https://eslint.style/

[mightyiam]

https://eslint.style is a fork of the style rules that are deprecated in ESLint and typescript-eslint.

I find this part from the deprecation blog post important:

Consistency issues. Because ESLint’s rules are designed to be atomic and not to have access to other rules, we would run into issues where it wasn’t possible to correctly fix an error because the information was in another rule. For example, if an autofix needs to add a new line of code, it would need to know how the file is indented in order to apply the correct fix. However, the indent rule controls indenting for ESLint, which meant that other rules needed to apply fixes without indentation and then trust that the indent rule would fix the indentation on a subsequent pass.

The architecture of ESLint isn't adequate for formatting.

[voxpelli]

It's been working this far, step one would be to use eslint.style

Going down the route of dprint will be extremely hard without causing lots of disruption. Believe me, I have tried

[mightyiam]

The disruption to the users amounts to having to accept the automatic formatting changes, I suppose?

[voxpelli]

A couple of things:

• Getting a dprint config that aligns with standard’s current formatting can be a challenge – there likely will be formatting changes (I tried getting one that matches the internal Prettier + ESLint setup at @SocketDev but had to give up, took more time than I could justify)
• Having a native dependency (which I believe that dprint in all its shapes is) can cause disruptions for some platforms
• The eslint-plugin-dprint is yet another mysticatea abandoned module (the others that standard rely on me together with some others managed to rescue into the ESLint Community org), but seems like at least one maintained fork exists: https://eslint-plugin-dprint.ben12.eu/

[wesleytodd]

IMO one of the strengths of standard is that it works on the 90% of important formatting cases but does not have opinions on the rest. This helps keep it palatable to a wider audience despite having some strong opinions, which is actually quite difficult to achieve. Abandoning that for a new tool seems like a lot of work, and has the chance to really break things for end users.

It is my opinion that we need a lot more analysis of the problem than this issue provides to make a good decision here, but that the default decisions should be to use the existing working setup as long as possible.

I don't have a strong opinion on dprint, but I am really uncomfortable choosing a native dep for this. Additionally it looks like that library is pretty generic, which likely means there will be a lot of work to use and might never really fully satisfy the needs.

[voxpelli]

What has happened that forces us to make a change?

ESLint 9 won't ship with style rules.

Why is that relevant?

Well, we want to support ESLint 9 eventually.

How can we support ESLint 9?

1. Drop style formatting completely
2. Follow the pattern that was used when ESLint dropped Node.js specific rules: Use a module that maintains those dropped rules separately
3. Add a formatter so that standard doesn't just use ESLint it also starts to use eg Prettier or dprint

Which is the least disruptive solution?

Using the very same rules as now but from an imported package

Would it be better to use a formatter?

Maybe, but that feels like out of scope of what standard is. Eg many are using standard side by side with Prettier already.

[wesleytodd]

Yeah this is great! Honestly I feel like this is a great foundation for a conversation about how to move forward. Good problem statement and doesn't jump to a conclusion or a specific tool recommendation. @mightyiam, maybe we could reframe the discussion less around choosing a specific solution first and help fill in more details on what our options are and the pros/cons of them?

[mightyiam]

Why is reformatting our users' code such a big deal?

[wesleytodd]

Why is reformatting our users' code such a big deal?

I am not sure I understand this question. Can you provide more details on what you are trying to get at with this question?

[theoludwig]

Maybe, but that feels like out of scope of what standard is. Eg many are using standard side by side with Prettier already.

Exactly! Many users are using Prettier and Standard side by side, so what's the point of including ESLint formatting rules, if it's indeed something that should be out of the scope of standard.

[theoludwig]

Would be best that Standard doesn't include any formatter, and only do the linting phase with ESLint.

[voxpelli]

Maybe, but that feels like out of scope of what standard is. Eg many are using standard side by side with Prettier already.

Exactly! Many users are using Prettier and Standard side by side, so what's the point of including ESLint formatting rules, if it's indeed something that should be out of the scope of standard.

@theoludwig That would require an additional formatter for feature parity

I agree with @wesleytodd on this:

IMO one of the strengths of standard is that it works on the 90% of important formatting cases but does not have opinions on the rest

If you want 100% formatting – add a formatter (and likewise, if you want 100% linting, go with a custom extension of eslint-config-standard)

standard is for describing and solving the 80-90% non-controversial stuff rather than prescribing solutions to the remainder 10-20%

[wesleytodd]

I think the ideal vision of the standard project was to stop arguing about linting and formatting in every project, to centralize that discussion, and then keep true to that decision for stability. Dropping formatting is, IMO, against that vision.

To circle it back to governance though, if there was governance in place we could have these discussions in an abstract way and then apply the "vision" to this issue. We don't have first principals documented, so we hare fighting out the "to format or not" discussion without agreement on the high level goals of the project. I would really like to formalize #1948 before any decisions like this are made personally.

[thorsby]

What has happened that forces us to make a change?

ESLint 9 won't ship with style rules.

I think ESLint 9 might be safe enough, according to the ESLint blog:
All of these rules will be deprecated as of the next release, but will not be removed until at least ESLint v10.0.0 (if not later).