fix(pi): use wildcard peer ranges for pi-bundled packages

[bronislav]

What is the problem?

The pi package declares pi's bundled packages as versioned peers:

"peerDependencies": {
  "@earendil-works/pi-coding-agent": "^0.74.0",
  "typebox": "^1.1.24"
}

Bun auto-installs peer dependencies by default, so installing the pi package makes bun materialize a second, stale pi core inside the package directory. On my machine (pi 0.84.4, bun 1.3.14) pi update printed:

+ @earendil-works/pi-coding-agent@0.74.2 (v0.84.4 available)
+ typebox@1.3.25
111 packages installed

That is 193 MB in ~/.pi/agent/git/github.com/umputun/revdiff/node_modules — the full transitive tree, including the AWS/Google/OpenAI/Anthropic SDKs that pi core pulls in — plus a misleading "older version installed" line on every pi update, which is what sent me looking for the cause in the first place.

None of it is used. Pi's extension loader injects its own bundled copies of these modules (dist/core/extensions/loader.js):

import * as _bundledTypebox from "typebox";
...
  typebox: _bundledTypebox,
  "typebox/compile": _bundledTypeboxCompile,
  "typebox/value": _bundledTypeboxValue,

and pi's packaging docs say so explicitly (docs/packages.md):

Pi bundles core packages for extensions and skills. If you import any of these, list them in peerDependencies with a "*" range and do not bundle them: @earendil-works/pi-ai, @earendil-works/pi-agent-core, @earendil-works/pi-coding-agent, @earendil-works/pi-tui, typebox.

The pins also go stale by construction: they were set in #213 (2026-05-26), pi is now at 0.84.x, so the range needs a manual bump every pi minor purely to keep the number from being wrong.

How does this solve it?

It sets both peer ranges to "*", which is what pi's packaging docs prescribe for bundled peers. This fixes the root cause rather than the symptom — with "*" there is no stale pin to bump per release, and the peers still document the host requirement without asking the package manager to satisfy it.

Verified locally: after the change bun install in the package dir installs 0 packages and node_modules/ stays empty, while revdiff_review works unchanged — plugins/pi/extensions/revdiff.ts only does import type { ExtensionAPI, ExtensionContext } from @earendil-works/pi-coding-agent (erased at build) and gets Type from typebox via the loader injection above.

No functional or Go-side changes; package.json is the only file touched.

[umputun]

the diagnosis is right but the fix doesn't do what it says. "*" is still a satisfiable peer range, so it doesn't stop the auto-install, it only changes which version gets pulled.

pi has two install-arg builders in dist/core/package-manager.js. getNpmInstallArgs suppresses peers on every manager (--omit=peer for bun, --legacy-peer-deps for npm), but getGitDependencyInstallArgs returns a plain ["install", "--omit=dev"] with no peer suppression, and both installGit and updateGit call that one. The documented install is pi install https://github.com/umputun/revdiff, a git source, so the peers get installed whatever the range says.

measured here, resolution only, no installs:

peers	npm 11.19.0 --omit=dev	bun 1.3.9
^0.74.0 / ^1.1.24 (today)	119 pkgs, pi core 0.74.2	242
"*" / "*" (this PR)	167 pkgs, pi core 0.85.1	305
ranges unchanged + peerDependenciesMeta optional	1	0

so the PR grows the tree it exists to remove, and swaps the stale 0.74.2 core for the newest one plus a nested duplicate subtree. My own installed copy is 120 packages at pi core 0.74.2, which is the first row.

package.json:20-23 - the wildcard doesn't suppress the peer install and resolves to a newer, bigger pi core. Fix: keep the existing ranges and add peerDependenciesMeta with "optional": true for both peers.

  "peerDependencies": {
    "@earendil-works/pi-coding-agent": "^0.74.0",
    "typebox": "^1.1.24"
  },
  "peerDependenciesMeta": {
    "@earendil-works/pi-coding-agent": { "optional": true },
    "typebox": { "optional": true }
  },

pls leave the ranges alone. Whether ^0.74.0 should stay a ceiling that excludes pi 0.75+ is a separate question and mine to settle, the optional flag fixes the install either way.

the rest of your writeup holds up: pi's loader aliases both modules before any filesystem resolution (dist/core/extensions/loader.js), so neither peer is used at runtime, and docs/packages.md does prescribe "*". That advice only works on the registry install path where pi passes --omit=peer. I'll report the git-path gap upstream.

caveat on the numbers: npm 11.19.0 and bun 1.3.9 only, pnpm and a user-configured npm command are untested, and the git path drops even --omit=dev when npmCommand is set.