[compiler][rfc] Enable more validations in playground. #33777
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Jul 12, 2025
github-actions
bot
added
the
React Core Team
|
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
force-pushed
the
pr33777
branch
4 times, most recently
from
1373c05 to
cc4abf0
Compare
|
|
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
reviewed
Jul 24, 2025
| output = ` | ||
| # Output | ||
|
|
||
| React Compiler compiled this function sucessfully, but there are lint errors that indicate potential issues with the original code. |
There was a problem hiding this comment.
small nit: sucessfully -> successfully
mofeiZ
reviewed
Jul 24, 2025
| <TextTabContent | ||
| output={errors} | ||
| language="plaintext" |
There was a problem hiding this comment.
nit: should the language be markdown?
josephsavona
added a commit
that referenced
this pull request
Jul 24, 2025
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
josephsavona
added a commit
that referenced
this pull request
Jul 24, 2025
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
josephsavona
added a commit
that referenced
this pull request
Jul 24, 2025
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
josephsavona
added a commit
that referenced
this pull request
Jul 24, 2025
…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
josephsavona
added a commit
that referenced
this pull request
Jul 24, 2025
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
josephsavona
added a commit
that referenced
this pull request
Jul 24, 2025
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
josephsavona
added a commit
that referenced
this pull request
Jul 24, 2025
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?
github-actions bot
pushed a commit
that referenced
this pull request
Jul 24, 2025
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)
github-actions bot
pushed a commit
that referenced
this pull request
Jul 24, 2025
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)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
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.