Fast refresh without babel

[Artur-]

Description

For performance reasons, I would like to not use Babel at all but let esbuild handle everything while still having support for fast refresh. By looking at the code it seems like fast refresh is the only reason that babel is invoked by default.

As a side effect, this would avoid problems like the one mentioned in #266

Suggested solution

If I understand correctly, vite-plugin-react-swc has a pure JS implementation of react refresh. By integrating that into this repository, the babel plugin react-refresh/babel becomes unnecessary and babel can be skipped by default. Maybe there is a reason this cannot be done though?

Alternative

Using plugin-react-swc would be an alternative but has other drawbacks for existing (aka old aka legacy) projects, such as the requirement to have useDefineForClassFields: true and that writing custom plugins in Rust cumbersome to many compared to a few lines of JS

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[Artur-]

or is fast refresh actually implemented in swc core?

[ArnaudBarre]

The philosophy of the projects:

• If you need plugin in JS, you pay the cost a Babel, for now (SWC has support for JS plugins but it's incomplete and not guaranty to be performant if you hook into a lot o nodes)
• If you need speed, use the SWC plugin (which uses a builtin implementation of Fast Refresh). If then you want to use it with legacy code, use a patch (see feat: enable custom transform vite-plugin-react-swc#178 (comment) for an explanation)
• In an ideal world you could use esbuild already used by Vite: Add Fast Refresh support evanw/esbuild#3449 (I could update the PR to improve a few things, but I'm working on other things because of no feedback from the author)

[Artur-]

Thanks for the info!

In our case we are trying to create a sensible configuration for our framework users which makes this a bit more tricky, as they might have a mix of old and new projects. What we really are trying to implement is a way for old projects to work and allow people to gradually migrate to (newer) standards.

The linked esbuild PR seems like exactly what we would be hoping for, let's see if that progresses.