It’s not multiple instances of the same sbt plugin. That would be utterly impossible. There is only one sbt plugin at play here: sbt-dynscalajs 0.1.0. What we load via
ClassLoader are multiple instances of the Scala.js linker (not of the Scala.js sbt plugin). Note that sbt core itself does exactly the same kind of manipulations to load multiple instances of scalac with
++! There is no “right now” in this approach, it’s always going to be like that.
Also note that cbt must do the same thing if it wants to support multiple versions of Scala.js in the same build. Just as it needs
ClassLoaders to load multiple versions of Scala (at least I strongly suspect it does; I don’t know how else it could work).
Hum maybe my readme wasn’t very clear about this. A
shared folder if perfectly fine. Under this model the equivalent is simply the base directory of a project. So for some project
foo/src/ acts as shared folder instead of
foo/shared/src/. For platform-specific sources, see the issue I mentioned in my previous post.
No, the only reason that really prevents you from using this plugin right now is that it doesn’t support Scala Native. Someone (not me) would have to write a similar plugin for Scala Native, say
sbt-dynscalanative. Then you can use both plugins in a build, and you get triple dynamic platform support. Indeed, the way it is written, sbt-dynscalajs` can very well be composed with another similar plugin.
Since I was advocating earlier not to fiddle with multiple versions of Scala Native at the moment, the first iterations of that plugin wouldn’t even have to use any
ClassLoader, as it could statically link against the most recent version of the Scala Native linker. So even a non expert could do it, by copying and adapting the relevant parts of sbt-dynscalajs and sbt-scalanative.
I don’t there is a solution space. As I said above, the way sbt-dynscalajs does it is the way to support multiple versions of a linker in the same build. Unless I misunderstood what you mean here?