Problem
Spun out of #697 / PR #698. resolveDepVersions (in packages/server/src/bun-pin-rewrite.js) feeds ONLY the server-side Bun zero-install specifier rewrite. The browser importmap is built separately in packages/server/src/vendor.js via getPackageVersion() / resolvePackageDir(), which resolve a package's version by reading node_modules/<pkg>/package.json. Under Bun zero-install there is NO node_modules, so that read returns null and the vendor entry is skipped.
Two open questions this issue is to answer and then fix:
- Does the browser importmap actually resolve vendored deps under Bun zero-install today, or are bare browser imports left unresolved (a pre-existing gap)?
- If it resolves them via some other path, does that path pick the SAME version the server rewrite pins? A divergence means the server runs (say)
zod@3.25.76 while the browser importmap loads a different resolved version (server/client skew).
Design / approach
Make the resolved version a single shared source feeding BOTH the server rewrite AND the importmap under zero-install. Likely: when node_modules is absent, drive vendorImportMapEntries from the same package.json + bun.lock resolution resolveDepVersions uses (and, where a concrete version is needed for a jspm URL, resolve the range against the registry the way the vendor path already does for <pkg>@<version>).
Implementation notes (for the implementing agent)
- Where:
packages/server/src/vendor.js (getPackageVersion, resolvePackageDir, vendorImportMapEntries, jspmGenerate); packages/server/src/bun-pin-rewrite.js (resolveDepVersions); the Bun glue packages/server/src/action-seed-bun.js / action-seed.js; boot sequencing in packages/server/src/dev.js.
- Landmine: under zero-install there is no
node_modules, so any disk-resolution path is null there; the version must come from package.json + bun.lock (+ a registry query for a jspm-pinned URL).
- Landmine: a jspm importmap URL needs a concrete exact version, while the server rewrite can forward a range (Bun resolves it). To keep server and browser on the same version, the importmap must resolve the range to the exact Bun would pick, or both must agree on one resolved version.
- Verify with a real Bun zero-install boot of a dogfood app (no
node_modules) and assert the served <script type="importmap"> URLs match the versions the server actually runs.
Acceptance criteria
Relates to #697, #669.
Problem
Spun out of #697 / PR #698.
resolveDepVersions(inpackages/server/src/bun-pin-rewrite.js) feeds ONLY the server-side Bun zero-install specifier rewrite. The browser importmap is built separately inpackages/server/src/vendor.jsviagetPackageVersion()/resolvePackageDir(), which resolve a package's version by readingnode_modules/<pkg>/package.json. Under Bun zero-install there is NOnode_modules, so that read returns null and the vendor entry is skipped.Two open questions this issue is to answer and then fix:
zod@3.25.76while the browser importmap loads a different resolved version (server/client skew).Design / approach
Make the resolved version a single shared source feeding BOTH the server rewrite AND the importmap under zero-install. Likely: when
node_modulesis absent, drivevendorImportMapEntriesfrom the samepackage.json+bun.lockresolutionresolveDepVersionsuses (and, where a concrete version is needed for a jspm URL, resolve the range against the registry the way the vendor path already does for<pkg>@<version>).Implementation notes (for the implementing agent)
packages/server/src/vendor.js(getPackageVersion,resolvePackageDir,vendorImportMapEntries,jspmGenerate);packages/server/src/bun-pin-rewrite.js(resolveDepVersions); the Bun gluepackages/server/src/action-seed-bun.js/action-seed.js; boot sequencing inpackages/server/src/dev.js.node_modules, so any disk-resolution path is null there; the version must come frompackage.json+bun.lock(+ a registry query for a jspm-pinned URL).node_modules) and assert the served<script type="importmap">URLs match the versions the server actually runs.Acceptance criteria
node_modulesBun boot.Relates to #697, #669.