bug: `npm install -g yarn` install location not going to ~/.asdf

[KieranP]

Describe the Bug

In short: When asdf is installed with homebrew, installing nodejs packages globally will send them to /opt/homebrew instead of ~/.asdf

I don't recall seeing this issue under 0.16.0 so I think it could be 0.17.0 related, but I just upgraded to 0.17.0 and updated nodejs plugin, installed newest node LTS version (22.15.1), but am unable to install yarn globally under ~/.asdf.

Trying to call yarn after installing it (npm install -g yarn) results in it getting installed in /opt/homebrew/bin. (I have other dependencies installed with homebrew that installed a system node/npm under homebrew, but asdf is first in my $PATH so it takes priority)

Steps to Reproduce

(with clean system, i.e. no ~/.asdf yet)

1. brew install asdf
2. asdf plugin add nodejs
3. asdf install nodejs 22.15.1
4. which npm => /Users/kieran/.asdf/shims/npm
5. which yarn => yarn not found
6. npm install -g yarn
7. ls -la ~/.asdf/shims/ (no yarn)
8. asdf reshim
9. ls -la ~/.asdf/shims/ (still no yarn)
10. which yarn => /opt/homebrew/bin/yarn
11. npm root -g => /opt/homebrew/lib/node_modules
12. npm list -g

/opt/homebrew/lib
├── corepack@0.32.0
├── npm@11.4.0
└── yarn@1.22.22

Expected Behaviour

Installing using the asdf installed npm should install global packages under ~/.asdf folder

Actual Behaviour

It's installing into /opt/homebrew because the asdf installed npm is picking up homebrew npmrc:

› ~/.asdf/shims/npm config ls
; "builtin" config from /opt/homebrew/lib/node_modules/npm/npmrc

prefix = "/opt/homebrew"

; node bin location = /Users/kieran/.asdf/installs/nodejs/22.15.1/bin/node
; node version = v22.15.1
; npm local prefix = /Users/kieran
; npm version = 11.4.0
; cwd = /Users/kieran
; HOME = /Users/kieran
; Run `npm config ls -l` to show all defaults.

Note the prefix pointing to /opt/homebrew even though I have called the asdf npm. The result is that asdf shims never contains yarn binary, and when running multiple version of nodejs with asdf, this means all global packages for different nodejs versions are installed to the some /opt/homebrew location

Environment

OS:
Darwin Kierans-MacBook-Pro.local 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:29 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6030 arm64

SHELL:
zsh 5.9 (arm64-apple-darwin24.0)

BASH VERSION:
3.2.57(1)-release

ASDF VERSION:
0.17.0 (revision unknown)

ASDF INTERNAL VARIABLES:
ASDF_DEFAULT_TOOL_VERSIONS_FILENAME=.tool-versions
ASDF_DATA_DIR=/Users/kieran/.asdf
ASDF_CONFIG_FILE=/Users/kieran/.asdfrc

ASDF INSTALLED PLUGINS:
nodejs    https://github.com/asdf-vm/asdf-nodejs.git
          fd2c7f94c4c71416047ca

[augustobmoura]

This feels like a problem with the brew distribution instead of a problem with the plugin or asdf core. Can you confirm that downgrading asdf to 0.16 solves the issue?

You can install a specific version of a plugin in brew by running:

brew install asdf@0.16.7

[sskim91]

@augustobmoura

hi
I have the same problem.
Is there any way to downgrade?

The command below does not work properly.

brew install asdf@0.16.7

Warning: No available formula with the name "asdf@0.16.7".
==> Searching for similarly named formulae and casks...
Error: No formulae or casks found for asdf@0.16.7.

[sskim91]

curl -L https://raw.githubusercontent.com/Homebrew/homebrew-core/1d665566d3b4d3a493667c45c8fdc68add50cd05/Formula/a/asdf.rb -o asdf.rb
brew unlink asdf
brew install --formula ./asdf.rb
brew pin asdf # optional, if you want to avoid upgrading again

ref: asdf-vm/asdf#1892 (comment)

• 0.16.7 Changed the commit ID.

[jackpinto]

I'm experiencing the same issue on Linux Fedora 42 — none of the packages listed in .default-npm-packages are installed when using asdf 0.17.

The issue is resolved when I downgrade to asdf 0.16.7.

[augustobmoura]

I will probably need more time to investigate this, I'm having a pretty busy month. @Stratus3D do you know anything that could cause this in asdf-core off the top of your head?

Meanwhile, if anyone wants to give this some investigation, it would be very welcome. I'm pretty sure distribution maintainers should already be giving a look at this

[gjoseph]

@augustobmoura i don't know if this'll help but on my end, I'm only seeing the problem with one of my 2 machines.
On the one where the problem is exhibited, i tracked it down to ~/.asdf/plugins/nodejs/shims/npm:
In resolve_canon_npm(), if i remove the use of search_npm_on_current_path, things work fine again.

I've only just noticed it works fine on my other machine, so I might have a look for differences there -- the one where it works is a vanilla Macbook Pro M4, the one where it fails is a vintage mac from.. 2012 iirc.. on Sequoia but using Opencore, which may explain some subtle differences about where things are installed. (e.g IIRC homebrew is on a different location on those 2 machines)

[steerio]

It has nothing to do with Homebrew specifically, it just calls whatever it finds in the PATH that's not the asdf installed version. It's clearly a bug in the plugin.

$ echo $PATH
/Users/steerio/.ghcup/bin:/Users/steerio/.local/bin:/Users/steerio/.asdf/shims:/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/Users/steerio/.cargo/bin

$ asdf which node
/Users/steerio/.asdf/installs/nodejs/24.1.0/bin/node

$ asdf which npm
/Users/steerio/.asdf/plugins/nodejs/shims/npm

$ which npm
/Users/steerio/.asdf/shims/npm

$ npm list -g
/opt/homebrew/lib
├── corepack@0.32.0
└── npm@11.3.0

$ .asdf/installs/nodejs/24.1.0/bin/npm list -g
/Users/steerio/.asdf/installs/nodejs/24.1.0/lib
├── corepack@0.32.0
└── npm@11.3.0

On my Linux box npm resolves differently, not to another shim but to the proper executable:

$ asdf which npm
/home/steerio/.asdf/installs/nodejs/24.1.0/bin/npm

[augustobmoura]

It has nothing to do with Homebrew specifically, it just calls whatever it finds in the PATH that's not the asdf installed version. It's clearly a bug in the plugin.

I'm not convinced that is a bug in the plugin, because it did work on versions prior to 0.17, and it did work on versions before the golang migration of asdf_core.

What I assume is happening is that the logic for changing PATH before calling shims changed, and now the order we expect from the PATH variable is reversed or messed up in some way. I need the time to investigate where this is coming from, but again, I'm very busy this next weeks. If someone else wants to check this, this is probably the direction I would head into the investigation.

[augustobmoura]

Can you check if this is fixed on the last version now? #426 should've solved it

[JosephKu]

@augustobmoura It works for me. Thank you!