[bug] installing packages via `npm i -g` ignores shared-globals-dir

[sn0opy]

Describe the bug

I found a related issue for proto. Using proto directly does seem to work perfectly fine.

Steps to reproduce

This is my task for moon:

  setup-typescript-lsp:
    command: npm install -g typescript-language-server
    options:
      runInCI: false
      cache: false
      persistent: false

Here's a part of my toolchains.yml:

node:
  version: '22.18.0'
  packageManager: 'npm'
  npm:
    version: '11.7.0'
  addEnginesConstraint: true
  dedupeOnLockfileChange: false
  inferTasksFromScripts: false
  syncProjectWorkspaceDependencies: true

npm:
  version: '11.7.0'

pnpm:
  version: '10.30.3'

My project's local .prototools content:

[tools.node]
shared-globals-dir = true

[tools.pnpm]
shared-globals-dir = true

[tools.npm]
shared-globals-dir = true

Expected behavior

Running $HOME/.proto/shims/npm install -g typescript-language-serve actually installs the typescript lsp into ~/.proto/tools/node/globals/bin like expected. (I added the above lines to my $HOME/.prototools for testing purposes)

Executing npm via my task doesn't install it "globally" but uses the versioned path ~/.proto/tools/node/22.18.0/bin instead.

Environment

  System:
    OS: macOS 26.3.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 778.52 MB / 32.00 GB
    Shell: 5.9 - /run/current-system/sw/bin/zsh
  Binaries:
    Node: 22.18.0 - /Users/sascha/.proto/tools/node/22.18.0/bin/node
    npm: 10.9.3 - /Users/sascha/.proto/tools/node/22.18.0/bin/npm
    pnpm: 10.30.3 - /Users/sascha/.proto/tools/node/22.18.0/bin/pnpm
  Managers:
    Homebrew: 5.0.12 - /opt/homebrew/bin/brew
    pip3: 26.0 - /opt/homebrew/bin/pip3
    RubyGems: 3.0.3.1 - /usr/bin/gem
  Utilities:
    Make: 3.81 - /usr/bin/make
    GCC: 17.0.0 - /usr/bin/gcc
    Git: 2.50.1 - /usr/bin/git
    Clang: 17.0.0 - /usr/bin/clang
    FFmpeg: 8.1 - /opt/homebrew/bin/ffmpeg
    Curl: 8.7.1 - /usr/bin/curl
    OpenSSL: 3.6.1 - /opt/homebrew/bin/openssl
  Virtualization:
    Docker: 28.5.2 - /etc/profiles/per-user/sascha/bin/docker
    Docker Compose: 2.39.2 - /usr/local/bin/docker-compose
  Languages:
    Bash: 5.3.3 - /run/current-system/sw/bin/bash
    Go: 1.26.1 - /opt/homebrew/bin/go
    Java: 25.0.2 - /usr/bin/javac
    Perl: 5.34.1 - /usr/bin/perl
    Python: 3.13.0 - /Users/sascha/.proto/shims/python
    Python3: 3.14.3 - /opt/homebrew/bin/python3
    Ruby: 2.6.10 - /usr/bin/ruby
  Databases:
    SQLite: 3.51.0 - /usr/bin/sqlite3

Additional context

Logs for moon run --log debug are attached

issue.log

[sn0opy]

One thing that caught my eye was the code to locate a global directory. Even though the logs say it could find global directories to use, it still ignores them. I had a quick look at the code hoping to find something. Why is there a check for actual files in these directories? found_dir stays None if there aren't any files in these folders already.

The attached logs will say "Found a usable globals directory" because I manually executed npm i -g beforehand. If I uninstall it, moon's debug logs will show "No usable globals directory found, falling back to the last entry" instead.

[milesj]

@sn0opy Is that .prototools file in the root? moon only respects that one and none at other locations.

Why is there a check for actual files in these directories?

Because that function is to find a valid dir amongst a list of possible dirs. moon doesn't use that function, we utilize all the global dirs.

However, this shared dir isn't on by default, so most likely isn't being inherited by moon.

[sn0opy]

@sn0opy Is that .prototools file in the root? moon only respects that one and none at other locations.

I have a .prototools at the root level of my project. It's the same location where I executed the task from. The .prototools in my $HOME was just for testing purposes because I knew that proto itself will pick it up. The file in my $HOME and in my project's root have the same content. So it doesn't really matter which one moon picks up.