ElementConfig should be used to determine props required

[callumlocke]

ESLint currently uses ElementProps to determine what types are required by a component with Flow-annotated props, but it should be using ElementConfig instead.

See Using Default Props for Functional Components in Flow's docs for an explanation of why. See also their comparison of ElementProps and ElementConfig.

@ljharb suggested I open an issue here to get it changed.

[nickluger]

Thank you @callumlocke for staying with it in the other issue. The current workaraound for these often used rules would be then:

 "react/default-props-match-prop-types": [
      "error",
      { "allowRequiredDefaults": true }
    ],
 "react/require-default-props": [
      "error",
      { "forbidDefaultForRequired": false }
    ]

[okovpashko]

Totally agree.

Stumbled upon this issue when switched to eslint-config-airbnb and got a lot of Eslint errors in code that's written according to the Flow docs.

Flow allows using this component without passing name prop, but Eslit shows an error, that there shouldn't be default prop defined for the required prop.
But if we make the name prop optional, we'll get Flow error that we can't call method toUpperCase of undefined.

Looks like an incompatibility between Eslint and Flow.

type Props = {
	// propType "name" is required and should not have a defaultProp declaration react/require-default-props
	name: string,
};

class Greeting extends React.Component<Props> {
	static defaultProps = {
		name: 'User',
	};

	render () {
		// here will be Flow error if the "name" prop is optional
		// Cannot call `name.toUpperCase` because property `toUpperCase` is missing in  undefined [1].
		return <span>Hello, {this.props.name.toUpperCase()}</span>
	}
}

[jdeff]

I am running into the same issue when using TypeScript, FWIW.