fix: extension npm packages fail to resolve in compiled binary
Opened by swampadmin · 7/8/2025
Description
Since #611 (--external npm:*), extension models that import npm packages (e.g., @john/k8s importing npm:@kubernetes/client-node@1.0.0) fail when run from the compiled swamp binary:
Warning: Failed to load user model k8s/configmap.ts: TypeError: Could not find constraint '@kubernetes/client-node@1.0.0' in the list of packages.This affects ALL extension npm packages except npm:zod (which is in swamp's own dependency graph).
Root Cause
Two conflicting deno bundle failure modes:
CJS interop (#609): When npm packages are INLINED, CJS-dependent packages (e.g.,
@aws-sdk/client-s3→tslib) break withimport_tslib.default is undefined. This was fixed by #611 externalizing all npm packages.Compiled binary resolution: When npm packages are EXTERNALIZED (
--external npm:*), the compiled binary can't resolve packages not in its embedded dependency graph. This is the current regression.
Proposed Fix
Only externalize
npm:zod— revert--external npm:*to--external npm:zod@4 --external npm:zod. All other npm packages get inlined by the bundler, which works in compiled binaries.Ban dynamic imports — the CJS interop issue (#609) was triggered by
await import("npm:@aws-sdk/client-s3@3"). Add validation duringextension pushto reject dynamicimport()calls with a clear error. Static top-level imports are handled correctly bydeno bundle.Update skill docs — guide extension authors to use static imports only.
Impact
- Fixes
@john/k8sand any extension using npm packages from compiled binary - Prevents future CJS interop issues by rejecting the problematic pattern at push time
- No new runtime requirements (bundles remain self-contained)
- Extensions using dynamic imports will need to convert to static imports
Related
- #609 — Bundler breaks tslib CJS/ESM interop for dynamic imports
- #611 — Externalize all npm packages in extension bundler (introduced this regression)
Closed
No activity in this phase yet.
Sign in to post a ripple.