Use Task Runners for Common Coding Tasks

> A small drawback is that just isn’t readily available on developer’s machines (unlike bash and make)

Looking back, this was usually a substantial stumbling block for adoption of new tooling. Things have changed. All one has to do is look at what JS programmers will go through to scratch build entire toolchains on the back of npm. IMO, the bar has been moved up to allow _some_ installation friction rather than none.

IMO, if the tool is a solid improvement and installation is a one-liner, use it and promote it loudly so it continues to get support.

Also had this issue. I have made a meta-task runner to make discovery and running of already defined make/just/task/npm/etc task targets easier called dela[0].

The ergonomics of running tasks are very similar to the article as you can run a task simply by typing the name of the task in your shell without saying "make" or "npm run" or whatever else that is the actual task runner. The difference is that you just have to install dela without having to change anything in the underlying project repository.

Works really well for me!

[0] https://github.com/aleyan/dela

Historically, I did it the other way around: have some autogenerated shell commands (dev, test, pull...etc) on my local machine that detect which language the project in the current folder is using, and calls commands accordingly. I did it this way because, in my case, it was challenging to consolidate multiple projects across multiple organizations under a single tool.

It's public, but I realize I haven't pushed my local updates for a while now. https://github.com/Betree/dev-commander

I write a Python script for this stuff. argparse with subparsers makes (fairly) light work of creating a command line tool with git-/svn-/etc.-style subcommands, and you get very useful autogenerated --help output. (The fact you have to statically specify your program's command line interface up front is maybe a bit un-pythonic, but it's all the better for it.)

Python is always measurably more lines than the Makefile or shell script equivalent, but just think of the effect on your productivity metrics!

The standard shutil and subprocess modules are pretty convenient to use as-is. They're a bit syntactically tedious for anything that's a very basic sequence of shell operations, but in exchange you'll never forget to quote the arguments correctly. And I've always found that these processes to tend to grow over time anyway - something that's much easier to handle in Python! There's also far more scope for additional error checking and nicer UX.

I made a task runner inspired by make's simplicity but purpose-built for running tasks:

Run: Task runner that helps you easily manage and invoke small scripts and wrappers.

https://github.com/TekWizely/run

Do you find yourself using tools like make to manage non-build-related scripts?

Build tools are great, but they are not optimized for general script management.

Run aims to be better at managing small scripts and wrappers, while incorporating a familiar make-like syntax.

Let me also recommend babashka and it's task runner too!

If my tasks are simple enough, bash or make will do but for serious projects, specially lispy ones, babashka is amazing.

I use the shell script pattern. In bash the case statement at the bottom of your example can be replaced with this though:

  “${@:-default}” || usage

I've been using Taskfile. Are just / mise much better?

I do this with plain ol' makefiles.

Even for projects where Make isn't part of the build pipeline, like Rails or C++, I have a standardized makefile I put in the project root, using includes for "secrets.mk", so I can do things like "make deploy" and it Just Works(tm).

Sometimes the old ways are best!

I wish mise has better secrets management or allows for split config e.g. a repo wide config that's to be shared and a personal config that can override whatever's necessary. It's difficult to commit mise.toml because the [env] section almost always contains sensitive variables.