adding a Wasm test environment

[qxrein]

Cats over Wasm Implementation
Current Status:

• Added a Wasm test environment.
  • ✅ (passes JS only tests)
  • ✅ (passes Native only tests)
  • ✅ (passes JVM only tests)

To fix:

• sbt testsJS/test ends with RPCCore$ClosedException

[djspiewak]

I'm definitely in favor of adding a WASM environment to test in but there's a lot to address here. Several things were changed unnecessarily (notably scalatest).

Additionally, this would need to be reflected in a new GHA matrix entry in order to be tested in CI

[qxrein]

@djspiewak thanks for suggestions, i'll make sure to fix issues based upon your suggestions. My current motivation is to make sure that every tests atleast work on wasm then i can move forward to change based on the projects requirements.

Why was this test rewritten?

in my attempt to port i am facing this issue for org.scalajs.linker.runtime.UndefinedBehaviorError: java.lang.ClassCastException: undefined cannot be cast to java.lang.String can you please suggest what is the fix for this rather rewritting tests what can we change to perform this?

[armanbilge]

can you please suggest what is the fix for this rather rewritting tests what can we change to perform this?

We don't know either, because Wasm is new and experimental :) instead of rewriting tests to try and fix stuff, it's okay to push code with tests that don't work because then we can investigate together why they are broken.

[djspiewak]

To add to what Arman said, it's very plausible that the exception you're seeing is coming from a bug in the WASM support in Scala.js itself. The only way to figure that out is to get the code shared amongst all of us, along with the stack trace, so we can try peeling back the veil and seeing if the compiler is actually just doing the wrong thing.

Popping back up again, like I said, the right way to do this is by adding a JsEnv in the build. Today, this ADT looks like the following:

sealed abstract class JSEnv
object JSEnv {
  case object Firefox extends JSEnv
  case object Chrome extends JSEnv
  case object NodeJS extends JSEnv
}

Add a case for WASM and condition on it in the relevant places, just like we do for the browser environments today, and most of the existing build machinery should essentially come to life without having to spin up custom projects like testsJS in the OP.

[qxrein]

instead of rewriting tests to try and fix stuff, it's okay to push code with tests that don't work because then we can investigate together why they are broken.

this is what i was looking into, in my trial to port and fix the log errors for that issue. I came across some tests inside cats-effect repo which just exists (like even if they are not causing an issue in the repo they have 0 actual tests to pass they are just existing) for an undefined error we can bypass them, this made me wonder that i can't fix this issue in test file itself, there are some other issues.

also thanks for the explanation @djspiewak i appreciate your efforts, i'll make sure to try tests accordingly.

[qxrein]

I am not sure about this, if it is valid (shall we not change this parameter?)

[djspiewak]

I definitely would not do it this way. NodeJS without WASM is still a valid environment. You should add an additional member of the JsEnv ADT to represent WASM and then add the appropriate cases here and elsewhere.

[armanbilge]

@qxrein are you able to keep working on this PR? thanks!

[qxrein]

yes, I am working on this and thankfully most tests are green now. I am trying my best to finish this before v3.7.

[armanbilge]

thankfully most tests are green now

Cool! When you have a chance, please push your changes, thanks!

[qxrein]

made progress with a this PR to enable mostly all tests to pass over (WASM) for JS test suite, overcoming ClassCastException errors caused by JavaScript interop assumptions in the tracing system. I added defensive interop - lazy property access, null checks, and fallback paths for operation in good enough WASM’s limited interop environment while maintaining regular JS functionality. Now, most tests pass in both JS and WASM modes,
PS: Disable unique trace assertions for WASM mode (tests failing:

• TracingSuite.IO.delay should generate unique traces
• TracingSuite.Async.delay should generate unique traces)

[qxrein]

tests failing

fixed

[qxrein]

merge conflict is cursed

[qxrein]

making a new draft PR

[Fristi]

As you already gone in to the ScalaJS direction not sure if this would help you..

I stumbled upon this talk https://www.youtube.com/watch?v=Z2SWSIThHXY which uses Graal to compile to WASM. There are still things in the works like threading, etc ..

[qxrein]

Thanks for the reference @Fristi i believe the approach i am currently using provides more mature and complete WASM support today, especially for our specific needs around fibers and asynchronous operations, CE relies a lot on threading and i’m keeping the port as minimal as possible to make maintenance easy. That said, GraalVM’s WASM backend is moving fast-once they sort out threading and a few other features, it could be a good option.

Sorry for reopening the PR, accidentally hit the button on the gh mobile app.