For (almost?) any CLI flags, we should also be able to configure behavior via the configuration file.

For comparison, ESLint allows configuring reportUnusedDisableDirectives via the config file, as described here. And it's enabled by default in ESLint v9.

In order to ensure that everyone is using the same settings on a software project, configuring everything via the config file is preferable. It makes it easier for all LSP-based editors to get consistent linting, and ensures that all developers on a project can be using the same set of rules when running npm run oxlint as their coworkers, their editor, and CI.

Flags that should be added to the config file:

• "typeAware": true/false, equivalent to the --type-aware flag. Defaults to false if unset. feat(linter): introduce typeAware as config options #19614
• "reportUnusedDisableDirectives": off/warn/error, equivalent to --report-unused-disable-directives and --report-unused-disable-directives-severity. Defaults to off if unset. (feat(linter): add options.reportUnusedDisableDirectives to config file #19799)
• "noIgnore: true/false", equivalent to --no-ignore, defaults to false if unset.
• "disableNestedConfig": true/false, equivalent to --disable-nested-config. I'm a bit unsure on this one, as it'd potentially be a bit weird behavior-wise.
• max-warnings feat(linter): introduce maxWarnings config option #19777
• type-check feat(linter): introduce typeCheck config option #19764
• "tsconfig": path/to/file, equivalent to --tsconfig=. Only necessary if the tsconfig file is not at the root of the cwd. I (@camc314) am going to deliberatly skip supporting this. We have auto tsconfig discovery that should be used instead of this - if someone want this, they can make an issue and we can re-evaluate.

Output for these from the --help command:

        --tsconfig=<./tsconfig.json>  TypeScript `tsconfig.json` path for reading path alias and
                              project references for import plugin. If not provided, will look for
                              `tsconfig.json` in the current working directory.
        --no-ignore           Disable excluding files from `.eslintignore` files, --ignore-path
                              flags and --ignore-pattern flags
        --report-unused-disable-directives  Report directive comments like `// oxlint-disable-line`,
                              when no errors would have been reported on that line anyway
        --report-unused-disable-directives-severity=SEVERITY  Same as
                              `--report-unused-disable-directives`, but allows you to specify the
                              severity level of the reported errors. Only one of these two options
                              can be used at a time.
        --disable-nested-config  Disable the automatic loading of nested configuration files
        --type-aware          Enable rules that require type information

The only major question I have is what takes precedence, and whether we should introduce flags to turn some features off.

Right now, to get type-aware rules, you have to use npm run oxlint --type-aware, but if typeAware: true were enabled via the config file, there would be no way to turn it off (other than editing the config file, obviously). We could introduce a --no-type-aware flag if we really wanted to, I guess? But I don't think that should block this work regardless.

We also should decide whether we want to include these config options at the top-level of the config file, or if they should go into a linterOptions object instead.