Eslint-plugin-react: react/jsx-pascal-case warns on components that are all-caps abbreviations

Created on 26 Apr 2016  路  3Comments  路  Source: yannickcr/eslint-plugin-react

Some components by a user may contain all caps when it is an abbreviation, eg. <YMCA />, which is still technically valid PascalCase.

In the documentation it specifies that should throw a warning. Obviously it would be impossible for the parser to tell whether a component in all caps is a word or an abbreviation (unless, eg, it looked for punctuation, but even then still not certain).

Would you consider an optional parameter passed to the react/jsx-pascal-case rule to allow all-caps components, or perhaps to specify which component names are allowed to be all caps, would be appropriate?

I'm thinking:

"react/jsx-pascal-case": [2, {"all-caps": true} ]

or

"react/jsx-pascal-case": [2, {"exceptions": "YMCA"}]

Obviously it should still throw an error on components <ymca> or <yMCA>. I'm not sure what solution would best integrate with the rest of the project so open to your thoughts. I use several of these abbreviated components throughout many of my apps.

enhancement question

Most helpful comment

I think we could do both, I'll go for:

  • an allowAllCaps option (Boolean, false by default)
  • an ignore option (Array, [] by default)

(to follow the same options naming as the other rules)

All 3 comments

I like both of these ideas. "exceptions" would be useful in a general case.

Yeah, I'm still not so sure how well an "exceptions" option would work, since it seems like there are probably workarounds built into eslint (probably some kind of global, or if anything just add an eslint exception at the comment). But if it's something that might be useful to be implemented with other rules, I think it could work.

I think perhaps the lazy/fast way to go is simply to have a string config, either "strict" (default/as-is) or "caps-allowed" so one doesn't have to enter each component that is an exception (since it's not really an _exception_, but just a misinterpretation by the rule). Both these ideas are technically not mutually exclusive, but I imagine the latter ("caps-allowed" or "all-caps-ok") requires less code change (mostly just an updated regex).

I think we could do both, I'll go for:

  • an allowAllCaps option (Boolean, false by default)
  • an ignore option (Array, [] by default)

(to follow the same options naming as the other rules)

Was this page helpful?
0 / 5 - 0 ratings