I am a big fan of Volta, and I believe it was quite revolutionary when it first appeared. I switched from NVM to it, and I never looked back. I always wished there were tools like Volta but for other things like Python and Java. To my happy surprise, tea is becoming it.
Maybe some other day I'll elaborate more on why I think tea is very similar to Volta.
There is a handy tool in Volta which is: volta pin node@18 npm@9, which calculates the full sharp version of node and npm matching the version constraint and writes it to the volta key in the package.json.
Writing the full version as opposed to writing just @18 to the package.json has advantages, like bringing reproducibility to CI/CD builds and colleagues environments. We can't deny things breaks sometimes even for packages adopting semantic versioning.
Nevertheless, it would be quite painful having to search the web for the latest node@18 and npm@9 every time I want to upgrade to latest patch or minor.
Maybe some command like tea pin node@18 could:
- Fetch the latest version of node@18
- Find where node's version was fetched from. Example:
$ cat .node-version
18.14.2
- Make the replacement automatically, i.e. change
.node-version from 18.14.2 to 18.17.0.
- If no file or source of the version was found, tea could create a
.tea.yml automatically to perform the pinning process on the current folder.
I am a big fan of Volta, and I believe it was quite revolutionary when it first appeared. I switched from NVM to it, and I never looked back. I always wished there were tools like Volta but for other things like Python and Java. To my happy surprise, tea is becoming it.
Maybe some other day I'll elaborate more on why I think tea is very similar to Volta.
There is a handy tool in Volta which is:
volta pin node@18 npm@9, which calculates the full sharp version of node and npm matching the version constraint and writes it to thevoltakey in thepackage.json.Writing the full version as opposed to writing just
@18to thepackage.jsonhas advantages, like bringing reproducibility to CI/CD builds and colleagues environments. We can't deny things breaks sometimes even for packages adopting semantic versioning.Nevertheless, it would be quite painful having to search the web for the latest node@18 and npm@9 every time I want to upgrade to latest patch or minor.
Maybe some command like
tea pin node@18could:.node-versionfrom18.14.2to18.17.0..tea.ymlautomatically to perform the pinning process on the current folder.