Summary
NetScript Fresh canary defer adoption can silently split the web runtime across incompatible package singletons when an application pins only @netscript/fresh/defer and @netscript/fresh/defer/island while keeping the @netscript/fresh root and @netscript/sdk stable.
In EIS Chat, this compiled and built, but exact Aspire + Playwright runtime proof showed two failure modes:
- the stable root
definePage continued to emit the stable defer implementation while the explicit layout imported the canary island;
- after aligning only the Fresh root to canary.3, the route partials failed with
[NetScript SDK] Cache provider not initialized because the application imported SDK 0.0.5 while Fresh canary.3 owned SDK 0.0.6-canary.3.
Reproduction
- Deno 2.9.5
@netscript/fresh 0.0.5@netscript/fresh/defer and /defer/island 0.0.6-canary.3@netscript/sdk 0.0.5- NetScript SDK query factories with
getCachedEntry
- Fresh deferred route using generated/root
definePage
Then navigate through a Fresh partial. The build passes, but either the canary coordinator is not consistently used or the partial reports the uninitialized cache provider error.
Expected
The supported dependency closure should be explicit and mechanically enforced. A subpath pin should not permit a split root runtime, and Fresh should not create/use a different SDK cache singleton from the application's SDK import.
A useful fix could be one or more of:
- publish/declare exact peer-compatible versions for the Fresh/SDK/telemetry closure;
- reject mixed root/subpath versions at build/init time;
- avoid module-version-local provider singleton ownership;
- document that the full coherent closure must be pinned together for canaries.
Verified workaround
Pinning all three direct dashboard imports coherently resolves the failure:
@netscript/fresh@0.0.6-canary.3@netscript/sdk@0.0.6-canary.3@netscript/telemetry@0.0.6-canary.3
After that correction, Playwright measured channel/session/knowledge route changes at 21–45 ms, no real skeleton at 20/100/1000 ms, no browser errors, and warm navigation issued no named-region partial refetches.
Aspire telemetry on the broken run also showed successful server prewarm plus the client decision policy; the user-visible failure was the split cache-provider runtime, not loader latency.
Acceptance
Summary
NetScript Fresh canary defer adoption can silently split the web runtime across incompatible package singletons when an application pins only
@netscript/fresh/deferand@netscript/fresh/defer/islandwhile keeping the@netscript/freshroot and@netscript/sdkstable.In EIS Chat, this compiled and built, but exact Aspire + Playwright runtime proof showed two failure modes:
definePagecontinued to emit the stable defer implementation while the explicit layout imported the canary island;[NetScript SDK] Cache provider not initializedbecause the application imported SDK 0.0.5 while Fresh canary.3 owned SDK 0.0.6-canary.3.Reproduction
@netscript/fresh0.0.5@netscript/fresh/deferand/defer/island0.0.6-canary.3@netscript/sdk0.0.5getCachedEntrydefinePageThen navigate through a Fresh partial. The build passes, but either the canary coordinator is not consistently used or the partial reports the uninitialized cache provider error.
Expected
The supported dependency closure should be explicit and mechanically enforced. A subpath pin should not permit a split root runtime, and Fresh should not create/use a different SDK cache singleton from the application's SDK import.
A useful fix could be one or more of:
Verified workaround
Pinning all three direct dashboard imports coherently resolves the failure:
@netscript/fresh@0.0.6-canary.3@netscript/sdk@0.0.6-canary.3@netscript/telemetry@0.0.6-canary.3After that correction, Playwright measured channel/session/knowledge route changes at 21–45 ms, no real skeleton at 20/100/1000 ms, no browser errors, and warm navigation issued no named-region partial refetches.
Aspire telemetry on the broken run also showed successful server prewarm plus the client decision policy; the user-visible failure was the split cache-provider runtime, not loader latency.
Acceptance