-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Add React Compiler #4161
Add React Compiler #4161
Conversation
React Compiler uses a small cache function from React 19 at runtime. Until it's possible to use R19 on RN, this adds a userspace implementation to polyfill the cache function
@lingui recommends running their `macro` plugin [first in the pipeline](https://lingui.dev/ref/macro). Normally with the React Compiler, the compiler plugin should run first as we want to see the original code as it was written. However, this sometimes causes conflicts with other babel plugins. In this case, it looks like the @lingui/macro plugin does some very light transformation that the compiler can still understand and compile correctly, so let's run it first. Before this commit, the compiler would cause the @lingui/macro plugin to crash because it seems like it would strip off the `extra.raw` property off of StringLiterals which was being used [here](https://github.com/lingui/js-lingui/blob/1293412c5dcc565636403443788a5b5d4ca206c1/packages/macro/src/macroJsx.ts#L395). I need to figure out why the compiler is doing that but for now this works and should be a safe change unless there were specific reasons the macro plugin was placed 2nd to last.
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.
lfg
I am curious if this work in production now, and how you upgraded the Babel plugin? I tried this, and my Expo app completely broke... |
yeah, i don't think we've had a single issue related to it |
@gaearon it might also be worth upgrading the compiler and letting us know if there are any issues! We've fixed a ton of bugs since then |
yeah! will need to try that. what's a good hash that has been baked for a bit? |
@gaearon https://www.npmjs.com/package/babel-plugin-react-compiler/v/0.0.0-experimental-8d2bec7-20240812 has been in use internally since 8/9 and we haven't seen any issues yet |
In my ReactConf talk I demo'd adding React Compiler to bluesky, so I wanted to add it for real!
Adding the compiler and eslint plugin was pretty straightforward. The only hiccup I ran into was an interesting interaction with @lingui/macro:
lingui recommends running their
macro
plugin first in the pipeline. Normally with the React Compiler, the compiler plugin should run first as we want to see the original code as it was written. However, this sometimes causes conflicts with other babel plugins.In this case, it looks like the @lingui/macro plugin does some very light transformation that the compiler can still understand and compile correctly, so I made it run first.
Without letting @lingui/macro run first, the compiler would cause the @lingui/macro plugin to crash because it seems like it would strip off the
extra.raw
property off of StringLiterals which was being used here. I need to figure out why the compiler is doing that, but for now this works and should be a safe change unless there were specific reasonsthe macro plugin was placed 2nd to last.