Symptom
A user can end up with the same @davstack/* global package installed by multiple package managers simultaneously, with PATH order silently deciding which one wins. Today's footgun, seen on Windows:
```
~/AppData/Roaming/npm/node_modules/@davstack/open-agents@1.0.0 (npm-global, stale)
~/AppData/Local/pnpm/global/.../@davstack/open-agents@1.1.0 (pnpm-global, fresh)
```
pnpm-global won on PATH so explore resolved to 1.1.0 — but any of: a Node-installer PATH reorder, a setx from another tool, a Windows update — could flip the order and silently downgrade the user to the stale copy (which on Windows means hitting the tsx-loader boot bug fixed in PR #34).
Root cause
packages/init/src/index.ts line ~57-91 picks the install command from detectPackageManager(repo.root), which reads the closest lockfile. So:
- run init in an npm repo →
npm install -g @davstack/<tool>
- run init in a pnpm repo →
pnpm add -g @davstack/<tool>
The two installers don't see each other's globals. Over time, bootstrapping different repos accretes duplicates.
Proposed fix
Before running the global install, check whether the tool is already installed somewhere on PATH (likely just which <bin> / command -v / Windows where, then walking back to a package.json). If yes:
- If the existing install is the same major: refresh it through its own manager (e.g.
pnpm add -g if it lives under pnpm-global), regardless of the detected repo's pm.
- If different: warn and ask whether to migrate or leave alone.
Either way, never create a parallel install in a different pm's global dir without asking.
Why low priority
- The PATH-order flip is theoretical until it happens.
- Cleanup is a one-liner once the user notices (
npm uninstall -g @davstack/<tool>).
- The user-visible bug only re-emerges if PATH flips AND the shadowed copy is on a broken version (currently true for the pre-PR-34 raw-
.ts versions; will be moot once those age out).
So: nice cleanup, not urgent. File now so it isn't forgotten.
Workaround for users today
If you have both npm-global and pnpm-global installed, pick one, uninstall from the other. Spot-check with where explore (Windows) / which -a explore (Unix) — should return exactly one path.
Symptom
A user can end up with the same
@davstack/*global package installed by multiple package managers simultaneously, with PATH order silently deciding which one wins. Today's footgun, seen on Windows:```
~/AppData/Roaming/npm/node_modules/@davstack/open-agents@1.0.0 (npm-global, stale)
~/AppData/Local/pnpm/global/.../@davstack/open-agents@1.1.0 (pnpm-global, fresh)
```
pnpm-global won on PATH so
exploreresolved to 1.1.0 — but any of: a Node-installer PATH reorder, asetxfrom another tool, a Windows update — could flip the order and silently downgrade the user to the stale copy (which on Windows means hitting the tsx-loader boot bug fixed in PR #34).Root cause
packages/init/src/index.tsline ~57-91 picks the install command fromdetectPackageManager(repo.root), which reads the closest lockfile. So:npm install -g @davstack/<tool>pnpm add -g @davstack/<tool>The two installers don't see each other's globals. Over time, bootstrapping different repos accretes duplicates.
Proposed fix
Before running the global install, check whether the tool is already installed somewhere on PATH (likely just
which <bin>/command -v/ Windowswhere, then walking back to apackage.json). If yes:pnpm add -gif it lives under pnpm-global), regardless of the detected repo's pm.Either way, never create a parallel install in a different pm's global dir without asking.
Why low priority
npm uninstall -g @davstack/<tool>)..tsversions; will be moot once those age out).So: nice cleanup, not urgent. File now so it isn't forgotten.
Workaround for users today
If you have both npm-global and pnpm-global installed, pick one, uninstall from the other. Spot-check with
where explore(Windows) /which -a explore(Unix) — should return exactly one path.