Rule: valid usage of messageId

[macklinu]

ESLint v4.15.0 introduced messageId. Looking at this code sample:

module.exports = {
  meta: {
    messages: {
      avoidName: "Avoid using variables named '{{ name }}'",
    },
  },
  create(context) {
    return {
      Identifier(node) {
        if (node.name === 'foo') {
          context.report({
            node,
            messageId: 'avoidName',
            data: {
              name: 'foo',
            },
          })
        }
      },
    }
  },
}

I would want a rule that:

• ensures that the messageId used in context.report() matches a key in meta.messages (in this example, avoidName)
• if meta.messages[messageId] contains a placeholder, it matches data[placeholderName] (in this example, {{ name }} matches data.name)

I'm wondering if the second bullet point should be added to eslint-plugin/no-unused-placeholders or as part of a new rule. I think the first case makes sense as its own rule.

What are your thoughts on this? I'd be happy to work on a pull request this week - looking for feedback on if this would be valuable and how to best include these features into this plugin. Thanks!

[not-an-aardvark]

Thanks, I think both of these ideas sound good. I agree that the second bullet point should be added to no-unused-placeholders (and possibly also no-missing-placeholders, which basically does the opposite of no-unused-placeholders).

[macklinu]

I tried to dive into resolving the second bullet point a few weeks ago, but felt like I was in a little over my head. I'm becoming more familiar with the ESLint APIs and working with rules, so I'm still interested in giving this another shot in the coming weeks. If you end up tackling this, let me know, but reaching out to let you know this is still on my radar. 😄

[bmish]

The second bullet point should be handled by #252.

For the first bullet point (check if messageIds exist and are used) we have a few options:

1. Create no-unused-message-ids and no-missing-message-ids (similar to no-unused-placeholders and no-missing-placeholders)
2. Or perhaps add these checks to the existing prefer-message-ids rule