Plugin: react-featuresRules
prop-types
prop-types rule
prop-types rule
Enforce prop types validation for React components. This rule is part of eslint-plugin-react-features.
Quick Summary
| Aspect | Details |
|---|---|
| Severity | Warning (type safety) |
| Auto-Fix | ❌ No (requires prop type definitions) |
| Category | React |
| ESLint MCP | ✅ Optimized for ESLint MCP integration |
| Best For | JavaScript React projects (TypeScript preferred) |
Rule Details
A class component (extending React's Component or PureComponent, by
binding, declared or as a class expression) must declare its props. Any of
these declares them: a static propTypes (any key spelling), a
Card.propTypes = … assignment, or TypeScript props on the base class
(React.Component<Props>).
Why This Matters
| Issue | Impact | Solution |
|---|---|---|
| 🔄 No type safety | Runtime errors from wrong props | Define PropTypes |
| 🐛 Poor documentation | Unclear component API | PropTypes document interface |
| 🔍 Debug difficulty | Silent failures with wrong types | Runtime warnings in dev |
Examples
❌ Incorrect
// BAD: No PropTypes defined
class UserCard extends React.Component {
render() {
return (
<div>
<h1>{this.props.name}</h1>
<p>{this.props.email}</p>
</div>
);
}
}✅ Correct
import PropTypes from 'prop-types';
// GOOD: PropTypes defined
class UserCard extends React.Component {
static propTypes = {
name: PropTypes.string.isRequired,
email: PropTypes.string.isRequired,
age: PropTypes.number,
role: PropTypes.oneOf(['admin', 'user', 'guest']),
onUpdate: PropTypes.func,
};
static defaultProps = {
age: 0,
role: 'user',
};
render() {
const { name, email, age, role } = this.props;
return (
<div>
<h1>{name}</h1>
<p>{email}</p>
</div>
);
}
}
// BETTER: Use TypeScript instead
interface UserCardProps {
name: string;
email: string;
age?: number;
role?: 'admin' | 'user' | 'guest';
onUpdate?: () => void;
}
function UserCard({ name, email, age = 0, role = 'user' }: UserCardProps) {
return (
<div>
<h1>{name}</h1>
<p>{email}</p>
</div>
);
}Options
| Option | Type | Default | Description |
|---|---|---|---|
ignore | string[] | [] | Component names to ignore |
customValidators | string[] | [] | Accepted for compatibility; it has no effect |
skipUndeclared | boolean | false | Skip if no props are accessed |
Configuration with Options
{
rules: {
'react-features/prop-types': ['warn', {
ignore: ['Link', 'Router'], // Third-party components
skipUndeclared: true // Skip components not using props
}]
}
}Configuration Examples
Basic Usage
{
rules: {
'react-features/prop-types': 'warn'
}
}Strict Usage
{
rules: {
'react-features/prop-types': 'error'
}
}Related Rules
default-props-match-prop-types- Type consistencyrequire-default-props- Default values
Further Reading
- PropTypes - React docs
- TypeScript with React - Modern alternative
Known False Negatives
- Function components are not checked; the rule reads class components only.
- A component that never reads
this.propsis still reported under the defaultskipUndeclared: false.
Use this rule
npm install -D oxlint-plugin-react-features{ "jsPlugins": ["oxlint-plugin-react-features"], "rules": { "react-features/prop-types": "error" }}import { defineConfig } from 'vite-plus';export default defineConfig({ lint: { jsPlugins: ['oxlint-plugin-react-features'], rules: { 'react-features/prop-types': 'error', }, },});oxlint-plugin-react-features re-exports eslint-plugin-react-features/oxlint: the same rules under the same IDs, and no ESLint install. Why oxlint.
Did this rule catch something? Star the repo to get new CWE coverage as we ship it — or follow the AI-code-security benchmarks behind these rules.