sort-comp
sort-comp rule
sort-comp rule
Enforce component method ordering in React class components. This rule is part of eslint-plugin-react-features.
Quick Summary
| Aspect | Details |
|---|---|
| Severity | Warning (organization) |
| Auto-Fix | ❌ No (requires reordering) |
| Category | React |
| ESLint MCP | ✅ Optimized for ESLint MCP integration |
| Best For | React class components with consistent style |
Rule Details
Enforces a consistent ordering of methods within React class components, making code more predictable and easier to navigate.
Why This Matters
| Issue | Impact | Solution |
|---|---|---|
| 🔄 Inconsistent structure | Hard to find methods | Standardized ordering |
| 🐛 Review difficulty | Different patterns across team | Consistent conventions |
| 🔍 Onboarding | New devs struggle to navigate | Predictable structure |
Default Order
static-variables- Static class propertiesstatic-methods- Static methodsinstance-variables- Instance propertieslifecycle- React lifecycle methodseverything-else- Custom methodsrender- The render method (always last)
The lifecycle group holds the constructor and React's lifecycle methods
(componentDidMount, shouldComponentUpdate, componentDidUpdate,
componentWillUnmount, …); their order among themselves is not checked.
Member names are read in every spelling (['render']()). The class must
extend React's Component or PureComponent, by binding, declared or as a
class expression.
Examples
❌ Incorrect
class UserProfile extends React.Component {
// BAD: render before lifecycle
render() {
return <div>{this.state.name}</div>;
}
// BAD: lifecycle after render
componentDidMount() {
this.fetchUser();
}
// BAD: constructor not first
constructor(props) {
super(props);
this.state = { name: '' };
}
// BAD: static after instance methods
static propTypes = {
userId: PropTypes.string.isRequired
};
}✅ Correct
class UserProfile extends React.Component {
static propTypes = {
userId: PropTypes.string.isRequired,
};
state = { name: '' };
constructor(props) {
super(props);
}
componentDidMount() {
this.fetchUser();
}
fetchUser() {}
render() {
return <div>{this.state.name}</div>;
}
}Options
| Option | Type | Default | Description |
|---|---|---|---|
order | string[] | See default order | Array of group names in order |
Configuration with Options
{
rules: {
'react-features/sort-comp': ['warn', {
order: [
'static-variables',
'static-methods',
'lifecycle',
'instance-variables',
'everything-else',
'render'
]
}]
}
}Configuration Examples
Basic Usage
{
rules: {
'react-features/sort-comp': 'warn'
}
}Related Rules
prefer-stateless-function- Functional componentsstate-in-constructor- State initialization
Further Reading
- Component Lifecycle - React docs
- Class Components - Structure
Known False Negatives
- Lifecycle methods are not ordered among themselves; only the groups are.
getDerivedStateFromPropsis a static method, so it sorts withstatic-methods.
Use this rule
npm install -D oxlint-plugin-react-features{ "jsPlugins": ["oxlint-plugin-react-features"], "rules": { "react-features/sort-comp": "error" }}import { defineConfig } from 'vite-plus';export default defineConfig({ lint: { jsPlugins: ['oxlint-plugin-react-features'], rules: { 'react-features/sort-comp': '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.