You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I do enjoy using volta now, but I'm facing some kind of inconvenience.
Actual behaviour
If VOLTA_FEATURE_PNPM is not set, then using pnpm via globally installed package or via corepack does not trigger installing new node version. since volta do not observe pnpm withot that env.
If I use VOLTA_FEATURE_PNPM, then volta use own pnpm instead of corepack (then packageManager field in package.json is unused)
If I use VOLTA_FEATURE_PNPM, then I can't use volta uninstall pnpm
THE MOST PROBLEMATIC -> if pinned version of node changes, volta installing new one, but do not change binded version for other packages (pnpm, corepack, I'll assume yarn too) if they are installed via volta install <package>.
Expected behaviour
If VOLTA_FEATURE_PNPM is not set and user have pnpm installed, trigger node instalation if workspace version is different than installed.
If VOLTA_FEATURE_PNPM is set, but pnpm is installed via corepack, take that binnary and use it, do not repeat installation
If VOLTA_FEATURE_PNPM is set and pnpm is managed my volta, allow to uninstall pnpm
If a new node version is beeing installed (because pinned version changed or user install new default node), swap tool binnaries to the respective node version
ex. Node was 20.12.0 and pnpm was 9.1.0, when I change Node to 20.13.0 the pnpm still use 20.12.0 and therefor installation script throws WARN/ERROR that engine is missmatched, because pnpm use old node.
100% better solution is to stop pinning package managers in a volta property in package.json and instead take packageManager field like corepack does.
Also this is a bit weird that you need to install corepack as a separate package, which is causing the same issue like with pnpm, that corepack using node version that was default when it was installed, but node itself contain corepack in the image, why does volta do not use it instead?
Is it possible to do some workaround or even fix this behaviours?
The text was updated successfully, but these errors were encountered:
Thanks for filing this – I will try to give it a careful read and make sure I see what the issue is sometime soon. To answer your final question:
Also this is a bit weird that you need to install corepack as a separate package, which is causing the same issue like with pnpm, that corepack using node version that was default when it was installed, but node itself contain corepack in the image, why does volta do not use it instead?
The answer here is that Volta existed for a good while before corepack! And we haven’t yet had a chance to implement support for it (see #987 for some background).
I do enjoy using volta now, but I'm facing some kind of inconvenience.
Actual behaviour
volta uninstall pnpm
volta install <package>
.Expected behaviour
ex. Node was 20.12.0 and pnpm was 9.1.0, when I change Node to 20.13.0 the pnpm still use 20.12.0 and therefor installation script throws WARN/ERROR that engine is missmatched, because pnpm use old node.
100% better solution is to stop pinning package managers in a volta property in package.json and instead take packageManager field like corepack does.
Also this is a bit weird that you need to install corepack as a separate package, which is causing the same issue like with pnpm, that corepack using node version that was default when it was installed, but node itself contain corepack in the image, why does volta do not use it instead?
Is it possible to do some workaround or even fix this behaviours?
The text was updated successfully, but these errors were encountered: