sbt VS Mill

After spending one day or two reading documents and many frustrated attempts to fix the issue, I ended up arriving at this Github - Spurious recompilation in multi-project build This was not the fix itself, however, gave me light by the end of the tunnel to understand the problem was indeed with the multi project setup.

NOTE: I won’t mention SBT and Leiningen here because, with all due respect, they are niche build tools. I also won’t discuss Kobalt for the same reason (besides, it’s no longer actively maintained). Additionally, I won’t touch upon Bazel and Buck in this context, mainly because I’m not very familiar with them. If you have insights or comments about these tools, please feel free to share them in the comments 👇

Sbt has the primitives that would allow that, but this would change the semantics of the test task. See also testQuick and https://github.com/sbt/sbt/issues/6292

If I use IntelliJ then apparently sbtn is not supported and they don't bother with Scala-CLI or Coursier.

Version 1.3.13 has a size of 1.17 MB in zip

See scala-xml 2.x mega tracker on plugin ecosystem conflicts.

This is under discussion at https://github.com/sbt/sbt/issues/6997

See https://github.com/playframework/playframework/issues/10572 and https://github.com/sbt/sbt/issues/6235 for more details and context.

BTW, if you're curious, it appears OP is using this: https://github.com/sbt/sbt/releases/tag/v1.6.2 Pretty sure one of the executables is doing ANSI colours.

If you see the progression of documentation changes over the years pushing people towards multi-project style, and issues like https://github.com/sbt/sbt/issues/6217, hopefully you'd see that I've really tried to encourage people to use multi-project style from the get go.

This might be a bit of a shameless plug, but because you ask :)

Regarding no sbt, I would highly recommend to have a look at the mill build tool https://mill-build.org. I personally find it very pleasant to use as a replacement for sbt, mostly because of the following points:

- it uses regular Scala code to define a build

In most build tools, caching is opt in, so most things dont get cached and instead are wastefully recomputed. In Bazel caching is the default so everything is cached. Even tests are cached so if you run a test twice on the same code, the second time it is skipped

- Dependency bazed test selection: You can use bazel query to determine the possible targets and tests affected by a code change, allowing you to trivially set up CI to only run tests downstream of a PR diff and skip unrelated ones

- Automatic sandboxing of your build steps in CGroup/NS containers, to ensure your build steps do not make use of un-declared files.

- At my last job we extended these cgroups to limit CPU/Memory usage as well, which eliminates the noisy neigjbour problem and ensures a build step or test gets the same compute footprint whether run alone during development or in parallel on a CI worker

- Built in support for seamless shared caches (e.g. I compile something on my laptop, you download it to your laptop for usage)

- Built in support for shared compute clusters (e.g. I compile stuff and it automatically happens in the cloud on 96 core machines)

- Support for deep integration between multiple languages (e.g. building a Go binary and Rust libeary which are both used in a Python binary, which is then tested using a Bash script)

If you never hit these needs, you don't need Bazel. If you do hit these needs, most other build tools simply do not cut it. We're trying to support some of these use cases and provide an alternative in https://mill-build.org, but Bazel really is a high bar to reach in terms of features that support latge monorepos

Starlark is definitely a mixed experience IMO.

On one hand, having a "hermetic" subset of Python is nice. You can be sure your starlark codebase isn't going to be making network calls or reading files or shelling out to subprocesses and all that. The fact that it is hermetic does help make things reproducible and deterministic, and enables paralleization and caching and other things

On the other hand, a large Starlark codebase is a large Python codebase, and large Python codebases are imperative, untyped, and can get messy even without all the things mentioned above. Even though your Starlark is pure and deterministic, it still easily ends up a rats nest of sphagetti.

For https://mill-build.org we went the opposite route: not enforcing purity, but using a language with strong types and a strong functional bent to it. So far it's been working out OK, but it remains to be seen how well it scales to ever larger and more complex build setups

Author here. Unfortunately this is because my own experience with Gradle is not up to date; I've only lived in the Gradle Groovy world! If anyone is interested in helping out, I have a 1500USD bounty on porting a gradle.kts build to Mill, so we can do a fair up-to-date comparison https://github.com/com-lihaoyi/mill/issues/3670

https://mill-build.org/ you'll need to know some Scala

I had filed a GitHub ticket, but it was closed as "out of scope". I'm not sure why the maintainers insisted on perpetuating the ambiguity, and would like to know your opinion about the following. None of the references above answer these very basic and very important questions.

It was my case, but https://github.com/com-lihaoyi/mill made my life easier

sbt (lowercase) has improved a lot, but Mill is a serious alternative today.

Akka HTTP, Cats, Quill, ninny, Monix Observable, mill.