[SBT-Plugin] Default IntegrationTest configuration

[pslaski]

I have tried to run ScalaJS code as SBT Integration test suite, I configured them as is written in the docs

.configs(IntegrationTest)
.settings(commonSettings, Defaults.itSettings)
.settings(inConfig(IntegrationTest)(ScalaJSPlugin.testConfigSettings))

but, during execution of IntegrationTest / fastLinkJS operation, I got

[error] Referring to non-existent class org.scalajs.testing.bridge.Bridge
[error]   called from core module module initializers
[error] Referring to non-existent method static org.scalajs.testing.bridge.Bridge.start()void
[error]   called from core module module initializers
[error] There were linking errors
[error] (IntegrationTest / fastLinkJS) There were linking errors

The fix for that is adding explicitly scalajs-test-bridge as IntegrationTest scope dependency.

My proposition is to have in ScalaJSPlugin defined integration tests config settings (similar to testConfigSettings) which user can easily add to IntegrationTest scope

[enriquerodbe]

Thanks for the workaround, I stumbled upon this and wasn't able to make this work!

[sjrd]

I don't think we can do that. Unfortunately, sbt decided to design its libraryDependencies so that the setting itself is scoped in the project, but the right-hand-side has an additional % Test or % IntegrationTest. That means that we cannot add config-specific libraryDependencies from a Seq[Setting[_]] that should be passed in inConfig.

Said in a different way: I do not see what setting we could put inside testConfigSettings that would achieve the effect of, when passed through inConfig(IntegrationTest)(...), adding a dependency in the IntegrationTest configuration.

---

An entirely different solution would be to resolve the dependency ourselves and patch it up directly in fullClasspath. The problem with that is that it requires dark magic in our own build, as we must instead do an actual dependsOn and not resolve from the internet. And every piece of dark magic like that dramatically reduces our confidence in our tests, since we don't actually test the sbt plugin as users will see it.

---

My opinion here is that we should improve the documentation instead.

[pslaski]

Thanks for your response - yes, improving the documentation would be good too and probably the simplest and fastest solution