Why not just

Test / test := {}

?

That said, not having anything shouldn't throw an exception in the first place. I can't reproduce that behavior, even with the JSDependenciesPlugin.

Now, emptying Test / jsEnvInput would be bad, yes, because you remove the script that connects to the server to listen to test execution commands sent by sbt. We can probably emit some kind of error in that situation, indeed. But yeah, you shouldn't empty Test / jsEnvInput, that is not going to help.

Using Test / test := {} has the same problem of:

[error] stack trace is suppressed; run last demo / Test / jsEnvInput for the full output
[error] (demo / Test / jsEnvInput) java.nio.file.NoSuchFileException: require-file:/tmp/tmp-12228659344646593601react.development.js

ah sorry - correction:

Using Test / test := {} works but when I do a release with sbt-release, then the above error about demo / Test / jsEnvInput appears.

I can't reproduce that behavior, even with the JSDependenciesPlugin.

@sjrd I can provide a repo if you like :)

I had a similar error with the same kind of message in a cross-build project until have moved the enablePlugins(JSDependenciesPlugin) configuration to be in the .js module only.

@plokhotnyuk Unfortunately in my case it's not a cross-project but a plain JS-only module

@sjrd I can provide a repo if you like :)

Yes, please.

It's likely jsdependencies' fault, though. I suspect the exception is thrown by this line:
https://github.com/scala-js/jsdependencies/blob/134283738b95c072901a6d672cb190791213b433/jsdependencies-sbt-plugin/src/main/scala/org/scalajs/jsdependencies/sbtplugin/JSDependenciesPlugin.scala#L409

Which jsEnv are you running with? If the jsEnv terminates without connecting to the test adapter, the test adapter should fail, not hang. However, if the jsEnv does not terminate, there's nothing the test adapter can do (except for timing out, which we probably should consider).

Actually, scratch that. If the input is empty, scalaJSCom.init never gets called. So the underlying connection is actually established and the jsEnv may not terminate. So the jsEnv is working correctly.

To avoid the hanging, I don't think we have another option than setting a timeout on the TestAdapter's call.

Alrighty, reproduction is here:

• check out https://github.com/japgolly/scalajs-benchmark/tree/issue/jsEnvInput
• sbt test and you'll see the demo module fail

If you look at the module's config you can see that it only enables ScalaJSPlugin & JSDependenciesPlugin and doesn't configure tests at all. I'm not setting the jsEnv.

Thank you. That's definitely JSDependenciesPlugin's fault. I have re-reported that specific issue at scala-js/jsdependencies#40.

Thanks @sjrd !

Actually, scratch that. If the input is empty, scalaJSCom.init never gets called. So the underlying connection is actually established and the jsEnv may not terminate. So the jsEnv is working correctly.

To avoid the hanging, I don't think we have another option than setting a timeout on the TestAdapter's call.

IIUC, the jsEnv itself already terminates: the execution of all the scripts finishes, and nothing was put in the event queue nor the I/O handlers, so the Node.js process should finish on its own. That means that

1. ExternalJSRun.future should complete with a successful(()).
2. At that point, the nodejs.ComSupport should be able to complete its own future (not sure whether it should be a success or a failure at this point, but that doesn't matter).
3. Which should in turn cause the JSEnvRPC to cancel all pending RPC calls
4. And that should cause TestAdapter.loadFrameworks to fail, instead of hanging.

Is the above reasoning correct? If yes, what is going wrong that causes the hanging? Perhaps a race between cancelling call RPC calls versus starting the loadFrameworks RPC call?

nothing was put in the event queue nor the I/O handlers

The com run establishes a connection to the JVM unconditionally (even if init is not called). So there are open I/O handlers, hence Node.js does not terminate.

This is a specification problem in the JSEnv that allows not calling scalaJSCom.init on a com run. Allowing this, enables to cleanly terminate the JSEnv (by closing the connection from the JVM side).

It is unclear to me how to resolve this. We could:

• Change the specification and require init to be called. Then we could only establish a connection to the JVM once init is called.
• Fail if messages are in the inbound JS queue and init is not called after a certain amount of time (can't think of a better condition...)
• Push the problem upwards to users of the JSEnv.

After giving this some thought, I think we do not gain a lot with the first two options, because the JS side might as well have a bug so it doesn't answer to messages. To address this for now, I think we should simply refuse to create a TestAdapter with an empty input.