feat(linter): configure by category in config files

[DonIsaac]

closes #5454

Adds a categories property to config files, where each key is a RuleCategory and each value is "allow"/"off", "warn", or "deny"/"error".

Note that this change won't come into effect until after #6088 is merged.

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

[DonIsaac]

• feat(linter): configure by category in config files #6120 👈
• refactor(linter): add schemars and serde traits to AllowWarnDeny and RuleCategories #6119
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @DonIsaac and the rest of your teammates on Graphite

[codspeed-hq]

CodSpeed Performance Report

Merging #6120 will not alter performance

_{Comparing don/09-27-feat_linter_configure_by_category_in_config_files (6e3224d) with main (c828b70)}

Summary

✅ 29 untouched benchmarks

[Boshen]

To be honest I haven't seen a single usage of these categories in the wild ... since it's a foreign concept from Rust.

Should we actually try and reduce complexity at this stage?

Or maybe it's just that there is no recommended usage documentation for these categories.

[DonIsaac]

To be honest I haven't seen a single usage of these categories in the wild ... since it's a foreign concept from Rust.

1. 5 our of 8 non-skipped repos we test oxlint-ecosystem-ci use these categories..
2. The way they are using these flags will break once feat(linter)!: support plugins in oxlint config files #6088 merges. This PR addresses the same user story that CLI flags (at least, the way these repos and many others are using them) used to solve.
3. I've seen various issues and Discord messages asking for this feature. I think it's something people want.
4. This would allow users who rely on the VSCode extension to perform broad-category rule configuration, something that is not currently possible (you can't configure CLI flags when running the LSP).

Should we actually try and reduce complexity at this stage?
Yes. I have two thoughts on this:

1. This integrates directly with existing filters. It's mostly just a change to Oxlintrc
2. Oxlintrc is meant to mimic eslintrc, so we can become backwards-compatible. In the future I see us having our own, more refined, config format.
3. That being said, we should be careful what features we add to this config file

[graphite-app]

Merge activity

• Sep 27, 10:55 PM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Sep 29, 11:04 AM EDT: Graphite rebased this pull request after merging its parent, because this pull request is set to merge when ready.
• Sep 29, 11:09 AM EDT: The Graphite merge queue couldn't merge this PR because it had conflicts with the trunk branch.
• Sep 29, 11:10 AM EDT: Boshen added this pull request to the Graphite merge queue.
• Oct 8, 6:18 PM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Oct 8, 6:18 PM EDT: DonIsaac added this pull request to the Graphite merge queue.
• Oct 8, 6:23 PM EDT: DonIsaac merged this pull request with the Graphite merge queue.