eslint: Change Request: Add "did you mean" for slightly incorrect rule option keys

Okay, I think we are agreed on this proposal so marking as accepted.

Maybe we can make it a bit “smart” and suggest any properties that begin with the same letter

Sounds good to me.

and otherwise, just list out all of the properties?

Just to clarify, I think we should always list out all of the properties.

No, in this case we’re already displaying multiple errors.

This is what we’re currently displaying for the config from my previous comment:

Error: Key "rules": Key "prefer-destructuring":         Value {"VariableDeclarator":{"object":true},"array":false} should NOT have additional properties.
        Value {"VariableDeclarator":{"object":true},"array":false} should NOT have additional properties.
        Value {"VariableDeclarator":{"object":true},"array":false} should match exactly one schema in oneOf.

Now, I’ll just add a linebreak for diff clarity (we should probably format these messages better regardless of this issue):

Error: Key "rules": Key "prefer-destructuring":
        Value {"VariableDeclarator":{"object":true},"array":false} should NOT have additional properties.
        Value {"VariableDeclarator":{"object":true},"array":false} should NOT have additional properties.
        Value {"VariableDeclarator":{"object":true},"array":false} should match exactly one schema in oneOf.

The proposal is to display additional info below each error that relates to additional properties (I believe this is what @JoshuaKGoldberg is proposing too, just different data):

Error: Key "rules": Key "prefer-destructuring":
        Value {"VariableDeclarator":{"object":true},"array":false} should NOT have additional properties.
+               Unexpected property "array". Expected properties: "VariableDeclarator", "AssignmentExpression".
        Value {"VariableDeclarator":{"object":true},"array":false} should NOT have additional properties.
+               Unexpected property "VariableDeclarator". Expected properties: "array", "object".
        Value {"VariableDeclarator":{"object":true},"array":false} should match exactly one schema in oneOf.

If we’re always going to list out all properties then I don’t see any reason to also show properties beginning with the same letter. My goal was to shorten and simplify the output, but outputting everything all the time negates that benefit.

@mdjermanovic it sounds like you’re in favor of just listing potential properties rather than using a dependency to calculate the possible correct property?

Yes. I think we should list potential properties either way, and that alone will be a significant improvement in these messages. Additionally suggesting which of them is probably the right one would then be a small addition that maybe isn’t worth adding a new dependency.

I was curious if Ajv validation actually provides the data we need for this feature. By validateRule.errors for a test configuration "array-callback-return": ["error", { "foo": true }], it seems doable:

[
    {
        "keyword": "additionalProperties", // <- indicates a problem with additional properties
        "dataPath": "[0]",
        "schemaPath": "#/items/0/additionalProperties",
        "params": {
            "additionalProperty": "foo" // <- unexpected property name
        },
        "message": "should NOT have additional properties",
        "schema": false, // <- to be sure that the problem is caused by an unexpected property name
        "parentSchema": {
            "type": "object",
            "properties": { // <- keys of this object are expected property names
                "allowImplicit": {
                    "type": "boolean",
                    "default": false
                },
                "checkForEach": {
                    "type": "boolean",
                    "default": false
                }
            },
            "additionalProperties": false
        },
        "data": {
            "foo": true,
            "allowImplicit": false,
            "checkForEach": false
        }
    }
]

We’ve been actively trying to remove extra dependencies from ESLint, and I’m not sure there’s a big enough value-add here to take on another dependency. I’ll leave this open to get feedback from others on the team.