v0.1.17
Server-render in development, through Vite
Development emitted an empty <div id="app"> shell and let the client hydrate
it: boot() returned early because there was no built SSR bundle to load, and
loading the source through Node would have skipped every transform the
framework plugins apply — JSX, .vue, .svelte. So the one thing this package
exists for could not be exercised in the environment developers work in, and a
server-rendering bug only showed up in production.
Vite's own SSR loader applies those transforms. Photon now starts one in
middleware mode — it serves nothing, it only compiles — and fetches the entry
on EVERY render rather than caching it, so an edit to a page component shows
without restarting the process.
Vite is an optional peer. Three things keep this from becoming a cost anyone
pays involuntarily: without vite installed, dev falls back to the shell exactly
as before; the compiler starts only when entryServer actually exists, so a
client-only project never pays for a module graph and a watcher; and a
vite.config that throws degrades to the shell with a warning rather than taking
the dev server down.
close() releases the compiler — it holds a watcher, and leaving it running
keeps the process alive past a shutdown signal.
Tested both ways: a fake compiler for the wiring, and a real Vite instance for
the parts only Vite can answer — that createServer accepts these options,
that ssrLoadModule wants a root-relative URL, and that an edit to a
transitive import is actually picked up. Five mutations, each felling its test.
fix(renderer): resolve the build against the application root, not the cwd
path.resolve(process.cwd()) is only right when the process happens to have
started in the application's own directory. Under systemd, from the root of a
monorepo, or from anywhere a deployment finds convenient, photon looked for the
manifest and the SSR entry somewhere else -- and then served an unhydrated shell
rather than saying it had found nothing, which reads as a hydration bug for as
long as it takes to discover there was never a manifest.
The provider passes app.makePath(), the way bay already does for job
discovery, and an explicit appRoot in the config still wins: a deployment that
lays the build out elsewhere said so on purpose.
makePath stays optional on the context. photon is agnostic, so a host with no
notion of an application root keeps the cwd-relative lookup it had.
Name the CI workflow after the package
Every workflow already declared name: <pkg>-ci inside — twenty-eight of
twenty-nine — while the file was ci.yml almost everywhere and
<pkg>-napi-ci.yml in three places, where the -napi said nothing: half the
packages with a Rust engine did not carry it.
The file now matches the name it has always had, so one rule covers every
repository and the publish command no longer depends on remembering which
three were spelled differently.
GitHub keys run history by file path, so the runs recorded under the old name
stay reachable under it and this workflow starts a fresh history.
Drop a doc example that used an API atlas no longer has
Changes since v0.1.16.