I haven’t embraced scala-cli yet - mostly because my hobby code tends to break down into a minimalist core library and supporting extensions and demos. Further, they often have to have some custom step for deploying as part of the build.
sbt hasn’t been a great fit - too many neurons remembering all the strangeness. Mill has been an OK fit, with fewer caveats (Lee Haoyi’s opinions - consistent but another thing beyond beginner scala code) but not all-together satisfying.
scala-cli looks like it could be a great fit for those custom bits, but subproject support is a must-have feature.
Even though there’s no built-in support it’s not that hard to make it work, thanks to great composability. One example of that is Besom build combining just with scala-cli to have a support multiple projects. @lbialy might give more insight about it.
I’ve also had some kind of multi project related to Scala Native Lambda Handlers, but there I’ve used make, (mostly due to AWS SAM constraints, but hey, it worked) GitHub - WojciechMazur/ScalaNative-SAM-examples
I think we should leave Scala-cli as it is, let’s not mess it up.
Once we open the door, people will ask for even more features.
(Dislike of existing tools is a very strong motivator!)
I’ve fully embraced it and it’s great.
It keeps me away from needless complexity.
Whatever it’s “lacking” in subprojects / deployment etc.
I can work around with scripting, or the “pseudo make-file” approach.
Most of the time I discover that those are not really needed / can be done more simply, with small compromises.
I change myself and my habits to stay small instead.
If you need more, go with SBT or Mill, both great.
Creators of Scala-cli made a very good decision: “not a build tool”,
to fill a big gap that other tools didn’t.
Just leave Scala-cli alone please! from a sincere fan.
Scala Compose isn’t being actively worked on. Although its prototype it did show that subproject support didn’t take require much of a change to Scala CLI internals.