-
-
Notifications
You must be signed in to change notification settings - Fork 113
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
Option to skip fast refresh #346
Comments
For me remix should either provide passing babel plugins or not vendor the fast refresh transformation. Running twice Babel is not something we want to make easy to do. cc @pcattori |
Yes I agree with @ArnaudBarre . We're already done some exploratory work in Remix to better interop with That said, I don't have any problem with running user-defined Babel transformations from users separately via something like https://www.npmjs.com/package/vite-plugin-babel . Of course, the optimal way is to only parse the Babel AST once and then run all the transforms. So in the future when Remix/RR get better interop with |
Thanks for the fast replies.
The actual change so far (understand it's a WIP) looks a bit different from what you described. It's Just extrapolating from that PR, my impression is that my vite config would end up looking something like this, where the remix plugin passes the config along plugins: [
remix({
viteReact: {
babel: {
plugins: ['my-babel-plugin']
}
}
})
] And someone using SWC might do (just an arbitrary config property) plugins: [
remix({
viteReactSwc: { tsDecorators: true }
})
] If so, then that works for my use-case. |
Yeah similar API will be offer for both plugins so that Remix can configure the plugin installed by the user (babel or SWC) without needing to manage the transform part, so the final config will look like your initial code but will not have issues because remix will not try to transform files |
That would be fine, but what you're describing and the current WIP don't seem to line up to me. Maybe I'm missing something. It just includes swc-plugin inbetween the remix ones. https://github.com/remix-run/remix/blob/cef3e66cad89e31b5550b1c3ab51fbb311251353/packages/remix-dev/vite/plugin.ts#L1589 I suppose if the user declared it as well (to specify config) then it would just be applied twice. (Unless vite is able to de-dupe them? But I don't think so) So then I guess that line I linked to would be removed in the future? Meaning remix would no longer work as a standalone plugin, and would require users to opt into 1 of the From what was described, I was picturing remix doing something more like this. It would give the flexibility for remix to adjust the order in future if that was necessary const importSwc = async (conf) => {
try {
const swc = await import("@vitejs/plugin-react-swc");
return swc.default(conf);
}
catch (e) { return null; }
}
const importReact = async (conf) => {
try {
const react = await import("@vitejs/plugin-react");
return react.default(conf);
}
catch (e) { return null; }
}
export const remixVitePlugin = async (conf) => {
const swc = await importSwc(conf.swc);
const react = await importReact(conf.react);
if (swc && react) throw new Error("both...")
const reactPlugin = swc || react;
if (!reactPlugin) throw new Error("neither...");
return [
{ name: 'some-remix-before' },
reactPlugin,
{ name: 'some-remix-after' }
]
} |
I will let @pcattori answer for the Remix point of view, we maybe need to think on this but I yeah in the future I think it's better if remix/RRv7 is just plugin on top a base plugin that is framework/transpiler dependent. For example in one year if rolldown replace esbuild as the default TS transpiler, I will make sure it ships with builtin Fast refresh transformation so we could have a zero-deps react plugin! |
Description
I have a custom Babel transformation which I'd like to apply using this plugin. I'm also using Remix
With this setup, I get this error: "Uncaught SyntaxError: Identifier 'RefreshRuntime' has already been declared"
I think the problem is that both plugins are attempting to import the same thing. I tried playing with the order, but doesn't matter.
Here's the fragment containing the problem:
Suggested solution
Add a config option e.g.
enableFastRefresh
, defaulting to true (current behaviour), to opt-out of fast refresh behaviourAlternative
I could write my own vite plugin which is just a copy-paste of this one with the fast refresh stuff removed
Additional context
Since viteReact returns an array of plugins, I tried hackily using the 0-th item (the babel one), but it doesn't work because the two are tied together: the babel one applies some things required for fast refresh.
Validations
The text was updated successfully, but these errors were encountered: