FAQ

Here are some common questions regarding asdf.

WSL1 support?

WSL1 (Windows Subsystem for Linux 1) is not officially supported. Some aspects of asdf may not work properly. We do not intend to add official support for WSL1.

WSL2 support?

WSL2 (Windows Subsystem for Linux 2) should work using the setup & dependency instructions for you chosen WSL distro.

Importantly, WSL2 is only expected to work properly when the current working directory is a Unix drive and not a bound Windows drive.

We intend to run out test suite on WSL2 when host runner support is available on GitHub Actions, currently this does not appear to be the case.

Newly installed executable not running?

I just npm install -g yarn, but cannot execute yarn. What gives?

asdf uses shims to manage executables. Those installed by plugins have shims automatically created, whereas installing executables via an asdf managed tool will require you to notify asdf of the need to create shims. In this instance, to create a shim for Yarn. See the asdf reshim command docs.

Shell not detecting newly installed shims?

If asdf reshim is not resolving your issue, then it is most-likely due to the sourcing of asdf.sh or asdf.fish not being at the BOTTOM of your Shell config file (.bash_profile, .zshrc, config.fish etc). It needs to be sourced AFTER you have set your $PATH and AFTER you have sourced your framework (oh-my-zsh etc) if any.

Why can't I use a version of latest in the .tool-versions file?

asdf must always have an exact version of every tool in the current directory, not version ranges or special values like latest are not permitted. This ensure that asdf behaves in a deterministic and consistent way across time and across different machines. A special version like latest would change over time, and could vary between machines if asdf install was run at different times. As such it's allowed in asdf commands like asdf set <tool> latest, but forbidden in the .tool-versions file.

Think of .tool-versions file as Gemfile.lock or package-lock.json. It is a file that contains the exact version of every tool your project depends on.

Note that the system version is allowed in .tool-versions files, and it could resolve to different versions when used. It is a special value that effectively disables asdf for a particular tool in the given directory.

See issue https://github.com/asdf-vm/asdf/issues/1012

Why can't version ranges be used in the .tool-versions files?

Similar to the question above on the use of latest. With a version range specified, asdf would be free to choose any installed version in the specified range. This could result in different behavior across machines if they have different versions installed. The intent is for asdf to be fully deterministic so the same .tool-versions file produces the exact same environment across time and across different computers.

See issue https://github.com/asdf-vm/asdf-nodejs/issues/235#issuecomment-885809776

Why is a command completely unrelated to the plugins I'm using is getting shimmed by asdf?

asdf is only going to generate shims for executables it manages. If for example you use the Ruby plugin then you'll expect to see commands like ruby and irb replaced with shims, along with other executables present in Ruby packages you installed.

If you see a shim that you don't expect, it's likely because you installed a package under a tool that was managed by asdf, and the package provided the executable.

This is surprising when the executable has the same name as an executable already on your system. Some users reported a Node.JS package that provided it's own version of the which command. This resulted in asdf creating a shim for it, and it replacing the version of the which command present on the operating system. In such instances it's best to locate the package introducing the executable and remove it. asdf which <command> is helping in showing you where the offending executable is located, making it possible to determine what package added it.

See issues https://github.com/asdf-vm/asdf/issues/584 https://github.com/asdf-vm/asdf/issues/1653