Carry install locations to the wire so an import can be tied to an instance

[patchstackdave]

The defect

The same package is routinely installed more than once at different versions — a workspace pinning an old copy, a transitive dependency getting a nested install. The manifest knew where each one lived (PackageEntry.path was parsed and populated). Then buildWirePayload projected every entry to {name, version} and the locations were dropped at the wire boundary, unread by anything in the package.

Measured on a workspace fixture:

MANIFEST                                              WIRE
lodash 4.17.21  node_modules/lodash              →    { name: "lodash", version: "4.17.21" }
lodash 4.17.11  apps/api/node_modules/lodash     →    { name: "lodash", version: "4.17.11" }

An advisory matching only the older one cannot be resolved against the app's code. The consumer either warns on a copy nothing reaches, or pins a rule to a route that runs the safe one — a rule that never fires while reporting as protection.

Node resolves an import by walking up from the importing file, so the map's import sites and these paths together answer "which instance does this import reach". Neither half answers it alone.

What changed

WirePackage.paths — the locations, sorted. The dedupe by name+version stays, but the duplicate entries it dropped were the only record of the other locations (one copy at the root, one pinned inside a workspace is exactly the case that needs distinguishing), so their paths are collected onto the surviving entry instead of discarded with them. Sorted because scan order follows a lockfile's key order or a filesystem walk, and an unstable list looks to the server like a changed app on every rebuild.

WirePayload.installPathsComplete — separates "not installed there" from "we were not told". A yarn.lock is flat (hoisting is decided at install time and the file does not record it), so a missing paths from that source is not an answer. One entry without a location forfeits the claim for the whole payload, since a consumer reading a short list cannot tell which entry was incomplete. An empty package list does not claim completeness either — vacuous truth is the wrong answer when the scan found nothing.

Two sources had the information and threw it away:

• npm v1 lockfiles have no path keys, but their nesting is the layout — a nested dependencies map is literally the node_modules directory inside its parent. Until now the same repo produced a correlatable payload or an uncorrelatable one depending only on which npm wrote the lockfile, and nothing in the result showed which had happened.
• the node_modules walk knew the directory it read each manifest from. It now reports it. For a package reached through a symlink that is the link location, not the store target: a resolver walks up looking for node_modules/<name>, so the link is the path an import actually travels, while the target only says where the bytes live.

Windows

installLocation takes the platform path module as a parameter. Nothing could otherwise prove the POSIX normalization — CI runs on ubuntu only and path.sep is already / on every machine this is developed on, so on Windows node_modules\lodash would have matched nothing server-side and the correlation would have failed silently on exactly one platform. It has to be the whole module rather than the separator alone: POSIX path.relative cannot parse C:\app either (the first version of this test proved that by returning ../C:/app/...).

Compatibility

• Checksum unchanged. computeManifestChecksum already projects to {name, version} before hashing; a test pins it. If added fields moved the fingerprint, every already-reported build would read as changed the moment this shipped.
• No server change required. StoreManifest validates packages.*.name and packages.*.version; Laravel ignores unvalidated keys, so the added fields are accepted and simply unused until SaaS reads them.

Tests

10 tests in tests/install-paths.test.ts. Every guard mutation-checked individually:

reverted guard	result
duplicate paths discarded (keep first)	2 failed
paths not sorted	2 failed
completeness ignores missing paths	2 failed
empty list claims completeness	1 failed
v1 nesting not turned into a path	1 failed
v1 nested path loses its prefix	1 failed
walk reports no path	1 failed
separator not normalized	1 failed

One existing expectation changed: tests/node_modules_walk.test.ts "reads a package reached through a symlink" now expects path: 'node_modules/real', with a comment on why the link and not the target.

Full suite: 1594 passed, 6 skipped; typecheck and template typecheck clean.

Follow-up (not in this PR)

pnpm-lock.yaml and yarn.lock still supply no locations, so a pnpm/yarn project reports installPathsComplete: false. pnpm's importers section does encode per-workspace dependencies and could be derived from; yarn classic genuinely cannot. Consuming any of this — resolving an import site to an instance — is SaaS work.

🤖 Generated with Claude Code

[coderbuds]

Well-scoped feature with comprehensive opt-in install-paths implementation.

🎯 Quality: 100% Elite · 📦 Size: Large — consider splitting if possible

📈 This month: Your 138th PR — above team average · Averaging Excellent

_{See how your team is trending →}

[patchstackdave]

/review