[easel]

It would indeed by lovely, but also a bit of a challenge in this case. Part of how scala.js is able to achieve reasonable javascript size is that it uses very aggressive dead code elimination including google closure compiler. In order to do that, it has to see ALL the code that's actually going to be used.

There's nothing preventing that single blob from being exported to webpack. I currently export stuff into a legacy require.js/angular app using globals, so I imagine the same could be accomplished with webpack.

The issue will arise when you attempt to include multiple "scala.js webpack" modules. Each one will be compiled as an independent unit and carry it's own subset of the scala standard libraries, etc. For a transitional scenario, that's probably fine, but it does make participation in a fully polyglot webpack-loader or npm ecosystem problematic.

[dustingetz]

A simpler case is a scalajs app depending on commonjs modules, I think this should be possible? One problem is that a commonjs module depends on other commonjs modules, so maybe it becomes all or nothing

[gedy]

Since webpack does dead code elimination as well, wondering if that all needs to be a problem solved in Scala.js?

[sjrd]

Scala.js does a much better dce than Webpack, or any other JavaScript optimizer (including Closure). It does it at the method level (not top-level function/class level), and can also leverage the type system to do a better job at it. So yes, it needs to be solved at the Scala.js level.

Scala.js also performs whole-program optimizations of the code, besides "simple" dead cole elimination.