[New] add prefer-exact-props rule

[jomasti]

This rule checks if non-exact objects are used for defining prop types when using Flow along with using normal objects for prop types instead of something like prop-types-exact to enforce only passing the exact props to a component.

The exact prop wrapper functions for non-Flow usage are configurable by adding the exact property to an object setting in the propWrapperFunctions config option.

Closes #1455

[ljharb]

Also note the propWrapperFunctions settings, with can be used to specify exact or forbidPropTypes.

Perhaps this warrants a new setting for "exact propType wrappers", that could also be checked everywhere the existing propWrappers are?

[jomasti]

Do you think it should be a global setting instead of just an option for the rule? I'm unsure of the other use cases for it being a global setting.

[ljharb]

@jomasti if it were a global setting, then other rules could access it to "unwrap" propTypes for their own uses.

[jomasti]

@ljharb Wouldn't these particular "exact props" functions still be in propWrapperFunctions in order to facilitate that?

[ljharb]

@jomasti right; the idea is that i'd be able to move forbidExtraProps etc out of propWrapperFunctions and into this new setting.

[ljharb]

I guess an alternative schema for the existing setting could be:

"propWrapperFunctions": [
  "Object",
  { "property": "freeze", "object": "Object" },
  { "property": "forbidExtraProps", "exact": true }
]

[maxammann]

What exactly is missing before this can be merged? Can we maybe split this task and add support for libs like airbnb/prop-types in an other task?

[ljharb]

@maxammann that support already exists; see the "propWrapperFunctions" setting in the readme.

This PR needs to be updated per the above comments.

[jomasti]

After doing some digging, it looks like the failures on ESLint 3 are due to versions 7.22+ of babel-eslint using eslint-scope over escope if available. This combination of the two results is weird errors for TypeAlias and maybe others. I'm not sure what I should do to rectify this.

[ljharb]

We could modify the dep range, and for eslint 3 in Travis.yml manually downgrade it?

[jomasti]

We could modify the dep range, and for eslint 3 in Travis.yml manually downgrade it?

Would you prefer for the before_script to be extracted to a separate script with this extra logic?

[jomasti]

Downgrading to a working version of babel-eslint breaks other tests, so it doesn't seem viable.

[ljharb]

Breaks other tests on eslint 3?

[jomasti]

Yes, using babel-eslint@7.2.1 with eslint@3 breaks tests that use object spread in type aliases and the short syntax for fragments.

[ljharb]

So what is it exactly about this pr that causes this breakage?

[jomasti]

It's looking for the TypeAlias variable in the scope. This works fine on eslint 4 and above because both it and babel-eslint use eslint-scope.

[ljharb]

Seems great!

(I'm going to hold off merging it for awhile while the 7.12 release settles down)

[EvHaus]

This rule seems to be eerily similar to no-unused-prop-types. Can you help me understand what the major difference is? We might even want to add a note to the README to explain why you might use this over no-unused-prop-types.

I get that this specifically forces exact definitions in Flow and PropType wrappers, but the underlying reason for that is to avoid unused props in a component -- is that right?

[alexzherdev]

I could be wrong, but my understanding of this is forbidExtraProps warns at runtime when a component's consumer passes in more than the component needs; whereas no-unused-prop-types warns if the component itself is not using some of the propTypes it declares. So it's two separate things.

[EvHaus]

That makes sense. Thanks @alexzherdev

[FelixButzbach]

What happened to this PR? Is there any other rule that can/should be used?

I would love to enforce the usage of exact from prop-types-exact in our project as it seams to have only advantages and no disadvantages...

[codecov-commenter]

Codecov Report

Merging #1547 (48e04c2) into master (f233eb7) will increase coverage by 0.02%.
The diff coverage is 99.05%.

@@            Coverage Diff             @@
##           master    #1547      +/-   ##
==========================================
+ Coverage   97.44%   97.47%   +0.02%     
==========================================
  Files         110      111       +1     
  Lines        7294     7395     +101     
  Branches     2665     2699      +34     
==========================================
+ Hits         7108     7208     +100     
- Misses        186      187       +1     

Impacted Files	Coverage Δ
index.js	100.00% <ø> (ø)
lib/rules/prefer-exact-props.js	98.82% <98.82%> (ø)
lib/util/propWrapper.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f233eb7...48e04c2. Read the comment docs.