@vitejs/plugin-react-swc takes similar or more time to build than @vitejs/plugin-react

[Amansaxena001]

I just migrated to swc and the results are not that great, the build time on avg its coming more or less around before the migration. Is that expected?

[ArnaudBarre]

If you don't use any babel options, yeah it's expected that build time don't change.

Summary without anything babel or swc specific:
Classic Vite 7:

• dev: SWC is faster
• build: both should default to the buinltin esbuild pipeline and be the same

Vite-Rolldown/Vite 8:

• dev & build: plugin react will use the builtin oxc pipeline and be slightly faster than SWC (should not be hard to measure on the total timing because most of the time will be on other things).

If don't need anything special, you should try out Vite-rolldown with plugin-react.

[Amansaxena001]

@ArnaudBarre the build time on rolldown if i dont use swc ( which is crashing my build ) its 100x faster. We ve a very large project and I was amazed.

I am now trying with swc+rolldown on vite-7 but the dev server wont load - getting vite client not found.

Is the rolldown ready to be used in prod apps? as its still in beta

[Amansaxena001]

@ArnaudBarre So for faster build times and fast dev server what should I go with? One silly question but swc is for transpiling and all for dev server correct and rolldown is for bundling so how the dev server speed is affected by rolldown 😬?

As of now my dev server is working fine and rolldown build is also seems fine but when I use the dev server I feel the same speed, hmr is also same, simple save reloading the full page.

[ArnaudBarre]

My recommandation is to go with Vite-rolldown + plugin-react and do a bit of testing to unsure everything is good, but this is a good investment to get the best setup and will be the default one in a few months.

To be exact, the dev server is impacted by Vite-rolldown which uses rolldown which wrap oxc for JS/TS transform. This transform is better integrated with the rest of the transform (less back and forth with the JS runtime) so it should be faster. But again, this is theory, in practice JS/TS transformation is rarely the bottleneck once done with tools like esbuid/swc/oxc so it's probably not noticeable.

simple save reloading the full page

If you mean full page reload, this is not expected. For most files, you should get HMR without full page reload

[Amansaxena001]

@ArnaudBarre What version do you suggest for stability ? I am using rolldown-vite@7.2.5 and upgrade vite to 7.0.0 from 6.3.6. Im down to get this on prod and see even though we ve a very big project we are excited for this.

react refresh is also in oxc based implementation so if we go by metrics -- is it ok to say that overall setup inturn supersedes swc altogether ( i believe so )

If don't need anything special

Also in your first reply you mentioned , can you elaborate on that , i forgot to mention

[ArnaudBarre]

Rolldown-vite is reaching stability and not really in alpha anymore, so the later the better and 7.2.5 sounds good!
You should use `"vite": "npm:rolldown-vite@7.2.5", in your package.json until Vite 8 is available so you don't have both Vite and Vite-rolldown which could cause issues.

By 'anything special' I mean options like plugins or useAtYourOwnRisk_mutateSwcOptions that may not be transposable to oxc

[Amansaxena001]

Thanks @ArnaudBarre for the prompt responses, again thanks a lot.

[lewiii254]

Thanks for the clarification! So the recommended setup for the fastest builds/dev right now is:

• rolldown-vite + @vitejs/plugin-react (oxc-based)
• Avoid SWC unless we need SWC-specific options
• Use "vite": "npm:rolldown-vite@7.2.5" to avoid loading both Vite + Rolldown

Makes sense that oxc → rolldown integration is faster than calling SWC as a JS plugin. HMR doing full page reloads on my side probably means something in the chain isn’t patched yet.

One quick question:
For large projects, are there any known rough spots (HMR, watch mode, CSS/asset handling) we should keep an eye on before going all-in for prod?

Thanks,, this helps a lot!

[ArnaudBarre]

The minifier is I think the least stable part, so be sure to test the bundled/minified app. The chunking algorithm is also new, but that was also a reason for me to switch, we've added this on our main app:

  rolldownOptions: {
     output: {
        advancedChunks: {
          groups: [
            { test: /node_modules/u, name: "node_modules" },
            { test: /src\/icons/u, name: "icons" },
          ],
        },
      },
    },

[Amansaxena001]

@ArnaudBarre if i terser for minification instead of default oxc one then the bundle size are drastically reduced. Though Im not able to get the app running ( wip ). I also ve n't found much threads around terser with rolldown if people ve tried it.

TIA 🙏🏼

[ArnaudBarre]

It would be interesting if you can inspect what terser is able to minify and not oxc. Even if not always the best one, oxc tries to be really close to other minifiers on this benchmark: https://github.com/privatenumber/minification-benchmarks
So reports about missing opportunities that have a big impact will be analyzed by the OXC team.

[Amansaxena001]

@ArnaudBarre when Im using these treeshaking settings the build size is low but the app is reloading infinitely? on preview ( which runs on prod build vite preview ) and when not the bundle size is literally 2.x.x atleast for main which earlier was around 2.5-3K ish.

If possible could you share a config that has worked well for you

  treeshake: {
      moduleSideEffects: false,
      propertyReadSideEffects: false
   }

any idea what could be the reason?

[ArnaudBarre]

The infinite reload is clearly a bug. Can you see in the browser logs something that would hint to the issue? A reproduction is probably hard to get but it would help getting this fixed in vite-rolldown or rolldown.
Can you isolate which flag is causing the issue?

On my side I'm using the default treeshaking options, I will try more aggressive to see if I have the bug but this is probably dependent on a particular lib in the project