Eslint-plugin-react: Enhance forbid-prop-types to check for shape({})

[jeromecovington]

Does it make sense to enhance the forbid-prop-types rule to check for cases using shape that do not actually add clarity to the code, for example shape({}).

From https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/forbid-prop-types.md

By default this rule prevents vague prop types with more specific alternatives available

And:

This rule encourages prop types that more specifically document their usage.

When using for example shape({}) we are not more specifically documenting prop usage.

[jeromecovington]

Similarly it might make sense to check for arrayOf().

[ljharb]

That's a very specific pattern; shape({}) is certainly only trivially better than object; same with arrayOf() vs array - but I don't think that there's really a way to generically configure that in this rule.

[jeromecovington]

Yeah, I can't much argue for whether shape({}) (empty) is demonstrably better than object, only that shape({}) without any further definition of internal props doesn't actually more specifically document anything, which seemed to be the underlying goal of the forbid-prop-types. If nobody else thinks that goal is relevant, or if I am needlessly splitting hairs, I certainly won't be offended if this issue gets closed.

[ljharb]

If we can come up with a way to generically configure "propTypes that are functions that must take a non-empty argument", that'd be great.

I'm curious tho - are you actually seeing people using shape({}) or arrayOf() as a way to bypass these restrictions?

[alexlrobertson]

I use shape({}) frequently for components that consume an object and pass it to a child. The component doesn't care about the shape of the object, but the child does. Another use case would be style objects as the component doesn't need to care about the style shape.

I'm all for configurable style though.

[ljharb]

In that case, I'd recommend exporting the shape object from the child and using it on the parent, so that you get the error sooner :-)

[Palid]

+1, I've seen this used a lot where developers are just being lazy and don't want to document the type.

[amankkg]

+1, I've seen this used a lot where _I am_ just being lazy and don't want to document the type.
😅

[alexkrautmann]

I definitely would like for this to be configurable. I can't think of a good reason to do PropTypes.shape().