Bundler generalization

[johnhungerford]

When I saw that you had started working on a scalajs-esbuild plugin, it occurred to me that there is a lot of functionality here that is independent of the particular bundler used. It might be worth abstracting that functionality into a base plugin that is extensible in the manner of, say, jsEnv. There are at least two compelling reasons to do so:

1. New bundlers seem to be popping up, and it would save time and effort to get Scala.js support for them
2. Different bundlers optimize for different things, and it may be worth using multiple bundlers in the same project. For instance, I might want to use esbuild for tests and dev servers, where I don't really care so much how the code is bundled as that it does so quickly, but use webpack for production bundles because there are some very specific configurations I need to this optimally.

For reference I already have POC for this idea here, much of which is based on scalajs-vite. It works fairly well so far (I'm using it in my project), but I'm not married to it and scalajs-vite is both cleaner and reveals a deeper understanding of sbt than I have. Any interest in taking an approach like that?

[ptrdom]

Oh yes, when scalajs-esbuild is feature complete - at it will be relatively soon - I can see myself working on a scalajs-bundler Mark 2, starting from a scalajs-esbuild fork probably 😄

The way I see it the bundler functionality can be abstracted, and when any bundler specifics are fed as scripts that are just called to be executed by the core plugin, then any bundler can be plugged in without overcomplicating the core plugin implementation.

[johnhungerford]

I guess the question then is whether it would make more sense to just work from scalajs-esbuild instead of scalajs-vite? I'm less interested in the actual implementation of the bundler than that it can do all the things I need. What do you think?

[ptrdom]

Once we refine the full scope of work from the issues you created it will be easier to determine how to proceed. But scalajs-esbuild is the better implementation to extend.

[johnhungerford]

Ok looking at your responses to prior #39 and #41 I think it looks like what we have in mind is different enough that I'm going to keep working on sbt-jsbundler for now since it addresses my needs. Maybe once you're done with scalajs-esbuild we can revisit whether it would make sense for your more generic approach to include bi-directional import resolution.

[ptrdom]

Closing this because the suggestion will be addressed in a separate project.