PR #1716 injects pregenerated concrete paths into dist/server/index.js during vinext deploy so the PPR fallback-shell guard can avoid serving placeholder shell HTML for known pregenerated routes whose exact cache entry is absent.
This works for the vinext deploy path, and PR #1716 adds coverage that the injected Worker entry hydrates the registry at module init.
Follow-up: decide whether this registry population should move into normal build/prerender finalization, or whether direct publication of build artifacts with Wrangler should be explicitly documented as unsupported for this feature.
Questions to resolve:
- Should
vinext build artifacts always include the concrete-path registry?
- Is
vinext deploy the only supported publication path for cacheComponents fallback-shell serving?
- Do we need an E2E/direct-Wrangler test proving supported publication paths populate
getRenderedConcreteUrlPathsForRoute(route.pattern)?
Refs #1359
Refs #1716
PR #1716 injects pregenerated concrete paths into
dist/server/index.jsduringvinext deployso the PPR fallback-shell guard can avoid serving placeholder shell HTML for known pregenerated routes whose exact cache entry is absent.This works for the
vinext deploypath, and PR #1716 adds coverage that the injected Worker entry hydrates the registry at module init.Follow-up: decide whether this registry population should move into normal build/prerender finalization, or whether direct publication of build artifacts with Wrangler should be explicitly documented as unsupported for this feature.
Questions to resolve:
vinext buildartifacts always include the concrete-path registry?vinext deploythe only supported publication path for cacheComponents fallback-shell serving?getRenderedConcreteUrlPathsForRoute(route.pattern)?Refs #1359
Refs #1716