this post definitely needs more exposure! I believe you've just helped me get my head around Volta. (:
I'm so accustomed to explicitly installing Node runtimes, that I completely missed it at first; Volta works because we don't explicitly tell it to install a version..
bear with me for a moment here, because it was while reading a specific section that I imagined a "typical workflow" using Volta, and it all just suddenly made perfect sense:
First, volta install, it does what it says on the tin. It installs a specific version of a tool globally e.g. volta install node@12. This becomes the default on your machine which is used as a fallback for any projects that don't specify a version.
Secondly, volta pin allows you to set a version of a tool for the current project e.g. volta pin node@14. This gets stored in the package.json and is shared between all developers.
Here's the cool part, Volta automatically switches your toolchain whenever you change directory 🤯
....and with that knowledge, I understand volta install is to be used sparingly! as per the documentation, "The volta install command will set your default version of a tool."
so in a nutshell:
volta install node to set your environment default runtime version
volta pin node to set a custom runtime for a specific project
with the engines version range check..
node/npm/npx away to your hearts' content..
hmm.. I really like this idea! oh well. \O.o/ I'll miss nvm.. might even still use it from time to time, a simple omz custom plugin does do auto version changing on directory navigation, but even with that convenience, each installed version has it's own list of "global packages"...
is npm a victim of it's own success then, due to it's infamous node_modules folder..?? (and all the things that depend on it, of course) lol. but I digress..
regardless, I believe the engines field in a project's package.json will work well enough to ensure non-Volta users don't get left in the cold.
so thank you again! this post was an awesome find.. (:
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
this post definitely needs more exposure! I believe you've just helped me get my head around Volta. (:
I'm so accustomed to explicitly installing Node runtimes, that I completely missed it at first; Volta works because we don't explicitly tell it to install a version..
bear with me for a moment here, because it was while reading a specific section that I imagined a "typical workflow" using Volta, and it all just suddenly made perfect sense:
....and with that knowledge, I understand
volta installis to be used sparingly! as per the documentation, "Thevolta installcommand will set your default version of a tool."so in a nutshell:
volta install nodeto set your environment default runtime versionvolta pin nodeto set a custom runtime for a specific projectenginesversion range check..node/npm/npxaway to your hearts' content..hmm.. I really like this idea! oh well.
\O.o/I'll missnvm.. might even still use it from time to time, a simpleomzcustom plugin does do auto version changing on directory navigation, but even with that convenience, each installed version has it's own list of "global packages"...is
npma victim of it's own success then, due to it's infamousnode_modulesfolder..?? (and all the things that depend on it, of course) lol. but I digress..regardless, I believe the
enginesfield in a project'spackage.jsonwill work well enough to ensure non-Volta users don't get left in the cold.so thank you again! this post was an awesome find.. (: