You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know this will be an annoying change to make, but it would be great if this could land in 1.0 as well. I understand these shims are important for implementing munit features, but they are also potential landmines.
Here are two ways it can go wrong (and has for me):
I write a Scala.js library accidentally using File or Path or one of the other classes shimmed here. I write an munit suite to test it, and voila it all works (b/c munit has kindly put these JDK shims on the test classpath). So I publish my library. Then, a downstream depends on my library and tries to create a Scala.js app ... but they can't, because they get linking errors for Path, File, etc. Having JDK shims on the test classpath makes it nigh impossible for libraries to catch these sorts of mistakes.
If some other well-meaning library or application has also shimmed these JDK classes, then there would be a classpath conflict, in which case I'm actually not sure what happens. But probably not good.
Off the top of my head, there's a couple ways to avoid this (not mutually exclusive):
Move these shims out of the java package into the munit package and in your JVM sources create type aliases to point e.g. munit.internal.Path to the JDK implementations.
Create wrapper classes in the munit package, that delegate to JDK on the JVM and Node.js on JS.
Thanks for your attention to this issue.
The text was updated successfully, but these errors were encountered:
@armanbilge you would be interested in contributing a PR? It would be nice to include this in 1.0 since it's arguably a breaking change to remove the JDK shims.
Specifically: https://github.com/scalameta/munit/tree/main/munit/js/src/main/scala/java
I know this will be an annoying change to make, but it would be great if this could land in 1.0 as well. I understand these shims are important for implementing munit features, but they are also potential landmines.
Here are two ways it can go wrong (and has for me):
File
orPath
or one of the other classes shimmed here. I write an munit suite to test it, and voila it all works (b/c munit has kindly put these JDK shims on the test classpath). So I publish my library. Then, a downstream depends on my library and tries to create a Scala.js app ... but they can't, because they get linking errors forPath
,File
, etc. Having JDK shims on the test classpath makes it nigh impossible for libraries to catch these sorts of mistakes.Off the top of my head, there's a couple ways to avoid this (not mutually exclusive):
java
package into themunit
package and in your JVM sources create type aliases to point e.g.munit.internal.Path
to the JDK implementations.munit
package, that delegate to JDK on the JVM and Node.js on JS.Thanks for your attention to this issue.
The text was updated successfully, but these errors were encountered: