feat: merge plugin-react-oxc into plugin-react

[sapphi-red]

Description

Built on top of #306

The initial plan was to make @vitejs/plugin-react-oxc the default plugin when rolldown-vite lands. But I changed my mind and thought that merging plugin-react-oxc into plugin-react is better.

The upsides are:

• easier migration for users using babel plugins: In the original plan, users had to migrate to @vitejs/plugin-react-babel. With this change, they can use @vitejs/plugin-react.
• easier migration for users trying rolldown-vite: In the original plan, early users have to use @vitejs/plugin-react-oxc to try the behavior. With this change, they can simply switch to rolldown-vite.
• easier to use react-compiler: given that react compiler requires babel and I assume there'd be many users that would like to use it, it would be better if they won't need to switch to @vitejs/plugin-react-babel

The downsides are:

• slightly bigger package size due to babel related code: It will be +30kB compared to @vitejs/plugin-react-oxc. I think this is acceptable.
• @babel/core + some plugins would be downloaded even if the user doesn't need it: babel requires 11.3MB of deps. Maybe we should make @babel/core an optional peer dep? (when rolldown-vite stabilizes) That would cut down 11.1MB.

[ArnaudBarre]

I like the idea!

The question is how easy should we make to use the react compiler? If most users will use it, maybe we could also add it as a dependency so users only need a single line change to use it. Or we could even enable it by default and add a boolean to opt out.

I still want to do some tests on real world code (not triangle benchmark were the code path is really simple) to better weight the performance impact of the compiler on build time

Given that the default template already include eslint, I'm not sure the argument of extra node modules weights a lot even I would prefer less packages.

Note: I think we should update the oxc recommendation in the swc plugin

[sapphi-red]

The question is how easy should we make to use the react compiler? If most users will use it, maybe we could also add it as a dependency so users only need a single line change to use it. Or we could even enable it by default and add a boolean to opt out.

I think it shouldn't be the default at least until react-compiler reaches stable (currently it's RC).

I still want to do some tests on real world code (not triangle benchmark were the code path is really simple) to better weight the performance impact of the compiler on build time

FWIW I saw some real world numbers at reactwg/react-compiler#33, reactwg/react-compiler#52.

Note: I think we should update the oxc recommendation in the swc plugin

Done 👍

[hi-ogawa]

I have test cases for NODE_ENV=production vite dev and NODE_ENV=development vite build #606, but these are failing on oxc since jsx runtime transform respects command instead of NODE_ENV.

For now I'll skip this case on rolldown since the behavior is same as previous plugin-react-oxc and also I'm not sure about this use case in the first place.

[sapphi-red]

I think it is a bug in plugin-react-oxc. It should skip setting the development option as then it would default to isProduction.
I'll fix this in a separate PR.

[hi-ogawa]

Created an issue #622

[ArnaudBarre]

FWIW I saw some real world numbers at reactwg/react-compiler#33, reactwg/react-compiler#52.

This are runtime benefits. I tested on my app bundled with esbuild, adding babel with compiler on all tsx files make the bundling time go from 700ms to 13s. So for now I don't think it's good to enable it by default given the non negligeable build time cost.
I'm not sure if we should make babel optional or not given that

[sapphi-red]

I just noticed that we should keep @babel/core as a normal dep for now as in normal Vite, this plugin will still use babel for the refresh transform.
I think we can put it on the table after we switch to rolldown-vite.