Not sure if this should really count as `feat`, but any new rule getting added to the default set should at least show up in the changelog for users.
Also updated all the snapshots that needed to be updated for this.
Part of #18610.
Our intent is to move `definePlugin`, `defineRule`, and `eslintCompatPlugin` to a separate package `@oxlint/plugins` (plural to avoid confusion with naming convention for plugins `oxlint-plugin-xxx`).
So rename the current entry point which exports these functions from `oxlint/plugin` to `oxlint/plugins` (plural).
As we prepare for alpha release of JS plugins, it feels like we can remove the warning logged to stderr.
```
WARNING: JS plugins are experimental and not subject to semver.
Breaking changes are possible while JS plugins support is under development.
```
They do still remain experimental, but I don't think we need to shout that quite as loudly now.
this is going to be a hard parser error in a future release, so lets move this rule to correctness to allow people to take advantage of the fixer and migrate their code
This is technically breaking (only for types), but custom plugins are experimental.
The ruletester/defineRule/definePlugin are re-exported but with a `@deprecated` tag which I think is a good enough trade off
I want to avoid users bringing in a ton of custom plugin code when doing `import { defineConfig } from 'oxlint'`
This ensures that we print the expected number of rules for users that are using JS Plugins.
Fix#17519.
Based on #17517, because otherwise we'd end up with weird snapshot differences when trying to merge these anyway.
AI Disclosure: The fix here was generated with Copilot + GitHub's Raptor mini model.
For a while, we've been skipping the printing of rule runs unless `--disable-nested-config` was passed. This was a result of the nested_configs value including the base config (see #16356). When we were checking whether that value was empty, it would always have at least 1 item (unless nested configs were entirely disabled).
As part of this, I've updated some configs in the fixtures to disable correctness rules, otherwise we will end up with a bunch of fixture snapshots needing updates every time a new default rule is added.
It's probably easiest to review this one commit at a time.
Pure refactor of tests. Shorten fixture directory names. There's no need to include "custom_plugin" in dir names. *All* these tests are for custom plugins.
This PR doesn't alter content of any files, just renames them.
camc314