Yarn completions out of date

[eproxus]

trafficstars

$ fish --version
fish, version 3.5.1
$ echo $version
3.5.1

The autocompletion for yarn bundled with Fish is very out of date. It seem to be for Yarn 1 and Yarn is now at version 3 (3.3.0). Unfortunately the auto completion is used by default and creates problems when using it:

$ yarn --version
3.3.0
$ yarn up<tab>
upgrade                            (Upgrade packages)
upgrade-interactive  (Upgrade packages interactively)
$ yarn upgrade
yarn upgrade
Usage Error: Couldn't find a script named "upgrade".

\$ yarn run [--inspect] [--inspect-brk] [-T,--top-level] [-B,--binaries-only] <scriptName> ...
$ yarn up # Actual command 
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: └ Completed
➤ YN0000: Done in 0s 190ms

Until this autocompletion is updated, I think it would be wise to disable it. Wrong completion is worse than no completion at all.

[faho]

Patches welcome.

Until this autocompletion is updated, I think it would be wise to disable it. Wrong completion is worse than no completion at all.

Completions are always a best-effort thing, and having a wrong subcommand or two isn't usually a big issue. The worst that happens in practice is that you pick a wrong one and it'll error, but you can always just type it yourself.

Unfortunately yarn here chose to not just remove a bunch of subcommands but also to gratuitously rename "upgrade" to "up" (while "upgrade-interactive" remains). So we'll have to remove the removed commands (apparently "audit" no longer exists, for example) and rename "upgrade" to "up".

The documentation is here - all the subcommands are listed in the sidebar.

---

If you wish to disable the yarn completions for yourself, run touch ~/.config/fish/completions/yarn.fish.

[EmilyGraceSeville7cf]

Wrong completion is worse than no completion at all.

IMO, just in case it suggests some a wrong outcome. find completion had such problem in the past (I don't know whether it was fixed or not). If completion is just outdated it's not the worst situation. :) Can you provide more details on what is outdated exactly to help others to update it to speed up the update process? (I don't mandate you to do it, anyway.)

[eproxus]

@faho @EmilySeville7cfg I'll try to make a pass over the whole yarn namespace and contribute an updated completion PR for this. Stay tuned.

[mqudsi]

Note that there's a not-insignificant number of people that rejected the yarn 2.0 upgrade and have stuck to yarn 1.x because of the unnecessary churn, the break in npm compatibility, and a host of other reasons.

I would be against removing yarn 1.x completions and would prefer putting it behind a version gate.

[eproxus]

Is there a nice way to enable different completions for different versions of the same executable that doesn’t require querying the version at every completion attempt?

[faho]

Is there a nice way to enable different completions for different versions of the same executable that doesn’t require querying the version at every completion attempt?

If you do something like

set -l thing_version (thing --version | string split .)

if test "$thing_version[1]" -gt 2
    # completions for version 3 and above
    complete -c thing ...
else if test "$thing_version[1]" -eq 2 -a "$thing_version[2]" -ge 5
    # completions for >=2.5 (and < 3)
    complete -c thing ...
else
    # completions for < 2.5
end

that will query once, when the completions are loaded. So if you do

> thing foo<TAB>

> thing bar<TAB>

the first completion will query, and the second completion won't need to do it again.

But that's required, there is no way around that (e.g. picking a specific file on install time is not acceptable).

[eproxus]

Just wanted to let you know that I unfortunately didn't get any time to work on this. It's also slightly above my current Fish competence level, so I don't plan to make any new version of this completion as of now.