Add forbid-foreign-prop-types rule

[iancmyers]

People may want to use babel-plugin-transform-react-remove-prop-types to remove propTypes from their components in production builds, as an optimization. The forbib-foreign-prop-types rule forbids using another component's prop types unless they are explicitly imported/exported, which makes that optimization less prone to error.

I've included the use-cases described in #696 as tests. I'd be happy to add additional test cases if recommended.

Fixes #696

[lencioni]

It would be nice to link to the babel plugin here.

[lencioni]

Unfortunately, even importing like this does not ensure that propTypes is explicitly exported from the module (and not just a property on the exported object).

What do you think about making this rule additionally ensure that propTypes is explicitly exported when being imported as well? Alternatively, if there is a rule in eslint-plugin-import that covers this, we should mention it here.

Also, this line should be

import SomeComponent, {propTypes as someComponentPropTypes} from './SomeComponent';

[iancmyers]

@lencioni Looks like eslint-plugin-import has the named rule which would ensure that named imports are also named exports: https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/named.md

[lencioni]

This is great! Will you please add a note about this and a link to the rule in the documentation?

[ljharb]

eslint-plugin-react still supports node 0.10, so please use array.prototype.find here instead (after this is merged, i'll update #1038 to switch back to .find)

[ljharb]

none of the code in this test requires object rest/spread or babel-eslint; could these tests just stick with espree?

[ljharb]

it'd be helpful if the error could include the position of the warning, so that editors can jump the cursor right to it

[lencioni]

It might be worth adding some valid cases like:

const foo = propTypes
foo(propTypes)
foo + propTypes
const foo = [propTypes]
const foo = { propTypes }

And maybe even junk like this (note the lowercase):

foo.propTypes
foo['propTypes']
const { propTypes } = foo

[ljharb]

I'm not sure why lowercase matters - I agree that cases where it's an object or array literal should be valid, but class foo extends React.Component should have the same restrictions (someone could always import Foo from './foo' and use it just fine)

[ljharb]

I think this plugin already has some component detection logic we could reuse?

[lencioni]

I was thinking lowercase should perhaps be allowed because in React, components must be uppercase. Lowercase means DOM element. But this distinction is unlikely to matter much here. Reusing component detection logic sounds good to me.

[oliviertassinari]

@iancmyers Thanks for working on that!
I have tried an iteration at the babel plugin with no luck.

react-native is encouraging the following pattern. We might need an exception.

import {View} from 'react-native';

class CustomView extends React.Component {
  static propTypes = {
    style: View.propTypes.style
  };
  render() {
    return (
      <View style={this.props.style}>..</View>
    );
  }
}

[ljharb]

That's just static class properties (which are a stage 2 proposal) - definitely those should be covered as well, but since it's just sugar for CustomView.propTypes = …, it shouldn't be difficult.

[iancmyers]

@lencioni @ljharb I've taken another pass at this and addressed much of your feedback.

[ljharb]

LGTM

[ljharb]

will a node always have a .parent property?

[iancmyers]

I believe that MemberExpression and ObjectPattern will always at least have a parent of Program.

[lencioni]

@iancmyers thanks for your contribution!

@oliviertassinari Thanks for raising this scenario. I'm going to merge this as it is, and we can follow up with an improvement to address that if we need to. One thought is to allow referencing propTypes on objects imported from packages, but we can discuss the details in a separate issue or PR.