[Feature] Command aliases

• I’d be willing to implement this feature (contributing guide)
• This feature is important to have in this repository; a contrib plugin wouldn’t do

Describe the user story

As a user of yarn, there are some commands that I run very frequently. I would like to have concise aliases for those commands so I can execute them quickly without having to remember and/or type long commands

Describe the solution you’d like

Add alias configuration for aliases:

alias:
  - p: dlx @yarnpkg/pnpify --sdk
  - pv: dlx @yarnpkg/pnpify --sdk vscode

This configuration makes both yarn pv and yarn p vscode equivalent to yarn dlx @yarnpkg/pnpify --sdk vscode.

Running arbitrary shell commands (like git aliases prefixed by !) are out of scope due to security and complexity concerns.

Describe the drawbacks of your solution

A number of potentially confusing behavior:

• Due to how Clipanion command priority works, commands contributed by plugins (including built-in ones) have priority over aliases. I.e. One cannot alias yarn add to another command.
• If aliases have priority over scripts, then user may unknowingly execute an aliased command rather than a script they intended to run; and vice versa,

Describe alternatives you’ve considered

Separate plugin: Implementing alias as described as a plugin will conflict with the built-in “run” entry command. Alternatively, the plugin command can use a prefix like yarn - p to trigger the p alias. However this kind of defeats the purpose of aliases (at least for me).

Package scripts: Aliases can also be implemented by adding them as package scripts.

// package.json
{
  // ...
  "scripts": {
    "p": "yarn dlx @yarnpkg/pnpify"
  },
}

However, implementing aliases this way has a number of drawbacks:

• one must add all aliases they want to use (which may be many) to every project they work on
• one must manually keep global (non-project-specific) aliases in sync in all projects
• they must be made public (both in git commits and in the npm package)

On the other hand, configuring aliases in .yarnrc.yml means global aliases can be kept in the home configuration, which avoid all the problem above.

[arcanis]

Given that I merged async plugin initialization I’ll go ahead and close this issue, but feel free to keep discussing as needed 🙂

[arcanis]

However, the truth is that cost is incurred for every yarn invocation, even for yarn --version.

If it affects the boot time too much, such dependencies can be lazily initialized. Cf the Clipanion doc: https://mael.dev/clipanion/docs/tips#lazy-evaluation

I’ve also experimented a couple of years ago with a Babel plugin to make all these imports lazy by default, but iirc it made things slightly slower (https://github.com/arcanis/babel-plugin-lazy-import). We have also switched to ESBuild since then, so the plugin wouldn’t be usable out of the box anymore.

Side note, should the loaded Configuration be available to plugins during instantiation?

The configuration isn’t really available yet when the plugins are initialized, since the configuration is loaded based on what the plugins register as configuration settings. We could expose something very basic (like “the union of the raw yaml rc files”), but it’s unclear how useful it would prove in practice, and would be one more thing to maintain susceptible to its own edge cases.