My team maintains multiple projects that are over 10 years old with a mix of Ruby on Rails and JavaScript. The code base is large, so there is pretty much a guarantee that going to the next version of Ruby or Ruby on Rails or Node will introduce problems. We lock down all the versions for everything so that we don't have to worry a deploying to a new environment (new server, developer, etc) will have different versions and require use to change priority to fix things. Instead, we periodically review our projects for upgrades, find upgrade issues and fix them, lock new versions, and deploy. Some of the code base is in legacy status. It does what it needs to do, and we have no need to change it unless some security issue is found.
There was a discussion about asdf before[1] with a blog post[2] about someone's shift to using asdf which may help, it's pretty straight to the point.
[1] https://news.ycombinator.com/item?id=30917354
[2] https://jinyuz.dev/2020/07/switching-from-pyenv-rbenv-goenv-...
This is often the case when the software you are writing is a web application that has one intended production deployment target, rather than a library or even a shrink-wrapped product that might need to work in diverse installations.
If you just have one of these projects, you can just install the dependency in user-space and update your user's startup files to point to it and be happy. But if you have two or more, or the version changes often (hopefully it does, so you can scoop up security and other updates), then a version manager helps with the toil of swapping back and forth.
Like many of its predecessors, asdf not only gives you a set of commands to swap these versions on demand, but it also creates "shims" to automate this swapping behavior when you enter and exit directories with an appropriate configuration file.
The "killer feature" of asdf (versus rbenv, pyenv, phpenv etc.) is that it is an extendable toolkit that gives you the same tools for dozens, maybe hundreds of different plugins contributed by the community. It is a polyglot web programmer's friend.
> Once asdf core is set up with your Shell configuration, plugins are installed to manage particular tools. When a tool is installed by a plugin, the executables that are installed have shims created for each of them. When you try and run one of these executables, the shim is run instead, allowing asdf to identify which version of the tool is set in .tool-versions and execute that version.
There is a hyperlink on word shims to the Wikipedia article https://en.wikipedia.org/wiki/Shim_(computing) that explains the generic concept of shims. Not helpful.Edit: here it is: https://github.com/asdf-vm/asdf/blob/v0.10.2/asdf.sh#L30-L31