v0.1.18
Type the context a pages predicate is handed
It was unknown, so a migrator could not write ctx.request.header(...)
without an assertion — the capability was there and unusable. The decoupling
argument for that did not hold: photon already needs ream's types to compile,
for the ctx.photon augmentation.
It is NOT ream's HttpContext either, though. The middleware works on a
structural shape and passes that; naming the framework class would promise
members it never hands over — the compiler said so the moment it was tried.
SsrConfig takes the shape the middleware actually serves, and stays generic
for a host that drives the renderer with a context of its own.
The concurrency test was sequential. It runs both requests through Promise.all
now, and says plainly that no mutation can fail it: with a per-call argument the
property is structural, and the test exists to catch a rewrite that moved the
context onto the renderer.
Hand the ssr.pages predicate the request it is deciding about
Upstream passes the HTTP context to that callback; photon passed the component
name alone and pointed callers at the middleware instead. That is not the same
capability: middleware owns the whole response, where this owns only whether
THIS component is server-rendered — "SSR for crawlers, hydrate for everyone
else" needs the second.
The stated reason for the deviation does not hold up. The renderer being a
shared singleton says nothing about what a per-call argument may carry, and the
context photon builds is already per request. Nothing is stored on the
renderer: the context is threaded through the call and two concurrent requests
cannot see each other's, which is what one of the tests checks.
Four mutations plus a fifth that fell nothing at first — the middleware
wiring was the uncovered caller, because every test built the context by hand.
Keep the dev-dependency alignment, drop the workspace: protocol
The internal ranges had been rewritten to workspace:^. That resolves inside
this monorepo and nowhere else: every package CI checks out its own repository
alone and runs pnpm install, where the protocol has no workspace to point at
and fails with ERR_PNPM_WORKSPACE_PKG_NOT_FOUND before a single test runs. The
concrete ranges are back; the dev-dependency bumps that came with the same edit
are kept, and now match what the lockfile already resolved.
Changes since v0.1.17.