These are the most significant issues I have with SBT:
- In a large project with -30 modules, watching sources (eg.
~compile) even in just one of the modules often freezes for up to 20 seconds, doing nothing before responding to changes. Other tasks liketestOnlycan also suffer from this but usually with <10 sec of lag. - Sometimes an incremental build takes twice as long as a clean build. Hard to provide any info about when or why.
- Scopes of keys are a nightmare. They’re great when you know exactly what’s needed but when you don’t know which scope you need it’s a nightmare to discover; similarly configuring a setting with the wrong scope never yields any warnings or errors. You just have to patiently run through all the related tasks and see if it works. Using
inspecton tasks doesn’t help either because it’s usually 8 nodes away in the big task & setting DAG. - SBT doesn’t seem to care about UX. The UX is terrible across the board. When presenting compilation errors, it’s insanely hard to decipher huge blogs of monotonous text. SBT should use different colours for filename and line number at the very least. Even at the end it says “n errors” detected but if it’s ≤ 4 it says “four errors”, “three errors”. How ridiculous! This isn’t a damn novel. We aren’t reading all the output from top-to-bottom; we’re scanning for information we know is there. Now this is surely due to scalac not SBT but as far as I’m concerned SBT is the interactive tool here and it should be held accountable for it’s UI and UX; users new to Scala and SBT certainly aren’t going to bother with the distinction. Clippy is an SBT plugin that can be used to apply syntax highlighting to Scala snippets in compilation errors (still doesn’t colour filename and line numbers) but it’s 1) not enough, 2) should be part of SBT proper (or whichever SBT component does Scala compilation).
- From what I can see on the outside, the SBT team seems too cautious, moving so slowly and scared to break anything for anyone (cough cough Ivy). SBT isn’t solid enough or well designed enough to improve in a reasonable timeframe with tiny, safe changes (which is probably why CBT has surfaced and is gaining momentum). When you look at all the deficiencies and desired features and ask how long it will take to fix/add, at the current rate it will take another 5 years or more. Are people really going to stick around? A strong backwards compatibility story won’t be worth much if, for example, 80% of the community abandons the tool.
Also worth mentioning:
- It unclear how loose settings floating around in the
build.sbtDSL apply in a multi-module project. The whole DSL/Scala dichotomy really feels like a big mess. Why not just Scala? It’s just adding complexity and knowledge curve for no benefit as far as I can tell.
I’ve also good to say about SBT. It used to be hell 4, 5 years ago but these days, with all the improvements and simplifications that’ve been made over the years, it’s a really good tool. It’s trivial to add new modules to a project, to have interdependencies between them, using the .value macros it’s super simple now to customise builds and add task dependencies, it’s not a big deal to add custom commands or settings. I think SBT has a lot going for it and, while I really wish the rate of improvement was faster, I do appreciate the work that has been done to improve it from the monster it was years ago.