fix(build): strip the react-native tree from the published shrinkwrap

[heskew]

Removes the react-native tree from what harper publishes. Part 1 of #1937.## What and whyalasql declares optionalDependencies: { "react-native-fs": "^2.20.0" }, and react-native-fs peer-depends on react-native without marking it optional. npm 7+ auto-installs peer deps, so resolving alasql drags in react-native, react, hermes, metro and react-devtools-core — ~140MB, ~200 packages. None of it can execute: every require('react-native-fs') in alasql/dist/alasql.fs.js sits behind an isReactNative guard, and Harper only uses alasql.parse plus its function extensions. The published 5.1.23 shrinkwrap pins 794 packages, 64 of them react-native/hermes/metro.This runs alongside prune-shrinkwrap-dev.mjs, which already enforces the same invariant — the published shrinkwrap should describe only the production tree a consumer installs (#1783).## Where to look**build-tools/prune-shrinkwrap-react-native.mjs** is the whole change; the rest is a build step, a doc entry, and tests.The reachability logic is what deserves scrutiny. It computes the set of packages reachable from the root with the react-native-fs edge and without it, and deletes only the difference — so a package still reachable by any other path cannot be removed, and the removed set is derived rather than a hardcoded list of directory names that would silently rot as alasql's tree shifts. resolve() reimplements node_modules lookup (check <from>/node_modules/<name>, then each ancestor); that's the part most likely to be subtly wrong, though a mistake there fails safe — an unresolvable name simply means nothing gets marked reachable through it.On the current tree: 419 dev entries pruned, then 262 react-native entries, 1202 → 521. Zero unresolved required edges afterwards; the only new unresolved optional edge is alasql -> react-native-fs, the one being severed. (The published 5.1.23 shrinkwrap already carries 11 such unresolved optional/peer edges, so this is a pre-existing, normal pattern.)## Why not overridesnpm honours overrides only for the root project — an override in harper's package.json does nothing for anyone installing harper. The published shrinkwrap, by contrast, is authoritative for registry installs.I verified that rather than assuming it, because the premise matters and one plausible failure mode would have sunk it: npm could have re-resolved the pruned optional dependency and pulled the subtree back. Serving a package with a pruned shrinkwrap from a local static registry (so npm takes the real packument + _hasShrinkwrap code path, with the dependency still resolving from npmjs):shrinkwrap before prune: 331 entries, react-native present: yes shrinkwrap after prune: 23 entries, react-native present: no installed: 23 packages react-native tree in consumer tree: NO react-native-fs node: ABSENTConsequence: no stub package, no third-party empty module, and no change to package.json or the committed lockfile.## Scope — what this does not fix- The Docker image. npm install <tarball> has no packument, so npm never learns the shrinkwrap exists and resolves the tree fresh from package.json. Confirmed on the same published 5.1.23 artifact: installed via the registry it honours the pin (fastify 5.8.5), installed from the tarball it resolves fresh (fastify 5.10.0, latest) and the react-native tree returns. The image is therefore also not reproducible — two builds of one commit weeks apart can ship different trees. Follow-up PR, which builds on this one; it has to land after this, since honouring an unpruned shrinkwrap would pin the react-native tree in.

• Contributor / CI installs, which use package-lock.json and are unaffected. Deliberately left alone: fixing it means either a stub package or a cryptic override, and it costs disk rather than shipped bytes.
• The root cause. Worth reporting upstream to alasql (active repo, no existing issue found) — RN-only deps are normally lazy-required without being declared. When that lands, this script gets deleted; it reports "nothing to prune" rather than failing, so it degrades quietly.## TestingunitTests/buildTools/pruneShrinkwrapReactNative.test.js — 6 tests, the load-bearing one being that a package pulled in by react-native and depended on elsewhere survives. Note the sibling prune-shrinkwrap-dev.mjs has no tests; I added these because a wrong prune ships a broken shrinkwrap to every consumer.test:unit:main: 2795 passing, 2 failing — globalIsolation and a uWS 413 case. Both reproduce identically on pristine origin/main (12/1 and 6/1 in isolation), and this diff only touches build-tools/, unitTests/buildTools/ and dependencies.md.## DocsNo companion documentation PR: this changes no public API, config option, schema directive, CLI surface or user-visible default — it only removes dead weight from what gets published. The behavioural note for future work lives in DESIGN.md and dependencies.md.Closes Prune the react-native tree from the published shrinkwrap #1962

---

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces a build tool script prune-shrinkwrap-react-native.mjs along with its corresponding unit tests and documentation in dependencies.md. The script surgically prunes the react-native-fs dependency tree from the published npm-shrinkwrap.json to prevent transitive peer dependencies like react-native and react from being installed by consumers. There are no review comments, and I have no feedback to provide.

[claude]

Reviewed; no blockers found.