[Bug]: react/prefer-read-only-props doesn't work with async components

[pnodet]

Is there an existing issue for this?

• I have searched the existing issues and my issue is unique
• My issue appears in the command-line and not only in the text editor

Description Overview

The code below does not trigger the rule. But if I remove the async keyword and the getData() the rule now errors correctly. I'm using nextjs app dir with server components.

type Props = {
  isInverted: boolean
}

const MyAsyncComponent = async ({ isInverted }: Props) => {
  const data = await getData();

  return (
    // some jsx
  )
}

Expected Behavior

Shouldn't the rule errors whether the component is async or not? Maybe I misunderstood something in the docs.

eslint-plugin-react version

v7.33.2

eslint version

v8.53.0

node version

v18.x

[ljharb]

What are async components?

[pnodet]

In this RFC (dec. 2020) React introduced server components. Although they are still experimental and not available in stable react app, they are the new default in Nextjs.

This components returns a Promise and they let you fetch data in asynchronous components that run on the server or even during the build. Instead of relying on useEffect to fetch the data.

You can find some documentation with better explanations here: https://react.dev/learn/start-a-new-react-project#bleeding-edge-react-frameworks

Typescript handles them now I think since this PR (nov. 2022) (microsoft/TypeScript#51328)

[ljharb]

Since they're still experimental, we don't support them yet, and it sounds like a pretty bad decision for nextjs to default to using them.

Once they're stable, I'd be happy to review a PR that adds support for them.

[pnodet]

I just want to clarify the "experimental" wording, after doing some research here is what I found from this article from May, from the react team:

As we announced in March, the React Server Components conventions have been finalized, and we do not expect significant breaking changes related to their user-facing API contract. However, we can’t release support for React Server Components in a stable version of React yet because we are still working on several intertwined framework-only features (such as asset loading) and expect more breaking changes there.

This means that React Server Components are ready to be adopted by frameworks. However, until the next major React release, the only way for a framework to adopt them is to ship a pinned Canary version of React.

We’re introducing an officially supported Canary release channel for React. Since it’s officially supported, if any regressions land, we’ll treat them with a similar urgency to bugs in stable releases.
Canaries let you start using individual new React features before they land in the semver-stable releases.
Unlike the Experimental channel, React Canaries only include features that we reasonably believe to be ready for adoption. We encourage frameworks to consider bundling pinned Canary React releases.

[ljharb]

I think that's harmful encouragement, and frameworks that follow it are similarly not doing their users a service.

If you think you can make a PR that would cover this, though, I'll review it.

[pnodet]

Made a quick PR feel free to suggest any changes, tests are running correctly.

[pnodet]

Just want to point out, I have a lot of respect for you and I understand your point of view but… I didn't made those decisions…

However, as many others, I use nextjs daily in my 9 to 5 and wanted to help what I think is a bug in the rules.