Skip to content
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

esbuild bundler instead of webpack #359

Open
ngbinh opened this issue Sep 1, 2020 · 11 comments
Open

esbuild bundler instead of webpack #359

ngbinh opened this issue Sep 1, 2020 · 11 comments

Comments

@ngbinh
Copy link
Contributor

ngbinh commented Sep 1, 2020

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
Copy link
Contributor Author

ngbinh commented Oct 13, 2020

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.

@julienrf
Copy link
Contributor

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?

@ngbinh
Copy link
Contributor Author

ngbinh commented Oct 14, 2020

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

@cquiroz
Copy link
Collaborator

cquiroz commented Oct 16, 2020

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.

@ramnivas
Copy link

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.

@cquiroz
Copy link
Collaborator

cquiroz commented Oct 16, 2020

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

@He-Pin
Copy link

He-Pin commented Oct 21, 2020

esbuild is used by Snowpack too

@mkotsbak
Copy link

mkotsbak commented Nov 4, 2021

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

@evbo
Copy link

evbo commented Nov 22, 2021

@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:
#2

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

@ngbinh
Copy link
Contributor Author

ngbinh commented Nov 22, 2021

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

@matthughes
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants