refactor: migrate off deprecated function-style rules in all tests

[bmish]

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
[ ] Add something to the core
[X] Other, please explain:

What changes did you make? (Give an overview)

This is a test-only PR that helps prepare for:

• RFC: RFC-85 (feat!: Require schemas and object-style rules rfcs#85)
• RFC implementation: feat!: drop support for function-style rules and rules missing schemas #16614

This PR only touches tests (and minor change to rule tester). It updates HUNDREDS of test cases that were using function-style rules to object-style rules. I did much of this manually but fixed a few hundred instances by writing a codemod. There were over 500 test cases needing to be updated ahead of the RFC implementation PR.

By merging these test updates first, the actual RFC implementation PR (focused on the breaking changes) linked to above will become dramatically smaller and easier to review. This will reduce the chance of ending up with substantial merge conflicts by the time the RFC breaking change PR can be merged for ESLint v9, and these test improvements are good to get in regardless. This will finally pay down the tech debt of still using hundreds of function-style rules in so many of our test cases. Updating and fixing these tests was ~6 hours of work but hopefully we're close to being done with function-style rules for good after this!

I recommend ignoring whitespace when reviewing.

Very rough jscodeshift codemod I wrote for limited parts of this (this is not at all complete, needs a lot of tweaking to handle a few different situations):

module.exports = function(fileInfo, api) {
    const j = api.jscodeshift;

    return api.jscodeshift(fileInfo.source)
        .find(j.CallExpression, {
            callee: {
                property: {
                    name: "defineRule"
                }
            }
        })
        .forEach(path => {
            if (path.value.arguments.length === 2 && path.value.arguments[1].type === "ArrowFunctionExpression") {
                path.value.arguments[1] = j.objectExpression(
                    [j.objectProperty(j.literal("create"),
                        j.functionExpression(null, [], j.blockStatement([j.returnStatement(path.value.arguments[1].body)])))
                    ]
                );
            }
        })
        .toSource();
};

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

[netlify]

✅ Deploy Preview for docs-eslint ready!

Name	Link
🔨 Latest commit	5836042
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/63901aa7dfc3180008c73055
😎 Deploy Preview	https://deploy-preview-16618--docs-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[mdjermanovic]

We should tag this as refactor: because of the changes in RuleTester.

[bmish]

@mdjermanovic updated from test: to refactor:.

[nzakas]

For consistency, I'd prefer we use the method form throughout:

{
    create() {

    }
}

This it the form we use in all of the core rules, so I think it's preferable to keep these in the same form.

[bmish]

@nzakas I agree with consistency, but a few things:

1. There are 200+ instances of create: context => ({ Program(node) { ... } });, and this format is used as a shorthand because they return an object. It's too much work to update all these by hand, so I would have to write a codemod to change to the longer form create(context) { return { Program(node) { ... } } } including adding the explicit return statement. Perhaps we should allow the shorthand style for functions that simply return an object.
2. Based on your request, I enabled the lint rule object-shorthand: ["error", "always", { "avoidExplicitReturnArrows": true }] and auto-fixed 100+ instances of the create function to the style you prefer (in a separate commit). When we're dealing with hundreds of instances of a function call, as we are in this PR, I think it's critical that we use linting/autofixers to enforce any style preference we have, instead of relying on manual edits.

[nzakas]

Agreed, thanks.

[nzakas]

LGTM. Thanks!

[nzakas]

Leaving open in case @mdjermanovic also wants to review.

[mdjermanovic]

LGTM, thanks!