Closed aduh95 closed 6 months ago
Yes unfortunately it is likely some script out there relies on it. We could deprecate corepack enable
, freeze it to always mean corepack enable pnpm@latest yarn@1.x
(i.e don't add more package manager to it), and possibly make it emit a warning.
I expect the --all
flag is good to go, no?
I expect the --all flag is good to go, no?
The --all
flag was intended to help build base offline base images for cloud providers, which frequently want all tools to be included in their images. I don't have a strong opinion as to whether this is super useful or not, but I'd tend to refrain from removing it, to avoid unneeded friction.
Maybe @styfle would have an opinion there? I would expect cloud providers to be "picky" about which package managers they enable by default, as more and more package managers are added to Corepack, I would expect they want to activate only a subset.
I would expect they want to activate only a subset.
At Vercel, we only enable the package manager found in package.json.
I didn't know the --all
flag existed until now.
I think we need to look at more long term and see how this would impact the scenario when corepack enable
is no longer needed, presumably when it goes stable.
The old --all
functionality that updates pnpm and Yarn can be replicated with:
corepack prepare --activate pnpm yarn
The old
--all
functionality that updates pnpm and Yarn can be replicated with:corepack prepare --activate pnpm yarn
Why not using corepack install -g pnpm && corepack install -g yarn
? prepare
subcommand is confused and is not listed in corepack -h
.
Force users to opt-in into the package managers they want to support. As more and more package managers are added to Corepack, it's more and more unlikely that our users will be interested in all the package managers Corepack supports, and it is unreasonable to expect Corepack maintainers would be able to perform security audits.