Revert [eprh] Remove hermes-parser #34747
Merged
+24
−8
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
Adds back HermesParser to eslint-plugin-react-hooks. There are still [external users of Flow](#34719 (comment)) using the plugin, so we shouldn't break the plugin for them. However, we still have the problem of double parsing: once from eslint (which we discard) and then another via babel/hermes parser. In the long run we should investigate a translation layer from estree to babel (or alternatively, update the compiler to take estree as input). For now I am reverting that PR. This does mean that [Sandpack in react.dev](https://github.com/reactjs/react.dev/blob/11cb6b591571caf5fa2a192117b6a6445c3f2027/src/components/MDX/Sandpack/runESLint.tsx#L31) cannot update to the latest eprh as HermesParser does not appear to be able to be run in a browser. I discovered this while trying to update eprh on react.dev last week, but didn't investigate deeply. I'll need to double check that again to find out more.
github-actions
bot
added
the
React Core Team
|
Comparing: c786258...8de3085 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
josephsavona
approved these changes
Oct 6, 2025
Member
josephsavona
left a comment
josephsavona
left a comment
There was a problem hiding this comment.
Thanks for reverting, our Flow users are pretty quiet but it's great to see folks using React with Flow (and hopefully taking advantage of component/hook syntax and render types).
Contributor
|
Thanks for considering your outside Flow users! There are dozens of us! 😅
We started using React+Flow in musicbrainz-server in 2015, when TypeScript wasn't a monopoly yet. It felt logical since React itself used Flow (and the focus on soundness was appealing). Today we have 100K+ lines of Flow, and no real desire to port those to TS. Flow still works great for us, outside of lacking up-to-date libdefs. We are taking huge advantage of the new |
github-actions bot
pushed a commit
that referenced
this pull request
Oct 6, 2025
Adds back HermesParser to eslint-plugin-react-hooks. There are still [external users of Flow](#34719 (comment)) using the plugin, so we shouldn't break the plugin for them. However, we still have the problem of double parsing: once from eslint (which we discard) and then another via babel/hermes parser. In the long run we should investigate a translation layer from estree to babel (or alternatively, update the compiler to take estree as input). But for now, I am reverting the PR. This does mean that [Sandpack in react.dev](https://github.com/reactjs/react.dev/blob/11cb6b591571caf5fa2a192117b6a6445c3f2027/src/components/MDX/Sandpack/runESLint.tsx#L31) cannot update to the latest eprh as HermesParser does not appear to be able to be run in a browser. I discovered this while trying to update eprh on react.dev last week, but didn't investigate deeply. I'll need to double check that again to find out more. DiffTrain build for [b65e6fc](b65e6fc)
github-actions bot
pushed a commit
that referenced
this pull request
Oct 6, 2025
Adds back HermesParser to eslint-plugin-react-hooks. There are still [external users of Flow](#34719 (comment)) using the plugin, so we shouldn't break the plugin for them. However, we still have the problem of double parsing: once from eslint (which we discard) and then another via babel/hermes parser. In the long run we should investigate a translation layer from estree to babel (or alternatively, update the compiler to take estree as input). But for now, I am reverting the PR. This does mean that [Sandpack in react.dev](https://github.com/reactjs/react.dev/blob/11cb6b591571caf5fa2a192117b6a6445c3f2027/src/components/MDX/Sandpack/runESLint.tsx#L31) cannot update to the latest eprh as HermesParser does not appear to be able to be run in a browser. I discovered this while trying to update eprh on react.dev last week, but didn't investigate deeply. I'll need to double check that again to find out more. DiffTrain build for [b65e6fc](b65e6fc)
|
I have uploaded a PR to fix the issue where the flow link in the PR template is incorrectly linked, preventing access to the official flow website. Could you please check it? |
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.
Adds back HermesParser to eslint-plugin-react-hooks. There are still external users of Flow using the plugin, so we shouldn't break the plugin for them. However, we still have the problem of double parsing: once from eslint (which we discard) and then another via babel/hermes parser.
In the long run we should investigate a translation layer from estree to babel (or alternatively, update the compiler to take estree as input). But for now, I am reverting the PR.
This does mean that Sandpack in react.dev cannot update to the latest eprh as HermesParser does not appear to be able to be run in a browser. I discovered this while trying to update eprh on react.dev last week, but didn't investigate deeply. I'll need to double check that again to find out more.