devCommands is still too strict: It misses ~

[nafg]

The fix for #27 is a step in the right direction I suppose, but it still misses one case.

If I do ~myproject/reStart everything is fine because it will split on '/' and get "reStart". However if I do project myproject; ~reStart it doesn't do the right thing because it returns "~reStart" which doesn't match.

[nafg]

Actually if a command starts with ~ arguably it should trigger dev mode no matter what the command is.

[nafg]

It would be interesting to have a setting that instead of a list of strings, was a function that could examine the current command and use its own logic.

[nafg]

Weirdly, if I have Global / onChangedBuildSource := ReloadOnSourceChanges and I run sbt ~myproject/reStart, at first webscalajs.CrossSbtUtils.executedCommandKey.value returns reStart but after changing a build file, causing sbt to reload, it returns ~.

(sbt 1.3.4)

[vmunier]

Hi,

It would be interesting to have a setting that instead of a list of strings, was a function that could examine the current command and use its own logic.

Agreed, such a setting would be useful. At the moment, you can configure isDevMode in scalaJSPipeline and provide your own logic. You could read from an environment variable for instance: isDevMode in scalaJSPipeline := !sys.env.get("SCALAJS_PROD").contains("true")

I think parsing the SBT command line to know whether fastOptJS or fullOptJS should be run is too fragile. As you pointed out, there are cases that are not handled well: the current parsing code fails to detect ~reStart or project myproject; reStart as dev commands.

sbt-web-scalajs/src/main/scala-sbt-1.0/webscalajs/CrossSbtUtils.scala

Line 13 in f7e8dde

state.value.history.currentOption.flatMap(_.commandLine.takeWhile(c => !c.isWhitespace).split(Array('/', ':')).lastOption).getOrElse("")

I am thinking of removing devCommands completely and let the user define an environment variable or SBT setting to configure the build on whether fastOpsJS (default) or fullOptJS should be run.
That would be a breaking change and it's forcing the user to reload SBT to be able to switch between fastOpsJS or fullOptJS, but the behaviour is more predictable.

[sjrd]

or SBT setting to configure the build on whether fastOpsJS (default) or fullOptJS should be run.

Also known as scalaJSStage, defined in the core sbt-scalajs. 😉

[vmunier]

Hi everyone, I've just opened a PR, which uses the scalaJSStage setting from the Scala.js projects to know whether to run fastOptJS or fullOptJS: #57. Any feedback welcome!

[vmunier]

sbt-web-scalajs v1.1.0 now relies on scalaJSStage to know whether fastOptJS or fullOptJS should be run.