Support Scala.js 1.1.0 #1308
Comments
|
Thanks for reporting! Is Scala.js 1.1.0 not binary compatible with Scala.js 1.0? If they are both binary compatible, we should just upgrade to Scala.js 1.1.0. |
|
I've just checked the release notes as they have the answer to my question. I think it is safe to just upgrade the Scala.js version in the 1.x bridge series. |
|
At least it won't break anything that is not already broken today. But the way bloop handles its dependency on the Scala.js linker has serious flaws already now:
In general, a Scala.js codebase is entirely defined by (per sbt triple
These are the specific things that bloop should take from the build tool. It should not try to reconstruct |
Was this option possible in 0.6.x and the early 1.x RC or is this something new? Is the All of the linking infrastructure we have in place assumes we work against a linker interface (that's what we do in the Scala Native integration) and then classload it dynamically based on the project's configuration. Based on what you say, it seems this is not true for 1.x though.
If I remember correctly, we didn't do this because it depends on
Which brings me to the elephant in the room, which is that we can't trigger The current Scala.JS and Scala Native integrations in I feel your recommendations are important, but over-indexing on the "should's" and not the "why's" misses the big picture of why the current implementation works as it does. |
No that wasn't possible in 0.6.x. And in fact I realized since yesterday that it is not possible either in 1.x (I've opened scala-js/scala-js#4087 for discussion upstream). So in fact the only way to make this work is to classload
Hum, I'm confused now. I must be misunderstanding what you're saying. If you are already classloading the linker artifact dynamically based on the project's configuration, then the present issue shouldn't have happened in the first place. Perhaps you mean that you have your own linker interface for Scala.js and Scala Native that you classload? But if that one is statically compiled with one version of the linker, and it's always that linker that is loaded together with it, then we are back to square one. Perhaps if you could point me to where you are taking the Scala.js version of the project into account, it'll be easier for me to understand what bloop does now and how to best fix it to avoid the present issue to come back for every Scala.js version.
I thought exporting the projects systematically compiled everything to get the SemanticDB anyway? At least that's my experience with Metals (which is the only way I interact with bloop), where my observation is that when importing the project, it will trigger compilation of everything. Perhaps this is just because I tend to work in complex builds with source and resource generators? If this is truly a concern, I understand the difficulty of dealing with
I tried making a clear separation between a) all the things that define a Scala.js codebase (which includes
The philosophy of sbt-scalajs is to mimic to the greatest extent possible the semantics of the sbt task graph, including all its zillions of classpath settings and tasks. We achieve that by loading the IR from
I've tried to explain the "why's" of my "should's". Perhaps you'd have preferred if I had started my bullets with the problems (the "why's") followed by the solutions (the "should's"), rather than the other way around? |
Yeah, agreed 👍 I tried to say that our infra allows us to do this, and for some reason, I thought that's what we're doing for Scala Native, but after double-checking now it isn't the case: we depend on a static version of the Scala Native and Scala.js linker. I would love it if this changes. Ideally, we would avoid resolving the scalajs linker artifacts ourselves and get them from the build tool.
This is very infrequent in most of the builds, it only happens when people work on complex builds that have lots of sophisticated dependencies (for example, if the compilation of a project depends on running another one). Because the exporter avoids
Right, but just to make it clear: depending on those tasks/settings you mentioned would trigger
IIRC,
I believe we could stop using our own task if sbt defined a way to get
Thanks for elaborating. What I meant is that sbt-bloop needs to work around some big limitations in sbt to do what we do, and that constrains how much information we can reuse from the scalajs plugin. The fact that some setting/tasks return custom types and that we're calling these tasks reflectively from within sbt-bloop is also another important limitation. |
|
The underlying problem described in the conversation between @jvican and @sjrd is still there. |
|
@lolgab let's maybe open another issue and point to this one? Do you know the details enough to create an issue with description? |
|
I am getting a stranger error, where my version is not even listed:
I am using Scala.js 1.13.1 |
|
That looks like the Scala JS version is not defined in your Bloop configuration files, which is why this seems to be happening. Any idea why would export skip that? Anything complex about your build? |
|
I have the exact same issue, in the bloop json file I have: "platform": {
"name": "js",
"config": {
"version": "",
"mode": "debug",
"kind": "none",
"emitSourceMaps": false,
"jsdom": false,
"toolchain": [
]
},
"mainClass": [
]
}, |
|
Any idea why the configuration was produced this way? What build tool are you using in your project? |
|
I am using sbt 1.9.3 with these plugins: And vscode metals: It is a multimodule project where only one modules targets scalajs: Worth noting that there isn't a root module that aggregate the others. |
|
Experiencing same issue in multimodule project with one Scala.js module. |
|
should be fixed in #2161 |
Bloop is currently able to compile and link Scala.js 0.6.x and 1.0.x, but not 1.1.0. It fails with the following error:
Based on the release notes of 1.1.0, I think Scala.js 1.1.0 could largely reuse the Scala.js 1.0 bridge.
The text was updated successfully, but these errors were encountered: