[compiler][rfc] Enable more validations in playground. by josephsavona · Pull Request #33777 · facebook/react

josephsavona · 2025-07-12T17:04:14Z

This is mostly to kick off conversation, i think we should go with a modified version of the implemented approach that i'll describe here.

The playground currently serves two roles. The primary one we think about is for verifying compiler output. We use it for this sometimes, and developers frequently use it for this, including to send us repros if they have a potential bug. The second mode is to help developers learn about React. Part of that includes learning how to use React correctly — where it's helpful to see feedback about problematic code — and also to understand what kind of tools we provide compared to other frameworks, to make an informed choice about what tools they want to use.

Currently we primarily think about the first role, but I think we should emphasize the second more. In this PR i'm doing the worst of both: enabling all the validations used by both the compiler and the linter by default. This means that code that would actually compile can fail with validations, which isn't great.

What I think we should actually do is compile twice, one in "compilation" mode and once in "linter" mode, and combine the results as follows:

If "compilation" mode succeeds, show the compiled output and any linter errors.
If "compilation" mode fails, show only the compilation mode failures.

We should also distinguish which case it is when we show errors: "Compilation succeeded", "Compilation succeeded with linter errors", "Compilation failed".

This lets developers continue to verify compiler output, while also turning the playground into a much more useful tool for learning React. Thoughts?

Stack created with Sapling. Best reviewed with ReviewStack.

josephsavona · 2025-07-12T17:24:18Z

I updated to implement a basic version of the better approach I laid out above. This is still a bit awkward bc you see output and an error. We need some text to clarify "compiled but with lint warnings".

josephsavona · 2025-07-14T21:06:02Z

mofeiZ · 2025-07-24T20:23:23Z

