Feature Request: Add Dynamic Prefix Aliases

[wmartinmimi]

As of now, in order to use alias, you need to define them in the justfile.

alias b := build

In my opinion, one main use of alias is to provide a shorter way to invoke the same command.

Hence, I am wonder if just would want to support writing short forms without even being explicitly defined in the just file.

just build # original command
just b     # valid command
just bu    # also valid
just bui   # also valid
just buil  # also valid

In my opinion dynamic aliases should never appear on just --list, since it is not explicit and would completely clutter the output.

The format of alias would be [unique command prefix][any amount of the rest of the command (optional)], hence when there are 3 jobs "build", "check", "compile", the following will happen:

just b  # runs `just build`
just c  # produces an error, preferably outputting the 2 matched commands as part of a correction hint
just ch # runs `just check`
just co # runs `just compile`

In order to work with existing defined alias, I am thinking of treating alias as also valid commands, and preform exact matches before checking for dynamic prefix matches.

So for the following justfile:

alias test := check
alias c := challenge

challenge:
  # run authentication challenge step

check:
  # run check steps

The following will happen:

just c   # matches exact alias "c", runs challenge
just ch  # does not match any exact alias or tasks, output `non-unique error, see: challenge, check`
just che # does not match any exact alias or tasks, but matches first unique prefix for task: check, runs check
just t   # does not match any exact alias or tasks, but matches first unique prefix for alias: test, runs check

I think it would beneficial to include this as part of just, since short forms can be used without defining an explicit alias, and conflict in matching can be resolve quite clearly.

Thank you for making just!

[casey]

This has been requested before, but I've been hesitant to add it. See #388, from long long ago. A couple concerns from that issue are:

• For some recipes, a prefix wouldn't be the best alias. E.g., wt might be the most natural alias of wattage (not wa) or ta might be the most natural alias of test-all (not te).

• If you added a recipe, you might break dynamic aliases. I.e., if you had just test you could run it with t, but if you added test-all, the t alias would break. This might be especially annoying if multiple people use the justfile, and one user uses t (in this example) to call the test recipe, and another users adds a test-all recipe and breaks the other user's workflow.

But, I can definitely see how this would be useful, and not having to define a bunch of aliases would be nice.

Two thoughts:

• Are there any other tools that do this? I.e., any kind of tool which has a bunch of subcommands, where the set of subcommands isn't fixed (i.e., there are new ones, and which ones exist change) and you can call them by any exact prefix. I'd be really curious to hear from the maintainers and users of such a tool, and whether or not it was a good addition.

• If we did add this, we could consider adding it as an unstable feature, so that we can remove it if it doesn't work out. To be honest though, we've never used unstable features in this way, so I'm a bit hesitant to do so. Usually, unstable features are things we know we want, but aren't in an ideal form, or need more testing. This would be a feature that we're not sure we're going to keep, and might remove later.

Thank you for making just!

You are most welcome! 🙇‍♂️

[laniakea64]

Are there any other tools that do this? I.e., any kind of tool which has a bunch of subcommands, where the set of subcommands isn't fixed (i.e., there are new ones, and which ones exist change) and you can call them by any exact prefix.

Mercurial behaves this way, but not sure if the changes they make to available subcommands are less than what you have in mind?

[casey]

@laniakea64 Mercurial is a good example. I didn't know it worked that way. I think it is good data point. Can users add new mercurial commands? Either new subcommands or aliases, and how do they interact with this feature? (Like if hg a initial calls hg add, but you create an alias, hg annotate, will hg a not work any more?)

[laniakea64]

Can users add new mercurial commands?

Yes. This is done by adding [alias] section in ~/.hgrc. I haven't tried adding subcommands.

how do they interact with this feature?

Taking hg cat as the example:

If I run hg c ..., it errors with exit status 255 and this message:

hg: command 'c' is ambiguous:
    cat checkout clean clone commit config continue convert copy

If I run hg ca ..., it invokes the hg cat command.

Now adding a new command in ~/.hgrc:

[alias]
caution = !echo testing

... and hg ca now fails in the same type way as hg c failed above. Now these commands must be spelled at least hg cat and hg cau.

If the custom command is instead named catcat, then:

• hg cat still invokes the original hg cat command (and spelling it out fully is the only way to invoke it),
• invoking hg catcat requires at least typing hg catc.

[wmartinmimi]

• Are there any other tools that do this?

Unfortunately I am unable to provide any example, as I haven't used tools with this behavior like this before. The idea of my feature request mainly came from shell scripts with c* and up* wildcard argument parsing, which seems fragile but are very ergonomic for personal use.

Mercurial mentioned above does describe the behavior I want.

• To be honest though, we've never used unstable features in this way, so I'm a bit hesitant to do so.

Please do treat this feature request however you feel comfortable with, it is your project after all :>

[casey]

I think I'd be open to this, given that mercurial does it. It feels like there are lots of footguns, so we should probably make it unstable at first.