Stricter validation of return value from a rule's `create()` function

Current behavior

ESLint currently allows objects, arrays, functions, and literal values to be returned by a rule’s create() function. I suspect it’s unintentional that we allow anything but objects right now.

Rule visitor functions should be defined in a returned object. For someone wanting to bail out of a rule early, the current convention is to return an empty object:

module.exports = {
    meta: {
        // ...
    },

    create(context) {
        if (foo) {
            // bail out since rule doesn't apply
            return {};
        }
        return {
            BlockStatement(node) {},
        };
    }
};

Proposed behavior

Require the return value from a rule’s create() function to be one of the following:

Return Value	Description	Current Behavior	New Behavior
{ /* visitors */ }	standard object of visitor functions	Rule executes	No change
{}	empty object used for bailing out early	Rule no-ops	No change
null / undefined		Exception (see below)	I think it would actually be useful to allow these as a means to bail out early as they could be considered a more elegant way to signal no-op behavior vs. returning an empty object (note: this is an optional part of this proposal but could be omitted in favor of only allowing empty objects for this purpose)
All other data types (arrays / functions / literal values, etc)		Rule no-ops	Exception (see below)

Here’s the exception referenced in the table:

Error: The create() function for rule my-rule did not return an object.
Occurred while linting file.js

Links

_Originally posted by @bmish in https://github.com/eslint/eslint/pull/16075#discussion_r912190791_

See more context in https://github.com/eslint/eslint/pull/16075 where I added some messaging around this when the wrong return type is provided.

[mdjermanovic]

My thoughts:

• undefined - this could indicate a bug, in particular forgetting to return visitors in some code paths or at all. I think the current behavior is more useful than accepting undefined and silently doing nothing.
• null - this is less likely to be a bug, so it might be an alternative way to say that there are no visitors, but I’d still keep this simple and allow only a single way return {}.
• Primitive value - this certainly looks like a bug, I’m 👍 to throw an error.
• Array/Function - this looks a lot more like a bug than an intention. I would support throwing an error, but this might need an RFC to get attention.

[github-actions[bot]]

Oops! It looks like we lost track of this issue. What do we want to do here? This issue will auto-close in 7 days without an update.