5 ms·

We love just and are using it in all projects now. So great. Our typical justfile has around ~20 rules. Here is an example rule (and helper) to illustrate how w

We love just and are using it in all projects now. So great. Our typical justfile has around ~20 rules. Here is an example rule (and helper) to illustrate how we use it in ci: export PATH := justfile_directory() + "/node_modules/.bin:" + env_var('PATH') ci: @just banner yarn install yarn install @just banner tsc tsc --noEmit @just banner lint eslint src prettier --check src @just banner vitest vitest --run @just banner done! banner *ARGS: @printf '\e[42;37;1m[%s] %-72s \e[m\n' "$(date +%H:%M:%S)" "{{ARGS}}" This example is a bit contrived, more typically we would have a rule like "just lint" and you might call it from "just ci". One of the best features is that just always runs from the project root directory. Little things like that add up after you've spent years wrestling with bash scripts.

alsetmusic 2y ago
> Little things like that add up after you've spent years wrestling with bash scripts. Can you please explain what you mean here? I looked at the GitHub examples and wondered why this would be preferable to Bash aliases and functions. I must be missing something.
- ricardobeat 2y ago
  Bash has a thousand pitfalls, and as you accumulate layers of scripting they start compounding. Little things like “what the hell directory is this command actually running from”, parsing input parameters, quoting rules, exit statuses, pipelining, etc. Tools like just provide a very consistent and simple base to start with, and you can always still call a separate script, or drop directly into inline shell scripting.
  - brundolf 2y ago
    So it's not a fundamentally different use-case, it's just an admission that shell scripts suck at what they do?
    - pdimitar 2y ago
      Of course. Is that news to you? Not a snark, I am genuinely surprised, assuming that you asked seriously. I moved to ZSH some years ago but even that is not good enough. I thought of using Fish at one point but just said "frak this" and started writing Golang for anything that's more than 20-30 lines of bash/zsh scripting. Or requires their weird list / array syntaxes for iterating over stuff. Can't ever remember that with a gun to my head.
      - udev4096 2y ago
        Shell scripts can be used safely if you know how to. Have solid error handling, exit on error (set -e), write tests (BATS) and a few other things to make sure it doesn't break. You are not gonna get the same performance with just or whatever new tooling there is just to run commands on your system
        pdimitar 2y ago
        > Shell scripts can be used safely if you know how to That's the contention point though -- I learned and relearned shell scripting no less than 7 separate times and it always slips away because it's not something I practice every day. Ultimately I concluded it's not worth it because you mostly have to memorize super weird syntax and strange exceptions to rules. At one point I was just like "screw this" and went for Golang. > You are not gonna get the same performance with just or whatever new tooling there is just to run commands on your system That's very debatable, I'd bet my Go programs process various things either faster or with the same speed. But even if they are slower that's often not important because most scripts I ever wrote were throwaway. Those that stuck around I have polished and re-polished, including with the measures you enumerated.
        ricardobeat 2y ago
        > if you know how to That’s a big if. I worked on a shell based tool for a couple years and eventually accumulated the know-how and toolset to write reliable code; but nobody else could contribute as the learning curve was too great. I switched to Ruby for all new tools and never looked back. Performance is rarely a concern in this territory, and you can always offload heavy work to another process.
- 3eb7988a1663 2y ago
  For me, the niceties are in the built in functions[0]. Commands to manipulate paths(!!), get cpu counts, mess with environment variables, string processing, hashing, etc. All the gyrations a more sophisticated script is going to eventually require. Instead of having to hack on it in shell, you get cross-platform utilities which are not going to blow up because of something as wild as a space or quote mark. [0] https://just.systems/man/en/functions.html https://just.systems/man/en/functions.html
  - richie_adler 2y ago
    My favorite feature is the ability to decorate the recipe name with the OS and then write relevant code for each recipe that does the same in each OS.
  - alsetmusic 2y ago
    This best explains what I must be missing. Saying, “shell scripts are bad,” doesn’t tell me anything. Thanks for giving me a concept to explore. I’ll have another look with this in mind.
  - udev4096 2y ago
    Nah. This looks nothing more than a wrapper for bash scripts. I can easily write helper scripts which does exactly what you described above. I don't understand the need of using a whole different tooling when I can run scripts natively on my machine(s)
    - nightowl_games 2y ago
      Bash scripts need wrappers because they suck so hard. You can do it all in bash, yes, but it's very conceivable this "just" thing actually provides real value.
gcmeplz 2y ago
I love the look of `just` and have been meaning to try it out, but this feels like one of those examples where Make's dependency management shines—it lets you specify that many of these commands only need to run when particular files change: node_modules: package.json yarn.lock yarn install --pure-lockfile prettier: $(shell find src -type f -iname "\*.ts") prettier --check src ... ci: node_modules prettier eslint vitest And as time goes on, I always end up wanting to parallelize the commands that can be parallelized (citest, lint, eslint), so I'll turn `make ci` (or `just ci`) into its own little script.
stock_toaster 2y ago
The banner readability could be slightly improved using constants[1] (and prefixing with _ to hide it from list output). # print all available commands by default default: @just --list ci: @just _banner yarn install yarn install @just _banner tsc tsc --noEmit @just _banner lint eslint src prettier --check src @just _banner vitest vitest --run @just _banner done! _banner *ARGS: @printf '{{BOLD + WHITE + BG_GREEN}}[%s] %-72s{{NORMAL}}\n' "$(date +%H:%M:%S)" "{{ARGS}}" [1]: https://just.systems/man/en/constants.html https://just.systems/man/en/constants.html

