Could we put lint messages in rule metadata?

Inspired by #6738, where it was noticed that some of our lint messages are inconsistent about ending in periods.

I think it would be really awesome to have lint messages as a part of rule metadata. This does not have immediate benefit for linting, but it would allow us to do interesting things with auto-generated documentation, and even allow searching by error message on the site.

Proposed API

We would support a new messages key on rule meta objects. The value of this key is an object with arbitrary keys and with string values equal to different messages being used.

Examples

// lib/rules/array-bracket-spacing.js
module.exports = {
    meta: {
        docs: {
            description: "enforce consistent spacing inside array brackets",
            category: "Stylistic Issues",
            recommended: false
        },
        fixable: "whitespace",
        schema: [
            {
                enum: ["always", "never"]
            },
            {
                type: "object",
                properties: {
                    singleValue: {
                        type: "boolean"
                    },
                    objectsInArrays: {
                        type: "boolean"
                    },
                    arraysInArrays: {
                        type: "boolean"
                    }
                },
                additionalProperties: false
            }
        ],
        messages: {
            noBeginningSpace: "There should be no space after '{{ token }}'",
            noEndingSpace: "There should be no space before '{{ token }}'",
            requiredBeginningSpace: "A space is required after '{{ token }}'",
            requiredEndingSpace: "A space is required before '{{ token }}'"
        }
    }
    // create: function (context) ...
};

// lib/rules/no-continue.js
module.exports = {
    meta: {
        docs: {
            description: "disallow `continue` statements",
            category: "Stylistic Issues",
            recommended: false
        },

        schema: [],

        messages: {
            default: "Unexpected use of continue statement"
        }
    },
    // create: function (context) ...
};

Example usage:

context.report({
    node: node,
    messageId: "noSpacesBefore",
    data: {
        token: token
    }
});

Challenges

The main challenge is figuring out how to access the messages from within the rule visitor functions, where we typically don’t use object-oriented patterns. Very worst case (I’m hoping to avoid this), maybe we could augment RuleContext to support a getMessages() function which can return the available messages.

A smaller challenge is to convert messages that use string concatenation (see array-bracket-spacing source for an example) to use our token replacement engine instead. I assume this is not a significant roadblock.

Benefits

Here are the benefits I can see with doing this (none of which have to do with actual linting):

1. Make it easier for information architect types like @pedrottimark or @scriptdaemon or @aubergine10 to find lint messages and ensure consistency across all core rules
2. Rule documentation auto-generation could include a block showing the possible linting messages for a rule, so that a user knows how violations will actually look (notwithstanding placeholder tokens which depend on the violation context).
3. Rule linting messages could be indexed in the site search. That way a user could search for the error message they are getting, and we can pull up the rule generating that message. (Anyone remember jslinterrors.com?)

Etc.

What do folks think? Am I missing any significant challenges or roadblocks? Have I overstated the potential benefits? Or could this be worth pursuing at some point?

[platinumazure]

I think I count 3 approvals (@mysticatea, @nzakas, @ilyavolodin) and I’m willing to champion and implement.

Regarding i18n, I propose that we agree to try to implement in an i18n friendly manner, but that we do not attempt to include i18n in this specific proposal or to choose a particular library for it in this discussion.

Regarding potential implementation, I would propose something like this:

• Semver-minor PR to support messageId and meta.messages and implement in one or two rules
• Semver-patch PR to update documentation for context.report
• One or more semver-patch PRs to convert our rules to use this new style of message if all goes well
• One semver-minor (?) PR to create a new internal rule enforcing new style messages (pending feedback on usability for rule developers)

Does this seem like a sensible approach? Am I missing anything?

[j-f1]

An addition to this could be the ability for RuleTester to accept error objects in the invalid section with messageId and data, reducing code duplication.