Repository navigation
RFC: New command names (and alias the old ones) #274
Description
Activity
corepack remove foosuggests uninstall to me; any reason not to nest all cache commands undercorepack cache? egcorepack cache remove fooReacted by Bo LingenI forgot to add the
-gflag toremove, would that clarifies the intent? You may notice I also listed it as mandatory flag tocorepack installto convey that it mutates the system, not the project. A command namespace likecachewould 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]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.
corepack use foo@1.2.3 -> Add the packageManager field to the package.json file
I would prefer
corepack add foo@1.2.3to add/update thepackageManagerfield in package.jsonI would prefer
corepack add foo@1.2.3to add/update thepackageManagerfield in package.jsonI don't have a strong opinion on this; fwiw I used
corepack usesince 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 foothen? Both npm and Yarn implement it (not pnpm though).Reacted by Jordan Harband, Bo Lingen and hrmnyMakes sense to me.
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@4it installs version 4. Then if I runpnpm add typescript@5, it upgrades from version 4 to version 5.That being said, I think your original
useproposal is better because it works nicely with the-goption to mean global machine vs omitting to mean local project. Its also is familiar to those usingnvmorfnm. You convinced me,useis better 😇These need to be compatible both ways. Right now,
corepack useshows 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 enableshould do a self-update of corepack- unrecognized commands should show some help text about how to update corepack
Does
usealsoinstall? Can anyone confirm that where I was previously usingcorepack prepare yarn@stable --activateI 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@stableand thencorepack use -g yarn@stablein a separate command?Reacted by Jems and momesana
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 foo@1.2.3->corepack install -g foo@1.2.3corepack prepare foo@1.2.3 --activate->corepack use -g foo@1.2.3corepack hydrate path/to/archive.gz->corepack install -g path/to/archive.gzcorepack hydrate path/to/archive.gz --activate->corepack use -g path/to/archive.gzcorepack prepare -o ...->corepack pack -gAlong with new commands:
corepack use foo@1.2.3-> Add thepackageManagerfield to thepackage.jsonfilecorepack remove -g foo-> Removes all versions fromfoofrom the cachecorepack up foo-> Download the latest version from the registry and automatically use itcorepack info foo-> List all versions currently in the cache (and the latest one from the remote)