Feature request for some extra rules

[otakustay]

We are currently creating a react code style guide, there are some rules we find useful but not covered by eslint-plugin-react:

1. Use a index module for cross-directory component import

   Warns on:

   import Foo from '../components/Foo'

   Not warn on:

   import {Foo} from '../components'
   
   import {Foo} from '../components/index'

2. Use default export for component jsx file

   Warns on:

   let Foo = ({message}) => <div>{message}</div>;
   
   export {Foo};

   Not warn on:

   export default ({message}) => <div>{message}</div>;

3. Default exported comopnent must have the same name of its filename

   Warns on:

   // in Foo.jsx
   export default class Bar extends Component {
       // ...
   }

   Not warn on:

   // in Foo.jsx
   export default class Foo extends Component {
       // ...
   }

   An ignoreAnonymouse flag can be set to ignore stateless component without a name

4. Use static properties to declare propTypes, defaultProps, etc

   Warns on:

   class Foo extends Component {
       // ...
   }
   
   Foo.propTypes = {
       // ...
   }

   Not warn on:

   class Foo extends Component {
       static propTypes = {
           // ...
       }
   
       // ...
   }

5. Do not import react when only JSX syntax is used

   Opposite to existing react-in-jsx-scope rule, this warns when react is imported but not explicitly used, this can be useful when using babel-plugin-react-require

6. Do not implement shouldComponentUpdate for components which extend PureComponent

   See React issue

7. Check for jsx's depth

   We want to restrict jsx to a depth of 3 or 4, this is something like restricting nested block in common js code

8. Forbid any non-primitive expression in jsx props

   Any expression except primitive values can cause shallow compare in PureComponent to break, this may include function expression, function bind (both .bind call and :: operator), object or array literals, function calls, etc...

[ljharb]

Thanks!

1, 2, and 3 are more appropriate for eslint-plugin-import. If you can't currently cover it with existing rules, please file issues there (and we can discuss further).

4. Class properties are not yet a part of the language - they're only stage 2 - so I think it's way too premature to create a rule requiring their use. Regardless, this should be a core rule once it's stage 4, not part of eslint-plugin-react (since you'd want to enforce it for every kind of class).

5. this is unnecessary; if it's not used, eslint's "no-unused-imports" or "no-unused-vars" will catch it.

6. This seems like a great rule for us! Can you file a separate issue just for this one rule, so it can be tagged appropriately?

7. I don't think this rule should ever be on by default anywhere, but it seems like a legit rule to create. Can you file a separate issue just for this one rule, so it can be tagged appropriately?

8. This is untenable, since you can't statically know if a given variable has a primitive or not within it. Effectively, this would prohibit anything but a literal primitive value in props, which wouldn't be useful.

[jomasti]

There is currently an open issue for 6 (#985)

[otakustay]

Thanks, I didn't aware of eslint-plugin-import before

Since #985 already covers 6, I'll later file a separate issue for 7, closing this now