RFC: New command names (and alias the old ones)

[arcanis]

I think the current command names are at odds with what most people would expect. What do you think about rewording them to be closer from what package managers' interfaces look like? The old commands would still work, but wouldn't be displayed in --help (or perhaps marked as deprecated in the documentation).

• corepack prepare [email protected] -> corepack install -g [email protected]

• corepack prepare [email protected] --activate -> corepack use -g [email protected]

• corepack hydrate path/to/archive.gz -> corepack install -g path/to/archive.gz

• corepack hydrate path/to/archive.gz --activate -> corepack use -g path/to/archive.gz

• corepack prepare -o ... -> corepack pack -g

Along with new commands:

• corepack use [email protected] -> Add the packageManager field to the package.json file
• corepack remove -g foo -> Removes all versions from foo from the cache
• corepack up foo -> Download the latest version from the registry and automatically use it
• corepack info foo -> List all versions currently in the cache (and the latest one from the remote)

[ljharb]

corepack remove foo suggests uninstall to me; any reason not to nest all cache commands under corepack cache? eg corepack cache remove foo

[arcanis]

I forgot to add the -g flag to remove, would that clarifies the intent? You may notice I also listed it as mandatory flag to corepack install to convey that it mutates the system, not the project. A command namespace like cache would be a possible alternative, but I'm worried most users would have troubles remembering it vs -g, which is very well known.

[updated the OP from corepack remove -> corepack remove -g]

[ljharb]

that still suggests a global uninstall to me, because there's more than one bucket of things that are mutated in the system - the global installs, the cache, config, and corepack itself, to name a few.

[styfle]

corepack use [email protected] -> Add the packageManager field to the package.json file

I would prefer corepack add [email protected] to add/update the packageManager field in package.json

[arcanis]

I would prefer corepack add [email protected] to add/update the packageManager field in package.json

I don't have a strong opinion on this; fwiw I used corepack use since adding a package manager would also remove one, which is different from package managers where adding a dependency doesn't mutate the others.

that still suggests a global uninstall to me, because there's more than one bucket of things that are mutated in the system - the global installs, the cache, config, and corepack itself, to name a few.

Fair enough - corepack cache clean foo then? Both npm and Yarn implement it (not pnpm though).

[ljharb]

Makes sense to me.

[styfle]

adding a package manager would also remove one, which is different from package managers where adding a dependency doesn't mutate the others.

It mutates for me. If I do pnpm add typescript@4 it installs version 4. Then if I run pnpm add typescript@5, it upgrades from version 4 to version 5.

That being said, I think your original use proposal is better because it works nicely with the -g option to mean global machine vs omitting to mean local project. Its also is familiar to those using nvm or fnm. You convinced me, use is better 😇

[rotu]

These need to be compatible both ways. Right now, corepack use shows an error message on corepack 0.18.0.

It's fine to introduce new commands or new aliases for old commands, but for new commands to be useful, there needs to be a low-friction path to start using them.

I'm thinking one (or both of):

• corepack enable should do a self-update of corepack
• unrecognized commands should show some help text about how to update corepack

[aduh95]

Fixed by #291

[wyckster]

Does use also install? Can anyone confirm that where I was previously using corepack prepare yarn@stable --activate I should now be using just the single command: corepack use -g yarn@stable?

Or will it be required to do it in two commands: first corepack install -g yarn@stable and then corepack use -g yarn@stable in a separate command?