no-multi-comp

Keywords: React, components, file organization, single responsibility, code structure, ESLint rule, LLM-optimized

Prevent multiple component definitions per file. This rule is part of eslint-plugin-react-features.

Quick Summary

Rule Details

Each React component should be in its own file for better maintainability, testing, and code organization. This follows the single responsibility principle.

Why This Matters

Examples

❌ Incorrect

// UserComponents.tsx - BAD: Multiple components in one file
function UserAvatar({ src, alt }) {
  return <img src={src} alt={alt} className="avatar" />;
}

function UserName({ name }) {
  return <span className="username">{name}</span>;
}

function UserCard({ user }) {
  return (
    <div className="user-card">
      <UserAvatar src={user.avatar} alt={user.name} />
      <UserName name={user.name} />
    </div>
  );
}

export default UserCard;

✅ Correct

hello

Options

Configuration with Options

{
  rules: {
    'react-features/no-multi-comp': ['warn', {
      ignoreStateless: true  // Allow small helper components
    }]
  }
}

Configuration Examples

Basic Usage

{
  rules: {
    'react-features/no-multi-comp': 'warn'
  }
}

Strict Usage

{
  rules: {
    'react-features/no-multi-comp': 'error'
  }
}

Related Rules

• no-anonymous-default-export - Named exports
• filename-case - File naming conventions

Further Reading

• Thinking in React - Component organization
• Single Responsibility - Design principle

Known False Negatives

The following patterns are not detected due to static analysis limitations:

Dynamic Variable References

Why: Static analysis cannot trace values stored in variables or passed through function parameters.

// ❌ NOT DETECTED - Prop from variable
const propValue = computedValue;
<Component prop={propValue} /> // Computation not analyzed

Mitigation: Implement runtime validation and review code manually. Consider using TypeScript branded types for validated inputs.

Wrapped or Aliased Functions

Why: Custom wrapper functions or aliased methods are not recognized by the rule.

// ❌ NOT DETECTED - Custom wrapper
function myWrapper(data) {
  return internalApi(data); // Wrapper not analyzed
}
myWrapper(unsafeInput);

Mitigation: Apply this rule's principles to wrapper function implementations. Avoid aliasing security-sensitive functions.

Imported Values

Why: When values come from imports, the rule cannot analyze their origin or construction.

// ❌ NOT DETECTED - Value from import
import { getValue } from './helpers';
processValue(getValue()); // Cross-file not tracked

Mitigation: Ensure imported values follow the same constraints. Use TypeScript for type safety.