sbt query

[eed3si9n]

sbt-projectmatrix represents both the idea of Scala version cross building and platform cross building (JVM, JS, Native) as flat list of subprojects, allowing parallel building and accurate representation of partial Scala support (e.g. sbt plugin only available for 2.12). As convenient at times, the cross build could also bloat into building 12 = 4 x 3 (2.11 ~ 3, JVM, JS, Native) artifacts for each source change.

One way to solve this might be to implement a filtering mechanism, similar to Bazel query.
In Bazel, users can issue build or test command against a query like bazel test dir1/dir1a/.... This will test all test targets under dir1/dir1a/ directory.

... as glob

Since sbt doesn't use directory structure to represent subprojects, it would probably be useful to support ... as glob * of the subproject id.

$ sbt query compilerBridge...
compilerBridge2_10
compilerBridge2_11
compilerBridge2_12
compilerBridge2_13

?scala=3, ?scala=2.x, ?scala=2.13

Scala version filtering would be useful to have.
? denotes query pairs. scala as query would be used to query against scalaVersion setting of the subproject, but with special version handling.
3 would be interpreted as 3.x, which means any Scala version with first segment 3, including pre-releases.
2.13 would be interpreted as 2.13.x would means any Scala version with second segment 2.13, including pre-releases.

$ sbt query compilerBridge...?scala=2.13
compilerBridge2_13

?platform=jvm, ?platform=js, ?platform=native

Another useful filtering might be platform cross building.

$ sbt query ...
scopt
scopt3
scopt2_12
scoptJS
scoptJS3
scoptJS2_12

$ sbt query ...?platform=js
scoptJS
scoptJS3
scoptJS2_12

Query as an aggregate

Once we have the ability to filter down the list of subprojects, we could then use that as the mechanism of aggregation.
For example:

$ sbt qtest ...?platform=js

could test all subprojects that is Scala.JS.

[er1c]

Does ... glob require us to use a separate test task (e.g. qtest) or is ... unique enough to be more "native"?

[eed3si9n]

Today, sbt test means "act" command interprets test to mean "test scoped to the root project", and uses aggregate list from the root project to broadcast test to the list in parallel.

If we adopt Bazel syntax, it would require <query> at the end of test as command like:

sbt test ...

This would break backward compatibility, and requires learning this new concept. If we created q-variant of commands like qtest and qcompile, then those knows about query could use it without disrupting the existing tasks.

[eed3si9n]

It might be tempting to treat the root-scopted keys as special case that would take <query> parameter automatically, but it would create ambiguity for input keys like:

sbt testOnly foo

The above could be interpreted both as run testOnly in foo subproject or run test class that matches foo in aggregated subprojects.

[adpi2]

@eed3si9n I am not sure to understand your previous comment. Could we use the following syntax? If not, can you clarify why?

$ sbt ...?platform=js / test
$ sbt ...?platform=js / testOnly foo

[eed3si9n]

Yea, I guess that might work.

[sideeffffect]

I have a few suggestions:

Use the binary suffix for platforms, so sjs* and native*.

Enable versioning the platform, so ?platform=sjs1.*, ?platform=sjs0.6.*, ?platform=native0.4.*, ?platform=native0.4.0-M2, etc. This will make it easy to potentially build for multiple versions of a given platform. Note that native0.4.* should coversany 0.4.* version, like 0.4.1 or 0.4.4, but not 0.4.0-M2 -- that should be covered only by native0.4.0-M2, because it's not guaranteed to be binary compatible with the 0.4.* series.

Use * as the one and only wildcard, it has precedent over x. Less ways to do the same thing is better everybody.