Add no-common-typos rule

[koenpunt]

I had it quite some time that I incorrectly used dangerouslySetInnerHtml instead of dangerouslySetInnerHTML.
To prevent certain typos I introduce a rule for which you can set a pattern and the corrected string.

I can imagine this might not only apply to attributes, in which case this rule could be extended to also validate props and other variables.

Todo:

• Documentation

[ljharb]

Please add test cases with SFCs, as well as class-based components.

[ljharb]

since configs come from JSON and YAML, when would it be an instanceof RegExp?

[koenpunt]

Because config can be JavaScript too:

Configuration Files - use a JavaScript, JSON or YAML
http://eslint.org/docs/user-guide/configuring

[ljharb]

Then instanceof is not reliable (due to cross-realm issues) and so we should be converting it to a string and parsing it.

[ljharb]

Either way, the schema should require it be a string, since rule schemas don't permit JS-only values, afaik.

[ljharb]

i'm very concerned about using full user-provided regex patterns without sanitizing them.

[koenpunt]

Why's that? Because of user's stupidity and potential rogue expressions?

[ljharb]

Yes, exactly that.

[koenpunt]

With fixing not enabled this shouldn't be an issue IMO

[ljharb]

users using a shared config that then run with --fix makes it an issue.

[koenpunt]

I changed it already so that regular expressions are always treated as string. Updated my previous comment to reflect that.

[ljharb]

I'm saying that the user of eslint should be protected against a malicious or accidental config, that might come from a plugin or a shared config.

Which means that the person who writes the pattern can't be trusted to mark it as safe - and neither can the user - which means the rule itself has to ensure that nothing unsafe can possibly happen.

[koenpunt]

So a predefined set of common typos, or better, common matchers like exact, case-sensitive, etc.?

[koenpunt]

For example:

"no-common-typos": [{
  "case-sensitive": {
    "somepattern": "SomePattern",
    "dangerouslySetInnerHTML": "dangerouslySetInnerHTML"
  },
  "exact": {
    "colour": "color"
  }
}]

[ljharb]

That's certainly one way to do it - or alternatively, [{ pattern: "SomePattern": caseInsensitive: true }] perhaps?

[ljharb]

why does this test need to use babel-eslint? all of these examples should use the default parser.

[koenpunt]

No idea, just used a different rule as boilerplate.

[koenpunt]

I ran the tests without parser specified, and then it raises errors, so I assume it is needed. Or why should it use the default parser?

[ljharb]

The default parser, but when ecmaVersion set to 6 or higher, and jsx set to true.

It should use the default parser because that's the important one it works with - if you also want to test that it works with babel-eslint that's fine, but that's secondary.

[koenpunt]

Also, I'm not sure about the schema.

Currently it requires patterns like so:

"no-common-typos": [{
  pattern: /somepattern/i,
  correct: "SomePattern"
}]

But maybe a format like this is better:

"no-common-typos": {
  "SomePattern": /somepattern/i,
  "OtherPattern": /otherpattern/i
}

[lencioni]

Would it be more useful to have a rule that knows what all of the DOM element props can be, and if you use something that isn't one of those it warns? That would have the advantages of working for everyone out of the box, and being specific for each individual node type.

[ljharb]

It's also worth noting that React itself does this for all DOM elements in React v15.3 and later.

[jseminck]

This can probably be closed now that we have the no-typos rule? Any specific cases that we want to add/support can go to that rule instead.

[ljharb]

Indeed, this is a bit duplicated by #1209.

Happy to reopen if it can be adapted.