I would like to see a new CLI flag, --doctor, that would check the .oxlintrc.json file for any potential issues. This would help users protect themselves from misconfigurations or mistakes. This would ensure that users can easily diagnose problems with the config file, and we can provide better instructions to the user when there are specific, common problems we notice.

Other dev tools that implement a doctor command:

• Storybook: https://storybook.js.org/docs/api/cli-options#doctor
• Homebrew: https://docs.brew.sh/Manpage#doctor-dr---list-checks---audit-debug-diagnostic_check-
• npm: https://docs.npmjs.com/cli/v11/commands/npm-doctor

Below are some examples of checks we could implement. Some of these will require a lot of work to implement, and so should be split into separate issues. These are just ideas.

Invalid Rules

Rules in your config that don't actually exist (yet?)

{
  "$schema": "./node_modules/oxlint/configuration_schema.json",
  "rules": {
    "not-a-real-rule": "error"
  }
}

Invalid Plugins

Rules for plugins in your config that don’t exist, e.g. typo-ing a rule like testin-library/no-debugging-utils if “testing-library” was added via jsPlugins

This would mostly be useful if we can’t easily do this based on rule names, to protect users from accidentally misconfiguring jsPlugins. If we do the invalid rules check, this is probably not necessary?

{
  "$schema": "./node_modules/oxlint/configuration_schema.json",
  "jsPlugins": ["eslint-plugin-testing-library"],
  "rules": {
    "testin-library/no-debugging-utils": "error"
  }
}

Invalid Config Options

Rules in your configuration that have an invalid config option set, based on the config schema. E.g. config options that aren't real, config options that aren't the right type, invalid enum values, etc.

Type-aware rules without type-aware being enabled

Warn if any type-aware rules are configured without type-aware rules being enabled (either via --type-aware flag or the config option once we add it). Could potentially also check if oxlint-tsgolint is in the package.json?

Missing $schema field

Print a message (but don't error) if the $schema field is missing in the oxlint config file.

{
    "rules": {
        "import/no-default-export": "error",
        "import/namespace": "allow"
    }
}

Duplicate rules via alias names

e.g. typescript/foo and @typescript-eslint/foo

{
    "$schema": "./node_modules/oxlint/configuration_schema.json",
    "plugins": ["typescript"],
    "rules": {
        "@typescript-eslint/explicit-function-return-type": "error",
        "typescript/explicit-function-return-type": "warn"
    }
}

Probably the same thing with certain rules like no-unused-vars and its ts equivalent? Plus rules with and without the eslint prefix.