Aka... How NOT to design a build system.

I must say that the winning award in that category goes without any question to SBT.

SBT is like trying to use a claymore mine to put some nails in a wall. It most likely will work somehow, but the collateral damage is extensive.

If you ask what build tool would possibly do this... It was probably SBT. Rant applies in general, but my arch nemesis is definitely SBT.

Let's start with the simplest thing: The data format you use to store.

Well. Data format. So use sth that can represent data or settings. Do *not* use a programming language, as this can neither be parsed / modified without an foreign interface or using the programming language itself...

Which is painful as fuck for automatisation, scripting and thus CI/CD.

Most important regarding the data format - keep it simple and stupid, yet precise and clean. Do not try to e.g. implement complex types - pain without gain. Plain old objects / structs, arrays, primitive types, simple as that.

No (severely) nested types, no lazy evaluation, just keep it as simple as possible. Build tools are complex enough, no need to feed the nightmare.

Data formats *must* have btw a proper encoding, looking at you Mr. XML. It should be standardized, so no crazy mfucking shit eating dev gets the idea to use whatever encoding they like.

Workflows. You know, things like
- update dependency
- compile stuff
- test run
- ...

Keep. Them. Simple.
Especially regarding settings and multiprojects.

http://lihaoyi.com/post/...

If you want to know how to absolutely never ever do it.

Again - keep. it. simple.

Make stuff configurable, allow the CLI tool used for building to pass this configuration in / allow setting of env variables. As simple as that.

Allow project settings - e.g. like repositories - to be set globally vs project wide.

Not simple are those tools who have...
- more knobs than documentation
- more layers than a wedding cake
- inheritance / merging of settings :(
- CLI and ENV have different names.
- CLI and ENV use different quoting
...

Which brings me to the CLI.

If your build tool has no CLI, it sucks. It just sucks. No discussion. It sucks, hmkay?

If your build tool has a CLI, but...
- it uses undocumented exit codes
- requires absurd or non-quoting (e.g. cannot parse quoted string)
- has unconfigurable logging
- output doesn't allow parsing
- CLI cannot be used for automatisation

It sucks, too... Again, no discussion.

Last point: Plugins and versioning.

I love plugins. And versioning.

Plugins can be a good choice to extend stuff, to scratch some specific itches.

Plugins are NOT an excuse to say: hey, we don't integrate any features or offer plugins by ourselves, go implement your own plugins for that.
That's just absurd.
(precondition: feature makes sense, like e.g. listing dependencies, checking for updates, etc - stuff that most likely anyone wants)

Versioning. Well. Here goes number one award to Node with it's broken concept of just installing multiple versions for the fuck of it.
Another award goes to tools without a locking file.
Another award goes to tools who do not support version ranges.
Yet another award goes to tools who do not support private repositories / mirrors via global configuration - makes fun bombing public mirrors to check for new versions available and getting rate limited to death.

In case someone has read so far and wonders why this rant came to be...

I've implemented a sort of on premise bot for updating dependencies for multiple build tools.

Won't be open sourced, as it is company property - but let me tell ya... Pain and pain are two different things. That was beyond pain.

That was getting your skin peeled off while being set on fire pain.

-.-