[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 [email protected] 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.