Support propWrapperFunctions for boolean-prop-naming

[jomasti]

This adds support for checking prop types in boolean-prop-naming when using the propWrapperFunctions setting.

Closes #1452.

[ljharb]

We definitely don't want to just support any function call. Take a look at propWrapperFunctions for how this can be configured - we should probably add a new setting that defaults to ['Object.assign'], such that users could define _.assign or merge etc themselves. It could be named propObjectAssignFunctions perhaps?

[louisscruz]

Any progress on this?

[jomasti]

I think this is good based on the previous feedback, but @ljharb will have to review again.

[ljharb]

This LGTM; although it occurs to me that with object spread, there’s no need for a merge/assign function anyways - is there a reason you aren’t using object spread?

[jseminck]

@ljharb last I remembered ESLint supports node 4 which does not support object spread. I've had the same problems in the past. We still have Travis running builds on node 4 so I suppose we still have to support it.

[ljharb]

@jseminck I’m not asking about the rule implementation, I’m asking about users in their own codebase - also, object spread is trivially transpileable with Babel to Object.assign, or to any other package name via transform-replace-object-assign.

[jomasti]

@ljharb Now that I think about it, this change should just use the current propWrapperFunctions setting instead of a new one since we would want to support the other functions that could be used like forbidExtraProps and whatnot.

[ljharb]

@jomasti it could; but propWrapperFunctions is meant to convey "this function returns an object", which "exact" prop functions also do.

However, this rule deals only with "exact prop wrapper functions" - Object.freeze, for example, is a valid propWrapperFunction but not a valid exact prop wrapper function.

[jomasti]

@ljharb You may be thinking about my other PR for prefer-exact-props, but for this one (boolean-prop-naming), any function that returns an object should be supported, right? That would be beyond the current implementation of adding a new property (and probably unnecessary currently) (propObjectAssignFunctions).

Also, avoiding adding this should make it easy to change the schema of propWrapperFunctions to support your suggested schema in #1547 without having to remove this new setting.

[ljharb]

@jomasti oh lol i got confused, yes, i was thinking about the other one.

Yes, this rule should just use propWrapperFunctions, good call :-D