Adding scalajs-linker as a dependency introduces unexpected error

I ran the Scala 3 compiler successfully with the -scalajs option, sjsir files appear in the target directory as expected.

After this step, I wanted to create human-readable JavaScript. Therefore I added scalajs-linker as a dependency to the SBT project.

Running the first step again with the scalajs-linker being added, I unexpectedly get an error:

     while compiling: (inline)
        during phase: genSJSIR
                mode: Mode(ImplicitsEnabled)
     library version: version 2.13.14
    compiler version: version 3.5.0
            settings: -classpath "" -d (memory) -nowarn true -scalajs true -usejavacp true

An exception or error caused a run to abort: 'org.scalajs.ir.Types$ClassType org.scalajs.ir.Types$ClassType$.unapply(org.scalajs.ir.Types$ClassType)' 
java.lang.NoSuchMethodError: 'org.scalajs.ir.Types$ClassType org.scalajs.ir.Types$ClassType$.unapply(org.scalajs.ir.Types$ClassType)'
...

I assume the source to be compiled was OK, as sjsir files were generated. I don’t know if this counts or not, but I compiled a simple Hello app. The goal is to be able to compile arbitrary Scala classes to JS, which can be lazy-loaded by the front end.

Do you have any idea what could cause this error? How do you include the linker properly in an SBT project for human-readable JS generation?

I believe you should never pass -scalajs flag directly. Similarly you should not depend on linker in the project compile dependencies. It could have messed up the classpath. Both of these should be done by the build plugin. Check Scala.js docs to see how to do it Scala.js project structure - Scala.js
The only exception could be

Meanwhile, this turned out to be a more general binary incompatibility issue, and I’m still examining why different return types are generated by the compiler for unapply in Scala 2 and 3.
https://github.com/scala/scala3/issues/21560

I think the presence of the -scalajs flag is a good idea, though you’re absolutely right that the linker should be kept separately from other parts of the project.

I’ll update on the unapply issue, as that could affect more users

UPDATE: here’s a discussion about the issue: https://github.com/scala/scala3/discussions/21563

Pattern matching changed.

I don’t think there is an expectation that synthetic methods are the same in Scala 2 and 3.

It’s OK, but backward compatibility is an issue in this case. As with the missing synthetic method, all extractor calls of a Scala 2 binary will crash