This is pretty major - makes it impossible to test such functions without moving them out of their context

Would love to see an option to disable or configure this TypeScript plugin feature. My use case: In order to make it easier to render the interface portion of async server components in tests and Storybook, I would like to follow a pattern like below, but this is prevented by this named export issue:

export default async function Controller() {
  const claim = await getExampleData()
  return <View claim={claim} />
}

export function View(props) {
  return <div>{props.claim.id}</div>
}

Type error: Page "src/app/example/page.tsx" does not match the required types of a Next.js Page.
  "View" is not a valid Page export field.

Example test that this pattern would support:

import { View } from "src/app/example/page"

it("passes accessibility scan", () => {
    const { container } = render(<View claim={{ id: "123" }} />)
    const a11y = await axe(container)
    expect(a11y).toHaveNoViolations()
})

Example Storybook story:

import { View } from "src/app/example/page"

const story = {
  component: View,
 args: {
   claim: { id: "123" }
 }
}

Related #56832, #50870

Hello. Also experiencing this. Is there any update? Thanks

Also affected... could you guys have made a more inscrutable error... seriously...

I'm so close to losing my sh*t with Nextjs

export default function Page() {
  // ...
}

Splitting the non default export from the page file, it works normally.

As for why, it doesn’t seem to be mentioned in the docs.

https://nextjs.org/docs/app/building-your-application/routing/pages

Based on the issues you're encountering with Next.js during your build process, it seems you're running into a common problem with Next.js's stricter validation of page exports in version 14. This validation aims to ensure that page files only export React components that are intended to be used as pages, not utility functions or other named exports. You need to tackle this with a precise refactor to align with best practices and address the compilation errors effectively

Understanding the Issue
Next.js expects that files under the pages directory (or any file treated as a page component) should only default export a React component that corresponds to a page. If you have other named exports, it can cause the build to fail as Next.js might interpret them as potential page candidates which they are not.

Solution: Restructure Exports and Component Organization
To resolve this issue, we need to separate utility functions or non-page components from the page files, ensuring that only the default page export is present in page component files. Here’s how you can adjust your setup:

Separate Utility Functions and Shared Components:
Move any named exports that are not page components into separate files within a suitable directory, such as components or utils.
Adjust Imports in the Main Page File:
Update import statements in your main page files to reflect these changes.

see also: #56825

align with best practices

If this is really the reason, and not a technical requirement, I would strongly encourage that this requirement is removed.

It is not 'best practices' that is literally just an opinion. An equally valid opinion is to prefer locality of behavior, which this rule impairs. React itself pushed back against 'best practices' when it was built, and now think of components as concerns, not technologies. Locality of behavior underlies this concept.

You may disagree, but it's all opinions.

If this export restriction is not a technical requirement, I would prefer to see this error removed.

I'm observing this in an unexpected setting: the project has src/app/page.tsx export a default React component and a utility function. Project builds normally. As soon as I add 'use client' to one of the components imported by the page I'm seeing this error.
14.2.4

I was also experiencing this kind of error showing

Type error: Page "app/page.tsx" does not match the required types of a Next.js Page.
  "CommentsPage" is not a valid Page export field.

Then I found out it was due to exporting another function inside page.tsx like that

'use client'
export function CommentsPage() => {
}

export default function Page() => {
     <CommentsPage/>
}

So, I tried to move that CommentsPage into another file like you did and build then everything fine.
And I also found another way of doing it in page.tsx like that by removing export keyword from it.

'use client'
function CommentsPage() => {
}

export default function Page() => {
     <CommentsPage/>
}