My thoughts on Eslint dropping formatting rules
Tags: devrel, eslint, webdev, vscode
Published: 2023-11-20 21:21:49

## Eslint Dropping their Formatting Rules

ESLint has been my go-to tool for almost all of my Node.js projects. It is a mature and widely used tool that I rely on for its effectiveness. Moreover, I use ESLint as my default formatter, as it helps me maintain a consistent code style throughout my projects.

When [ESLint](https://eslint.org/) announced that they [deprecated their formatting rules](https://eslint.org/blog/2023/10/deprecating-formatting-rules/), my reaction was “WTF”…
I am aware that the ESLint team has always been [advised against using them as a formatter](https://github.com/eslint/eslint.org/issues/435).
However, I disagree.

## Why I think you should use it as a Formatter

Antfu made good points about [why he does not use Prettier.](https://antfu.me/posts/why-not-prettier)

> “It’s a Mess with ESLint”[^1]

And I agree. I spent so much time configuring both together…

[https://x.com/antfu7/status/1279149212974776320?s=20](https://x.com/antfu7/status/1279149212974776320?s=20)

For instance, my auto-fix settings in VS Code for ESLint and Prettier would constantly overwrite each other, causing frustration and wasting time.

When working with ESLint and Prettier, it's common to end up with two configuration files (and possibly two ignore files, making it a total of four files). One configuration file is for ESLint, and the other is for Prettier. I would advise against putting the configuration in the `package.json` file as it would make it unnecessarily large, and you would be limited to using JSON format. It would require additional effort to maintain.

> **Linters** are tools that verify and correct logical and non-whitespace style issues in code, such as naming consistency and bug detection. Linters often take seconds or more to run because they apply many logical rules to code. [²]

I think if you configure your VS Code correctly, it does lint on the fly. Why shouldn’t it detect stylistic rules? Yes, it may take a few seconds to run `eslint . —fix` , but I don’t think it is slow. Of course, it depends on the project size. But would it be much faster when we put the stylistic rules into Prettier and then run `prettier . —write`.  Which one should be executed first, ESLint or Prettier? 😵‍💫

Take advantage of the powerful capabilities of your IDE and let it handle linting and formatting on the fly. Here is my VS Code setting:

```json
{
  "editor.formatOnSave": true,
  "typescript.tsdk": "./node_modules/typescript/lib",
  "eslint.format.enable": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "typescript.format.enable": false,
  "prettier.enable": false
}
```

I disabled all formatter except for ESLint to make sure only ESLint is used here.

> It’s very opinionated [³]

Prettier forces you to use `printwidth`. Of course, you can adjust it. However, most likely, you have already run the formatter… Grr

See below and build your own opinion if Prettier makes this really “prettier” 🫠

![Prettier forces unnecessary wrapping/unwrapping](https://antfu.me/images/prettier-print-width.png)

## Okay, they deprecated it. What should we do now?

Using an older version is possible, but it is not recommended.

Anthony Fu started the project [ESLint Stylistic](https://eslint.style/), an ESLint plugin with all the deprecated formatting rules. The maintainer is one of the best, and I am pretty sure he will come up with something great.

But if you're looking for a reliable and efficient tool to manage your code, [Biome](https://biomejs.dev/) is the way to go. In my experience, it's far more effective than ESLint. I highly recommend trying it and seeing the difference it can make in your workflow, and you get a linter and a formatter in one tool.

And their benchmark is very promising[^4]:

> - Biome's ~25 times faster than Prettier
> - Biome's ~20 times faster than parallel-prettier
> - Biome's ~20 times faster than `xargs -P`
> - Biome's 1.5-2 times faster than `dprint`
> - Biome single-threaded is ~7 times faster than Prettier.

## Outlook

There is an interesting competition on going to [rewrite the prettier in Rust](https://console.algora.io/challenges/prettier).
I can only guess that Prettier will get faster.

Interestingly, the Biome team is also joining that competition.
[https://twitter.com/biomejs/status/1726365565348991346](https://twitter.com/biomejs/status/1726365565348991346)
I can imagine they will be merged together.

## Conclusion

ESLint has deprecated its formatting rules. The ESLint team advises using a Formatter just formatting. However, if your Linter is already reading your codebase, why should you run another tool to reread it? Luckily, there are several alternatives available that you can consider.

I advise using one tool for lining and formatting your code, whether using Biome or ESLint with the Stylistic Rules plugin, but that would avoid some maintenance overhead. Furthermore, if you have configured your IDE, it can lint and format your code on the fly.

And if you don’t work on Google’s Monorepo, I think you wait for the time to finish formatting 😉 

[^1]: [https://antfu.me/posts/why-not-prettier](https://antfu.me/posts/why-not-prettier)
[²]: [https://typescript-eslint.io/linting/troubleshooting/formatting/](https://typescript-eslint.io/linting/troubleshooting/formatting/)
[³]: [https://eslint.style/guide/why](https://eslint.style/guide/why)
[^4]: [https://github.com/biomejs/biome/tree/main/benchmark](https://github.com/biomejs/biome/tree/main/benchmark)