Add more comprehensive examples of best practise eslint.config.js's for v9 migration

[TeemuKoivisto]

So I just updated my eslint to v9 and with it the default configuration file was changed to eslint.config.js

As someone who hasn't known about the configuration change at all, it was quite painful to realize how big of a change this major version update became. It wasn't immediately obvious where to find the new link for migrating https://eslint.org/docs/latest/use/configure/migration-guide and even from there reading such a huge article started to feel quite tedious as this was not what I wanted in the first place.

Some changes were easy like moving the parser and env blocks (although I'm not sure does env need to be renamed or nested under globals). However, with extends and plugins blocks I had no idea is importing them necessary anymore or what's the recommend best practise. It seems eslint:recommended was moved to "@eslint/js".configs.recommended so this added to the confusion. I am using TypeScript with Svelte and from quick searching I couldn't find an example I could have examined.

Here's a part of my config to show what I'm talking about:

{
  "root": true,
  "parser": "@typescript-eslint/parser",
  "plugins": ["svelte3", "@typescript-eslint", "eslint-plugin-import", "eslint-plugin-prettier"],
  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended", "prettier"],
  "env": {
    "es6": true,
    "browser": true,
    "node": true
  },
  "parserOptions": {
    "sourceType": "module"
  },
  "overrides": [
    {
      "files": ["*.svelte"],
      "processor": "svelte3/svelte3"
    }
  ],
  "settings": {
    "svelte3/typescript": true
  },
  "rules": ...
}

As it started to seem I was wasting my time when I could be productive, I reverted back to v8 and kept my old config since linting is quite minor problem in my case especially as I use prettier.

But as this migration will become unavoidable in the future, I'd really wish for more comprehensive eslint.config.js examples directly in the documentation to expedite the process. It's a fact most developers don't have the time nor motivation to read long migration docs and would rather just copy paste the new best practise example and figure out from there how to tweak it. Listing just a few at the top of the migration page would probably be enough; TS, prettier and some frontend framework related.

[MAST1999]

I would agree that the migration guide needs to expand on how to migrate the extends and plugin blocks.

[nzakas]

Thanks for the feedback. It looks like there are several examples using plugins, starting from here:
https://eslint.org/docs/latest/use/configure/migration-guide#importing-plugins-and-custom-parsers

We do also have a section on extends here:
https://eslint.org/docs/latest/use/configure/migration-guide#predefined-and-shareable-configs

It seems like these cover most cases.

Because the ESLint ecosystem is so vast, it's difficult to know what kind of examples will work for everyone. In general, we don't recommend using eslint-plugin-prettier or eslint-config-prettier, so probably not the best example to highlight.

We are working on a migration tool that should help with some of this.

In the meantime, if you think there are gaps in those two sections of docs, let me know what you think should be included.

[symplytheo]

Why did you say you don't recommend using eslint-plugin-prettier and eslint-config-prettier, especially as it's something we have been using with the previous versions?

[nzakas]

We've always recommended people avoid those, that's not new. Because they run Prettier inside of ESLint it is significantly slower and also can cause conflicts with ESLint rules. It's much better to run Prettier as a separate task after ESLint is run.