3 ms·

I tend to work on different projects in different terminal sessions so I don't find this a problem, but OK, I can see the benefit of making the tasks a command

I tend to work on different projects in different terminal sessions so I don't find this a problem, but OK, I can see the benefit of making the tasks a command line executes dependent on the current directory. (There are tools that can auto-adjust $PATH for you like this, but that would be a weak argument against Just (unless you're using them already) since it would mean swapping Just for that-other-tool.) If you use git and don't need multiple "layers" of Justfiles (i.e., if you have all your scripts in a scripts folder at the top level of your repo), then in bash you can get what you want with: run(){ `git rev-parse --show-toplevel`/scripts/$*; } Now from any repo subdir, `run clean` will run a script named "clean" in the scripts folder at the top level.

BeetleB 2y ago
Although I'm coming off as a strong just evangelist, I do want to point out that if someone already has a workflow with just scripts, it's totally OK to continue with that. Personally, I think using just is simpler for those who already don't have that workflow. Likewise, if you are using make as a command runner and already know make well enough - by all means continue! In my experience, though, someone who doesn't know make will be much more likely to learn just than make. I tend to sneak justfiles into the projects I work on. They usually don't have any good automation (no make, perhaps some scripts with a doc/md file explaining which script is for what). I sneak the justfile in the repository, and when it's mature, start showing teammates how I use it. They typically then switch to it. I don't think they would switch to it if it were a Makefile.