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.