scalajs-bundler icon indicating copy to clipboard operation
scalajs-bundler copied to clipboard

esbuild bundler instead of webpack

Open ngbinh opened this issue 4 years ago • 11 comments

I switched to use esbuild, an extremely fast JS bundler, instead of webpack recently on our big scala.js repo at work. The result is quite impressive, there are projects that esbuild can bundle in seconds where webpack would just OOM.

I still need to rely on scalajs-bundler to pull in npm dependencies. While I can just use scalajs-bundler without webpack by not calling fastOptJS/fullOptJS, I believe it may be beneficial for scala.js ecosystem as a whole to have an official backend on esbuild in scalajs-bundler.

I can try to give this a shot if you guys think it is the right thing for scalajs-bundler

ngbinh avatar Sep 01 '20 03:09 ngbinh

just FYI, I have been using esbuild for a couple of months on both production and dev build on a very large scala.js project at work. The plugin is fairly simple, I still need scalajs bundler to pull npm dependencies but not webpack.

ngbinh avatar Oct 13 '20 14:10 ngbinh

Interesting! Do we need to provide some sort of integration (ie, we would replace the bundling part currently done by webpack with something that uses esbuild)? Or should we remove the concern of bundling from sbt-scalajs-bundler and focus only on fetching NPM dependencies?

julienrf avatar Oct 13 '20 14:10 julienrf

There are tasks that webpack is better due to its rich ecosystem. But esbuild kills it on js bundling. So I think it would be nice if this plugin provides a clean solution to fetch NPM dependencies. For bundling, because esbuild can handle the whole hundred of MBs js output, you don't need something like LibOnly mode likes in webpack for it to work. It would make the plugin much simpler and there is no need for the bundler to know anything about scalajs internal

ngbinh avatar Oct 14 '20 01:10 ngbinh

It maybe interesting to explore this approach. scalajs-bundler approach is nice as you only need sbt running but keeping up to date with the js tooling world takes some effort.

cquiroz avatar Oct 16 '20 12:10 cquiroz

Given that module splitting support has landed in 1.3, I don't think we need the libraryOnly mode. So I think "pull npm dependencies only" might be the right role for scalajs-bundler.

ramnivas avatar Oct 16 '20 16:10 ramnivas

I wonder the impact of tests. Could we be able to write tests in sbt if there is no bundler integration. I mean tests that would use a facade

cquiroz avatar Oct 16 '20 21:10 cquiroz

esbuild is used by Snowpack too

He-Pin avatar Oct 21 '20 06:10 He-Pin

Also consider https://vitejs.dev/, which uses esbuild, as alternative to Webpack.

mkotsbak avatar Nov 04 '21 15:11 mkotsbak

@ngbinh I agree with @mkotsbak why not consider adopting vite instead of just esbuild?

vite would give a double benefit of bringing the speed of esbuild but also enabling code-splitting (not yet supported in esbuild as I understand...), which is another hot feature: https://github.com/scalacenter/scalajs-bundler/issues/2

So maybe we get 2 birds with 1 stone adopting vite alternative to webpack?

evbo avatar Nov 22 '21 19:11 evbo

Vitejs is great. But if you only need a bundler then using esbuild directly is simpler

ngbinh avatar Nov 22 '21 22:11 ngbinh

Given that module splitting support has landed in 1.3, I don't think we need the libraryOnly mode. So I think "pull npm dependencies only" might be the right role for scalajs-bundler.

I don't understand this comment. libraryOnly mode is still useful IMO as it allows clients to cache your library's bundles which will change much less frequently than your application code. Or do I misunderstand your point?

matthughes avatar Mar 31 '22 00:03 matthughes