Provide the optimization plugin for Next.js

[kaorun343]

Provide the optimization plugin for Next.js

[YassinEldeeb]

Hey @kaorun343! The SWC issue is indeed quite a complex topic, read swc-project/swc#8315 for more context.

My suggestion is providing the optimization plugin for Next.js, which wraps babelOptimizerPlugin.
We don't have to care about SWC version mismatch.

Unfortuntely, that's not possible, babelOptimizerPlugin comes from our client-preset package which we maintain in Javascript as it's targeted towards the Babel compiler, on the other hand, Next.js compiler plugins are only written in Rust, because SWC, the underlying compiler is written in Rust, that's why we need to have a completely separate package with separate challenges for the SWC plugin.

We can't simply port it, or wrap it for Next.js usage, SWC and Babel are completely different compilers, not just with language differences, but underlying architectural design.

[kaorun343]

Hi, @YassinEldeeb!

Thanks for your reply! 👍

I checked the other packages that provides plugins for Next.js, and I found they uses babel internally. So, it might be possible to do so, I think.

• vanilla-extract (CSS in JS library) provides @vanilla-extract/next-plugin , which is based on @vanilla-extract/integration and this uses babel internally
  • https://vanilla-extract.style/documentation/getting-started#bundler-integration
  • https://github.com/vanilla-extract-css/vanilla-extract/tree/master/packages/next-plugin
• Kuma UI (CSS in JS library) also provides @kuma-ui/next-plugin , which uses @kuma-ui/webpack-plugin and this uses babel internally, too.
  • https://www.kuma-ui.com/docs/install#setting-up-kuma-ui
  • https://github.com/kuma-ui/kuma-ui/tree/main/packages/next-plugin

They seems setting their original webpack loader in webpack field.
If this loader approach suits client-preset optimization, the SWC version implementation might be used internally.