From a user perspective, if you’re someone just looking for a “how to” with bullet points, Clj + alias and Lein might end up being an equal user experience. But I wanted to get to the more fundamental underpinning, that none of those additional build tools you’d alias are a plugin to Clj, and neither do they have anything related to it. Each one is just another tool that you need to learn, which might have its own configuration, command line arguments, etc., unrelated to that of Clj. Clj is just one way for you to download the tool and run it. You could assemble them all through Lein as well, or manually through any other means they’d offer themselves to be downloaded and run.
I like that model, I like it a lot! It is very similar to the Linux command line, you just have programs and you can pipe their input/output together. They don’t always play nice, but if you have an assortment of them that have some convention, they could. The big advantage is that none of them are coupled to Clj. The downside is there isn’t a lot of enforcement in how they should behave and interact, though hopefully that develops organically through conventions.
The biggest missing part, is there isn’t currently a way to orchestrate a build with Clj. So you need to write a script for your OS. Maybe bash, or joker, etc. Say you want to compile -> test -> uberjar. There could be another tool built that you could alias that provides this, but again, all that isn’t really related to Clj.
On that note, I think it would be nice if Clj could add the following features:
- A way to list the available main aliases.
- A way to add a doc-string to aliases (which would be displayed along when listing the available main aliases).
Would be cool if it could also maybe support some form of concept on man page, where inside deps.edn you could define a man, and Clj could show you the man for your main aliases.