Enforce or encourage PascalCase for export default component functions in App Router pages

[code-front-braga]

Goals

1. Encourage consistent React best practices (PascalCase for component functions) across Next.js projects.

2. Prevent accidental export of camelCase or lowercase component functions in special route files (e.g., page.tsx, layout.tsx).

3. Provide clear feedback via build warnings or ESLint rules when a route export violates component naming conventions.

Non-Goals

1. Changing how JavaScript default exports work natively.

2. Breaking existing projects that currently use camelCase without an opt-out or a phased deprecation/warning approach.

3. Restricting the casing of file/folder names themselves in the file system (this is strictly about the React component function inside the file).

Background

Currently, Next.js allows route files to export default functions using camelCase (e.g., export default function myPage()) without any warnings or errors.

While Next.js correctly wraps and renders these components internally, using camelCase for React components deviates from standard React conventions. In JSX, components must start with an uppercase letter to distinguish them from standard HTML elements. Allowing camelCase in page components can cause confusion, lead to inconsistent codebases, and set bad habits for developers learning React through Next.js.

Proposal

ESLint Rule: Add a dedicated rule to @next/eslint-plugin-next that checks export default functions inside App Router convention files (page.tsx, layout.tsx, template.tsx, etc.) and warns if they are not in PascalCase.

Build-time Check / Warning: Introduce a non-breaking dev-time warning when Next.js detects a route component exported in camelCase, suggesting PascalCase instead.