feat!: drop support for function-style rules and rules missing schemas

[bmish]

UPDATE: this PR was replaced by:

• feat!: Set default schema: [], drop support for function-style rules #17792

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[x] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

This implements RFC-85 (eslint/rfcs#85) for these two scenarios:

• Drop support for deprecated function-style rules in favor of object style rules
• Require rules with options to specify a schema

This is targeted to be merged as a breaking change in ESLint v9. It's a follow-up to @snitin315's work to add warnings in #16063.

Notable changes:

• Rule tester now throws instead of warns for the two scenarios
• Core no longer normalizes function-style rules into object-style rules
• Core throws when attempting to create a function-style rule (and added a test case for this)
• Retrieving a schema for a rule now defaults to the “no options” schema when no schema is specified
• Updates documentation to mention the new requirements
• I extracted HUNDREDS of updates to test cases that were using function-style rules in refactor: migrate off deprecated function-style rules in all tests #16618
• Throw with no-op schema schema: {}
• Implement, document, and test schema: false opt-out feature
• Ensure all rule examples in docs that have options also have a schema

Is there anything you'd like reviewers to focus on?

Should we delete docs/developer-guide/working-with-rules-deprecated.md. Perhaps we should delete most of the content and keep a barebones doc in place to avoid breaking links.

I'm a bit unsure about the below comment from an earlier PR. Should I duplicate the tests into FlatRuleTester? Should we still be relying on asserts in rule tester at all?

Should we also duplicate these changes in FlatRuleTester?

I think it isn't necessary since we are planning eslint/rfcs#85 for ESLint v9, and FlatRuleTester will not replace RuleTester before ESLint v9. When we implement eslint/rfcs#85 in linter/config, these deprecation warnings will become errors thrown by linter/config.

[eslint-github-bot]

Hi @bmish!, thanks for the Pull Request

The first commit message isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.

• The length of the commit message must be less than or equal to 72

To Fix: You can fix this problem by running git commit --amend, editing your commit message, and then running git push -f to update this pull request.

Read more about contributing to ESLint here

[netlify]

✅ Deploy Preview for docs-eslint canceled.

Name	Link
🔨 Latest commit	1cd2266
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/63968eb50dffab000898f928

[eslint-github-bot]

Hi @bmish!, thanks for the Pull Request

The first commit message isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.

• The length of the commit message must be less than or equal to 72

To Fix: You can fix this problem by running git commit --amend, editing your commit message, and then running git push -f to update this pull request.

Read more about contributing to ESLint here

[nzakas]

I think it may be a bit too early to be filing a breaking PR when we haven't even planned ESLint v9 yet.

Switching to a draft to avoid accidental merging, but I think it may be better to close this and hold on to the changes until we are actively planning for a major release.

[ddzz]

Seems like these tests could be updated to remove the use of should.

[bmish]

How else would you write it? I do want it to read like an English sentence.

[bmish]

@nzakas "draft" status works for me as I'd love to begin receiving and responding to feedback on this. I will likely have 4 breaking change RFCs to implement for ESLint v9, so I wanted to start preparing them now so they are lined up and ready to go whenever you decide to schedule the release. My concern is that each of these PRs could take several weeks of work, and if I wait until ESLint v9 is announced, I won't have time to complete them.

[github-actions]

Hi everyone, it looks like we lost track of this pull request. Please review and see what the next steps are. This pull request will auto-close in 7 days without an update.

[Rec0iL99]

@bmish wants this open for feedback. Don't close.

[github-actions]

Hi everyone, it looks like we lost track of this pull request. Please review and see what the next steps are. This pull request will auto-close in 7 days without an update.

[github-actions]

This pull request was auto-closed due to inactivity. While we wish we could keep working on every request, we unfortunately don't have the bandwidth to continue here and need to focus on other things. You can resubmit this pull request if you would like to continue working on it.

[nzakas]

@bmish this PR seems very out of date and hasn't been updated in a while. What do you think about closing this for now? You can always pick up the work and submit a new PR later.

[github-actions]

Hi everyone, it looks like we lost track of this pull request. Please review and see what the next steps are. This pull request will auto-close in 7 days without an update.

[nzakas]

Okay, we are just going to close this. @bmish you can feel free to resubmit when it's time.