Eslint-plugin-react: Move getStandardName logic from no-unknown-property into separate package

[davidtheclark]

The getStandardName function, which converts HTML attributes to their JSX equivalents, is widely useful outside of this module. There are lots of modules on npm that implement this themselves, in more or less complete form — they would all benefit from sharing a small and focused package that does nothing but this conversion.

eslint-plugin-react probably has more, and more committed, users than most of the other modules. So if it were to spearhead adoption of a focused package, the package would no doubt stay up-to-date, which would be a great thing for all the other modules that would rely on it.

@noraesae has already created https://github.com/noraesae/react-attr-converter, with the clear intention of serving this purpose. It would be awesome if no-unknown-property could use react-attr-converter, and eslint-plugin-react users could contribute to its upkeep.

What do you think? I could PR the switch if this sounds good.

[ljharb]

I think that it makes much more sense for React to own this, than for anyone in the ecosystem to do so - since React has the same logic internally. enzyme could also benefit from this.

@gaearon et al, what do you think?

[lencioni]

It seems like this might make sense for jsx-ast-utils. @evcohen thoughts?

[ljharb]

Fwiw, something for custom components already exists in airbnb-prop-types - require('airbnb-prop-types/build/helpers/getComponentName'). It'd just be better if it was a canon React implementation instead.

[gaearon]

In React we're trying to gradually move away from whitelists so I don't think we'll want to take on maintaining something like this (and thus making it seem like we encourage libraries to use it). It makes sense for tools but I think the community would do a better job of maintaining lists for ESLint etc. We don't often change those.

[ljharb]

@gaearon in general terms, as the community creates packages like that, would react be willing to commit to adding regression tests for them, to prevent unknown breakage when react makes a new release? That's really the sole reason I think it'd be important to have it be "from React".

[gaearon]

Can you create an issue in React repo? I'm not sure I fully understand what you're proposing.

[evcohen]

@lencioni most of jsx-ast-utils is specific to the AST, but we have added whitelists before for event handlers. Would be happy to maintain this list and function if it benefits the community!

plus eslint-plugin-react already depends on jsx-ast-utils so we could migrate for free, basically

[davidtheclark]

@lencioni @evcohen: I'm not sure why https://github.com/noraesae/react-attr-converter doesn't do the job. It could be incorporated into eslint-plugin-react, jsx-ast-utils, etc. Seems preferable to me to have a single-focus package for this, which other projects can then depend on.

[ljharb]

@gaearon https://github.com/facebook/react/issues/10051

[evcohen]

@davidtheclark that works just fine! there are tradeoffs for both, but I'm cool with that just as long as whoever owns that package is committed to maintaining it.