config files in readme should not encourage top level config. overrides only.

[NullVoxPopuli]

tl;dr: without adopting a new file format, we can get people ready by doing suggesting folks do:

// .eslintrc.cjs
module.exports = {
  root: true,
  overrides: [
    /* configs here */
  ]
}

(no top-level config, overrides-only), and that's all there is to it!

---

Top level configs are problematic.

• https://eslint.org/blog/2022/08/new-config-system-part-1/
• https://eslint.org/blog/2022/08/new-config-system-part-2/
• https://eslint.org/blog/2022/08/new-config-system-part-3/
• https://eslint.org/blog/2023/09/preparing-custom-rules-eslint-v9/
• https://eslint.org/blog/2023/10/flat-config-rollout-plans/

We can start getting folks used to this style of config by forbidding top level configs and only using overrides in our documentation.
This will make the migration to eslint 9 (or the new config file, which is usable today) easier.

But the key take away is that config files will be overrides-only, dn the future.

Right now, folks can opt in to the eslint9 way entirely, but the ecosystem isn't ready. So only overrides in the classic config is a good stepping stone.

Here are some examples of this:

• The one lint config to rule them all (also how to get gjs/gts linting going) embroider-build/addon-blueprint#71 (comment)
• https://github.com/NullVoxPopuli/eslint-configs
  • in this one, folks will say it looks complicated, but they haven't admitted to themselves yet that managing eslint configs is complicated, and making it look simple is hard -- but also reasoing about what your config even is doing is hard (which, as a reminder, is one of the motivator for moving to a flat / overrides-only config)

both of these examples show how we can use the same set of configs for every project -- and with easy escape hatches (overrides).