eslint-plugin-react: Imported propTypes triggers false positives
Hello,
Context
| Package | Version |
|---|---|
| eslint | ~6.0.1 |
| eslint-plugin-react | ~7.14.2 |
The situation
After updating ESLint, I’m encountering false positives when importing propTypes (that are used in multiple places, for instance).
Let’s take a simple example:
// sharedPropTypes.js
import PropTypes from "prop-types";
export default {
steps : PropTypes.array,
};
// MyComponent.jsx
import React from "react";
import sharedPropTypes from "./sharedPropTypes";
const propTypes = {
...sharedPropTypes,
};
function MyComponent(props) {
// Using steps.map somewhere
}
This scenario is triggering the following lint errors:
error 'steps.map' is missing in props validation react/prop-types
Which is new.
Please note that declaring propTypes in the component file is working fine:
// MyComponent.jsx
import React from "react";
import PropTypes from "prop-types";
import sharedPropTypes from "./sharedPropTypes";
const propTypes = {
steps : PropTypes.array
};
function MyComponent(props) {
// Using steps.map somewhere
}
A lead
After some searches, it seems that ESLint is more sensitive since https://github.com/yannickcr/eslint-plugin-react/pull/2301 .
- Could it be the source?
- How should I manage this situation in a clean way?
Related issues
https://github.com/yannickcr/eslint-plugin-react/issues/2352 https://github.com/yannickcr/eslint-plugin-react/issues/2343
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 3
- Comments: 17 (5 by maintainers)
Here’s an example:
This ESLint rule should complain that data.text is missing in props validation. The reason seems to be because ESLint thinks that renderLabel const is a different component of its own and needs to have props of its own. The error goes away if you pass the props in to the parameters of renderLabel.
@ljharb I think we can close this one. As you said in https://github.com/yannickcr/eslint-plugin-react/issues/2357#issuecomment-514675480 importing propTypes won’t work with static analysis and using a variable, defined in the same file, was fixed by #2704
I was having the same issue on version
7.16.0a work around for me was to downgrade to7.13.0hopefully this will be fixedIn that case it really does seem like we’re doing something different for classes and SFCs, so that’s a bug.