Based on feedback on Slack I would like to propose the support for shorthand commands in tools.deps.
This would be something mirroring "aliases" in Leiningen and probably "scripts" in NPM. But not what is currently called "aliases" in tools.deps.
It should allow one to hide e.g.:
clj -X:graph graph :deps '"mydeps.edn"' :trace true :output '"trace"
Some examples of user facing commands with this in place:
clj start ; Similar to npm
clj run ; Inspired by lein run
clj backend ; Step 1 ..
clj frontend ; Step 2 ..
clj devcards ; Step 3 of firing up a fullstack project with some extras.
Exactly how it needs to work is something I'll leave to the implementors. If there has to be a reserved
start making it e.g.
clj run backend then that's the way it is, but the shorter the better. The term "shorthand command" is just I term i used to differentiate it from the already taken "aliases".
Personally i believe this little bit of sugar would clean it up nicely in several ways and I'll try to capture that in the following.
Some benefits of adding this:
- Aligns well with knowledge from using tools like Leiningen and NPM
- Everything in one deps.edn file.
- People and companies can have conventions that reuses the same shorthands across projects, making it dead simple to know how you fire up a project.
- Project documentation and guides could expose clean an concise commands.
I know tools.deps is not intended to replace Leiningen, but it seems to have fragmented the already small Clojure(script) community and intended or not, my impression is that it’s used as a replacement as is, with no other tool wrapping it. Sure, you can still use lein, but enough people seem to have transitioned that it’s pretty much mandatory to know both. There is also Boot and maybe others, but I perceive that userbase as much smaller.
I can cope and work around it, but whenever I write these long commands or document a project I feel that there has been some regression going on. Essentially I seem to work one abstraction level below of where I should be after the initial config of deps.edn is done.
Some ways to approch tools.deps commands as it is today:
- Write by hand: Certainly possible, but requires more knowledge, experience, a good memory, depending on how involved the setup is and how similar your projects are.
- Copy paste from e.g. README.md: Works ok, but you have to refer to docs and it kind of makes Clojure look more complicated than it needs to.
- Shell scripts: Adds more files to a project and spreads the information more than if deps.edn was self contained.
- Shell command history: Easily accessible during a coding session or when working on the same for days, but less accessible weeks and months later.
- Other tooling wrapping it.
So, I'm not arguing that the current situation is impossible to handle and Clojure seems to have an over the average tech savy userbase, but I think it could and should be cleaner. I can't really see how something clean and readable can hurt either. The current way of working feels a little bit elitistic as well, at least to me.
While making this improvement won't change fragmentation, unless in the unlikely event that it completely takes over for Leiningen, it will at least align the two more.
Maybe it should also support adding overrides after the shorthand (
clj backend -M:foo), execute more than one shorthand in the same command (
clj backend frontend) or similar, but that's something I don't have a strong opinion on right now.
I hope these rather personal opinions explains well enough why this could be worthwhile.
Lastly, imagine if, in the future, something like this was all the instructions you would have to give a Mac user to get started with some really nice fullstack work in Clojure(script):
brew install clojure
clj new re-frame/app my-app
This request is not about adding some elegant template functionality to tools.deps as well, it's just an illustration of what a very streamlined experience could look like. Going from zero to the very productive experience of Clojure(script) development in so few step would be great. Not that you would be an expert straight away, but you could start editing files and see see e.g. hot code reloading just work.