alsetmusic 2y ago

> Little things like that add up after you've spent years wrestling with bash scripts. Can you please explain what you mean here? I looked at the GitHub examples and wondered why this would be preferable to Bash aliases and functions. I must be missing something.

ricardobeat 2y ago
Bash has a thousand pitfalls, and as you accumulate layers of scripting they start compounding. Little things like “what the hell directory is this command actually running from”, parsing input parameters, quoting rules, exit statuses, pipelining, etc. Tools like just provide a very consistent and simple base to start with, and you can always still call a separate script, or drop directly into inline shell scripting.
- brundolf 2y ago
  So it's not a fundamentally different use-case, it's just an admission that shell scripts suck at what they do?
  - pdimitar 2y ago
    Of course. Is that news to you? Not a snark, I am genuinely surprised, assuming that you asked seriously. I moved to ZSH some years ago but even that is not good enough. I thought of using Fish at one point but just said "frak this" and started writing Golang for anything that's more than 20-30 lines of bash/zsh scripting. Or requires their weird list / array syntaxes for iterating over stuff. Can't ever remember that with a gun to my head.
    - udev4096 2y ago
      Shell scripts can be used safely if you know how to. Have solid error handling, exit on error (set -e), write tests (BATS) and a few other things to make sure it doesn't break. You are not gonna get the same performance with just or whatever new tooling there is just to run commands on your system
      - pdimitar 2y ago
        > Shell scripts can be used safely if you know how to That's the contention point though -- I learned and relearned shell scripting no less than 7 separate times and it always slips away because it's not something I practice every day. Ultimately I concluded it's not worth it because you mostly have to memorize super weird syntax and strange exceptions to rules. At one point I was just like "screw this" and went for Golang. > You are not gonna get the same performance with just or whatever new tooling there is just to run commands on your system That's very debatable, I'd bet my Go programs process various things either faster or with the same speed. But even if they are slower that's often not important because most scripts I ever wrote were throwaway. Those that stuck around I have polished and re-polished, including with the measures you enumerated.
      - ricardobeat 2y ago
        > if you know how to That’s a big if. I worked on a shell based tool for a couple years and eventually accumulated the know-how and toolset to write reliable code; but nobody else could contribute as the learning curve was too great. I switched to Ruby for all new tools and never looked back. Performance is rarely a concern in this territory, and you can always offload heavy work to another process.
3eb7988a1663 2y ago
For me, the niceties are in the built in functions[0]. Commands to manipulate paths(!!), get cpu counts, mess with environment variables, string processing, hashing, etc. All the gyrations a more sophisticated script is going to eventually require. Instead of having to hack on it in shell, you get cross-platform utilities which are not going to blow up because of something as wild as a space or quote mark. [0] https://just.systems/man/en/functions.html https://just.systems/man/en/functions.html
- richie_adler 2y ago
  My favorite feature is the ability to decorate the recipe name with the OS and then write relevant code for each recipe that does the same in each OS.
- alsetmusic 2y ago
  This best explains what I must be missing. Saying, “shell scripts are bad,” doesn’t tell me anything. Thanks for giving me a concept to explore. I’ll have another look with this in mind.
- udev4096 2y ago
  Nah. This looks nothing more than a wrapper for bash scripts. I can easily write helper scripts which does exactly what you described above. I don't understand the need of using a whole different tooling when I can run scripts natively on my machine(s)
  - nightowl_games 2y ago
    Bash scripts need wrappers because they suck so hard. You can do it all in bash, yes, but it's very conceivable this "just" thing actually provides real value.

gcmeplz 2y ago

I love the look of `just` and have been meaning to try it out, but this feels like one of those examples where Make's dependency management shines—it lets you specify that many of these commands only need to run when particular files change: node_modules: package.json yarn.lock yarn install --pure-lockfile prettier: $(shell find src -type f -iname "\*.ts") prettier --check src ... ci: node_modules prettier eslint vitest And as time goes on, I always end up wanting to parallelize the commands that can be parallelized (citest, lint, eslint), so I'll turn `make ci` (or `just ci`) into its own little script.

stock_toaster 2y ago

The banner readability could be slightly improved using constants[1] (and prefixing with _ to hide it from list output). # print all available commands by default default: @just --list ci: @just _banner yarn install yarn install @just _banner tsc tsc --noEmit @just _banner lint eslint src prettier --check src @just _banner vitest vitest --run @just _banner done! _banner *ARGS: @printf '{{BOLD + WHITE + BG_GREEN}}[%s] %-72s{{NORMAL}}\n' "$(date +%H:%M:%S)" "{{ARGS}}" [1]: https://just.systems/man/en/constants.html https://just.systems/man/en/constants.html