Absolutely love oxlint and it's working great, however some feedback: as someone who was never that familiar with eslint and all of its intricacies (I configured it, then willfully put it out of my mind for as long as possible...), the docs + the default oxlint --init config + cli output don't do a good job at telling me "you probably don't need this" for all of the myriad compatibility configuration options that are not applicable to most people, as well as guiding the user into the pit of success.

As a user, I went through a lot of like "what happens if I just delete this option? oh... nothing? ok... I guess I will just leave it deleted...?"

Examples:

Env and globals

https://oxc.rs/docs/guide/usage/linter/config.html#configure-environments-and-globals

{
  "env": {
    "es6": true
  },
  "globals": {
    "MY_GLOBAL": "readonly",
    "Promise": "off"
  }
}

There's not really any default guidance on env or when to use it (I'm assuming it's all eslint compatibility stuff). As a new user, how do I know if I should be using "es6": true? How is this different from "builtin": true? browser? node? oxlint seems to work in my repo without any of those, so when exactly would I need them? What if I add a global declaration while using typeAware: true? Would oxlint know about it implicitly without me having to declare it here or not? (I know there is a docs page dedicated to that, but docs should say something upfront like "you probably don't need this" without having to read through everything)

Also, env keys don't seem to show up in LSP hover (i.e it's not part of the json schema) making discovery harder here as well)

Default Settings Clarity

    react: {
      version: "18.2.0",
    },

how do I know if I should configure my react version? If I'm on the latest, will ist just work automatically, or no?

The default oxlint --init comes with jsx-a11y, next, react, jsdoc and vitest settings out of the box with no comments in it (even though it could, because oxlint supports .jsonc configuration files!), and the default version: null violate the $schema

As a user, I again ask myself: Why did they include 8 default options for jsdoc out of the box? Does that mean they're different from the defaults and I shouldn't change them? What happens if I delete jsx-a11y? Will lint rules start failing in my react codebase? What happens if I don't add version fields here? I don't have any errors so far, so am I silently missing things?

Rule naming consistency

There's some consistency issues with rules that can make things quite confusing:

• Oxlint allows you to just use consistent-type-imports instead of typescript/consistent-type-imports, but accepts both. In my opinion, it makes sense to use the prefix, but https://oxc.rs/docs/guide/usage/linter/rules.html eliding the prefix makes this very confusing (while most of the rest of the docs do not elide the prefix)
• If you have a rule in your config (e.g import/no-named-export) without also enabling the "import" plugin, oxlint will silently proceed with no issues and no error on that rule. I feel like there should probably be an associated warning to tell you to enable that plugin.
• The default output format of oxlint cli's rules (again ) is confusing and arbitrary: eslint-plugin-import(no-named-export): Named exports are not allowed.
  • Why would it not be import/no-named-export, making it easy to copy-paste into your config?
  • Worse, typescript rules use typescript-eslint(...), but the prefix for the rule is typescript/
  • It doesn't mention the category at all, so you have to trial & error (or go read the docs) to figure out why the rule was enabled in the first place.
  • putting ourselves in the shoes of someone who isn't coming from the context of an eslint migration: Why does it mention eslint at all? What is this strange "eslint" that my core tooling keeps referring to but that has no relation to my configuration?
    • (eslint users are very familiar with import/no-named-export syntax anyhow, so this would not make it more confusing for them either)

Categories and default-enabled rules

From what I can tell, the default oxlint --init configuration comes out of the box with only correctness rules enabled, and only for a subset of the plugins. However, there are a few issues:

• As a new user, I want to enable some import rules. I've fixed all the current rules that the default --init gave me. Now, I change plugins: null to plugins: ["import"]! I get my import error. However... now, silently, I've accidentally disabled the rest of the default plugins and there's nothing that indicates my mistake here.
• Just enabling correctness category is a good default imo, however the fact that only correctness rules are enabled by default and that there's tons of very useful rules not in that category isn't very apparent. The default --init configuration coming with the categories mentioned + a one-liner comment explaining would be helpful here.
  • Again, guiding towards the pit of success: include the categories commented out with the levels that you think would be reasonable if the user desires to turn them on (e.g "error" for suspicious perhaps, "warn" pedantic)