Node bumps silently orphan user-installed global npm packages (nvm per-version globals + floating default alias) #17

Open
opened 2026-06-24 07:23:02 +00:00 by GuillaumeHemmen · 0 comments

Summary

Each sindri image release bumps the bundled Node.js patch version. Because nvm (Node Version Manager) stores global npm packages per node version, and the default alias floats to the newest installed line, any package installed with npm i -g under the previous node version silently drops off PATH after an image update floating; resolves to the newest installed v24.x

What we observed

Three node versions accumulated in the persisted ~/.nvm, each appearing at a container boot:

node version dir created globals present
v24.16.0 2026-05-30 yarn, @mixedbread/mgrep
v24.17.0 2026-06-18 yarn
v24.18.0 2026-06-24 (active) yarn

yarn exists under every version (re-provisioned each time), but @mixedbread/mgrep is absent from v24.18.0's global node_modules. Its files still sit on disk under v24.16.0: orphaned, not deleted.

Concrete breakage: a tool's startup hook runs subprocess.Popen(["mgrep", "watch"]); with mgrep no longer on PATH it throws FileNotFoundError: [Errno 2] No such file or directory: 'mgrep' on every new session.

Root cause

  1. nvm keeps globals per node version (~/.nvm/versions/node/<version>/lib/node_modules), not in a shared store.
  2. The image bumps the node patch version on each release.
  3. default is the floating alias 24, so the active node auto-jumps to the new patch zero user action, fixes it for every consumer.

Consumer-side workaround (today)

npm i -g <pkg> reinstalls into the now-active node version, but must be re-run after each node bump unless added to a per-boot bootstrap script.

## Summary Each sindri image release bumps the bundled Node.js patch version. Because nvm (Node Version Manager) stores global npm packages **per node version**, and the `default` alias floats to the newest installed line, any package installed with `npm i -g` under the previous node version silently drops off `PATH` after an image update floating; resolves to the newest installed v24.x ## What we observed Three node versions accumulated in the persisted `~/.nvm`, each appearing at a container boot: | node version | dir created | globals present | |--------------|----------------------|--------------------------| | v24.16.0 | 2026-05-30 | yarn, @mixedbread/mgrep | | v24.17.0 | 2026-06-18 | yarn | | v24.18.0 | 2026-06-24 (active) | yarn | `yarn` exists under every version (re-provisioned each time), but `@mixedbread/mgrep` is **absent** from v24.18.0's global `node_modules`. Its files still sit on disk under v24.16.0: orphaned, not deleted. Concrete breakage: a tool's startup hook runs `subprocess.Popen(["mgrep", "watch"])`; with `mgrep` no longer on `PATH` it throws `FileNotFoundError: [Errno 2] No such file or directory: 'mgrep'` on every new session. ## Root cause 1. nvm keeps globals **per node version** (`~/.nvm/versions/node/<version>/lib/node_modules`), not in a shared store. 2. The image bumps the node patch version on each release. 3. `default` is the floating alias `24`, so the active node auto-jumps to the new patch zero user action, fixes it for every consumer. ## Consumer-side workaround (today) `npm i -g <pkg>` reinstalls into the now-active node version, but must be re-run after each node bump unless added to a per-boot bootstrap script.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
actions/sindri#17
No description provided.