-
Notifications
You must be signed in to change notification settings - Fork 7.8k
Add local eslint rule to validate markdown codeblocks with React Compiler #7988
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Size changes📦 Next.js Bundle Analysis for react-devThis analysis was generated by the Next.js Bundle Analysis action. 🤖 This PR introduced no changes to the JavaScript bundle! 🙌 |
Such a great idea, love this! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoa, I hadn't realized how much went into this. Thank you! I scanned through, everything seems pretty reasonable. Let's ship and iterate
@josephsavona it was a classic case of ![]() |
this is the way |
…iler In facebook/react#34462 for example, we found an issue where the compiler was incorrectly validating an example straight from the docs. In order to find more issues like this + also provide more feedback to doc authors on valid/invalid patterns, this PR adds a new local eslint rule which validates all markdown codeblocks containing components/hooks with React Compiler. An autofixer is also provided. To express that a codeblock has an expected error, we can use the following metadata: ```ts // pseudo type def type MarkdownCodeBlockMetadata = { expectedErrors?: { 'react-compiler'?: number[]; }; }; ``` and can be used like so: ```` ```js {expectedErrors: {'react-compiler': [4]}} // ❌ setState directly in render function Component({value}) { const [count, setCount] = useState(0); setCount(value); // error on L4 return <div>{count}</div>; } ``` ```` Because this is defined as a local rule, we don't have the same granular reporting that `eslint-plugin-react-hooks` yet. I can look into that later but for now this first PR just sets us up with something basic.
In facebook/react#34462 for example, we found an issue where the compiler was incorrectly validating an example straight from the docs.
In order to find more issues like this + also provide more feedback to doc authors on valid/invalid patterns, this PR adds a new local eslint rule which validates all markdown codeblocks containing components/hooks with React Compiler. An autofixer is also provided.
To express that a codeblock has an expected error, we can use the following metadata:
and can be used like so:
Because this is defined as a local rule, we don't have the same granular reporting that
eslint-plugin-react-hooks
yet. I can look into that later but for now this first PR just sets us up with something basic.Stack created with Sapling. Best reviewed with ReviewStack.