Sounds like a great idea! I wonder if we should have a Linter Errors tab (that's potentially highlighted in red) in addition to the JS output tab then?

mofeiZ · 2025-07-24T20:34:17Z

compiler/apps/playground/components/Editor/Output.tsx

+      output = `
+# Output
+
+React Compiler compiled this function sucessfully, but there are lint errors that indicate potential issues with the original code.


small nit: sucessfully -> successfully

mofeiZ · 2025-07-24T20:35:43Z

compiler/apps/playground/components/Editor/Output.tsx

+      'Output',
      <TextTabContent
        output={errors}
+        language="plaintext"


nit: should the language be markdown?

mofeiZ

Nice, shipit!

--- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33753). * #33981 * #33777 * #33767 * #33765 * #33760 * #33759 * #33758 * #33751 * #33752 * __->__ #33753

Enable more validations to help catch bad patterns, but only in the linter. These rules are already enabled by default in the compiler _if_ violations could produce unsafe output. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33752). * #33981 * #33777 * #33767 * #33765 * #33760 * #33759 * #33758 * #33751 * __->__ #33752 * #33753

Work in progress, i'm experimenting with revamping our diagnostic infra. Starting with a better format for representing errors, with an ability to point ot multiple locations, along with better printing of errors. Of course, Babel still controls the printing in the majority case so this still needs more work. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33751). * #33981 * #33777 * #33767 * #33765 * #33760 * #33759 * #33758 * __->__ #33751 * #33752 * #33753

This PR uses the new diagnostic type for most of the error messages produced in our explicit validation passes (`Validation/` directory). One of the validations produced multiple errors as a hack to showing multiple related locations, which we can now consolidate into a single diagnostic. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33758). * #33981 * #33777 * #33767 * #33765 * #33760 * #33759 * __->__ #33758

…33759) Uses the new diagnostic infrastructure for this validation, which lets us provide a more targeted message on the text that we highlight (eg "This dependency may be mutated later") separately from the overall error message. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33759). * #33981 * #33777 * #33767 * #33765 * #33760 * __->__ #33759 * #33758

Uses the new diagnostic type for errors created during mutation/aliasing inference, such as errors for mutating immutable values like props or state, reassigning globals, etc. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33760). * #33981 * #33777 * #33767 * #33765 * __->__ #33760

Minor sytlistic cleanup --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33765). * #33981 * #33777 * #33767 * __->__ #33765

Per title --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33767). * #33981 * #33777 * __->__ #33767

This is mostly to kick off conversation, i think we should go with a modified version of the implemented approach that i'll describe here. The playground currently serves two roles. The primary one we think about is for verifying compiler output. We use it for this sometimes, and developers frequently use it for this, including to send us repros if they have a potential bug. The second mode is to help developers learn about React. Part of that includes learning how to use React correctly — where it's helpful to see feedback about problematic code — and also to understand what kind of tools we provide compared to other frameworks, to make an informed choice about what tools they want to use. Currently we primarily think about the first role, but I think we should emphasize the second more. In this PR i'm doing the worst of both: enabling all the validations used by both the compiler and the linter by default. This means that code that would actually compile can fail with validations, which isn't great. What I think we should actually do is compile twice, one in "compilation" mode and once in "linter" mode, and combine the results as follows: * If "compilation" mode succeeds, show the compiled output _and_ any linter errors. * If "compilation" mode fails, show only the compilation mode failures. We should also distinguish which case it is when we show errors: "Compilation succeeded", "Compilation succeeded with linter errors", "Compilation failed". This lets developers continue to verify compiler output, while also turning the playground into a much more useful tool for learning React. Thoughts?

Enable more validations to help catch bad patterns, but only in the linter. These rules are already enabled by default in the compiler _if_ violations could produce unsafe output. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/33752). * #33981 * #33777 * #33767 * #33765 * #33760 * #33759 * #33758 * #33751 * __->__ #33752 * #33753 DiffTrain build for [0d39496](0d39496)

facebook-github-bot added the CLA Signed label Jul 12, 2025

github-actions bot added the React Core Team Opened by a member of the React Core Team label Jul 12, 2025

josephsavona force-pushed the pr33777 branch from fa45d41 to a5d82bd Compare July 12, 2025 17:20

josephsavona force-pushed the pr33777 branch 4 times, most recently from 1373c05 to cc4abf0 Compare July 14, 2025 20:58

josephsavona requested a review from mofeiZ July 15, 2025 00:14

josephsavona mentioned this pull request Jul 24, 2025

[compiler] Use diagnostic for "found suppression" error #33981

Merged

mofeiZ reviewed Jul 24, 2025

View reviewed changes

mofeiZ approved these changes Jul 24, 2025

View reviewed changes

josephsavona force-pushed the pr33777 branch from cc4abf0 to dc78fb6 Compare July 24, 2025 21:50

josephsavona force-pushed the pr33777 branch from dc78fb6 to a3e4b67 Compare July 24, 2025 22:38

josephsavona force-pushed the pr33777 branch from a3e4b67 to d5e2c0e Compare July 24, 2025 22:41

josephsavona force-pushed the pr33777 branch from d5e2c0e to f2c4546 Compare July 24, 2025 22:44

josephsavona force-pushed the pr33777 branch from f2c4546 to 0553cd5 Compare July 24, 2025 22:47

josephsavona force-pushed the pr33777 branch from 0553cd5 to 3fbedc5 Compare July 24, 2025 22:49

josephsavona merged commit bcea869 into main Jul 24, 2025
8 of 9 checks passed

nextjs-bot mentioned this pull request Jul 25, 2025

Upgrade React from 3d14fcf0-20250724 to 19baee81-20250725 vercel/next.js#82063

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[compiler][rfc] Enable more validations in playground.#33777

[compiler][rfc] Enable more validations in playground.#33777
josephsavona merged 1 commit intomainfrom
pr33777

josephsavona commented Jul 12, 2025 •

edited

Loading

Uh oh!

josephsavona commented Jul 12, 2025

Uh oh!

josephsavona commented Jul 14, 2025 •

edited

Loading

Uh oh!

mofeiZ commented Jul 24, 2025

Uh oh!

mofeiZ Jul 24, 2025

Uh oh!

mofeiZ Jul 24, 2025

Uh oh!

mofeiZ left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

josephsavona commented Jul 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

josephsavona commented Jul 12, 2025

Uh oh!

josephsavona commented Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mofeiZ commented Jul 24, 2025

Uh oh!

mofeiZ Jul 24, 2025

Choose a reason for hiding this comment

Uh oh!

mofeiZ Jul 24, 2025

Choose a reason for hiding this comment

Uh oh!

mofeiZ left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

josephsavona commented Jul 12, 2025 •

edited

Loading

josephsavona commented Jul 14, 2025 •

edited

Loading