You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The apps CI job ("In-repo app tests (website + blog)", .github/workflows/ci.yml ~L264-292) boots only the website and blog (it runs each app's own webjs test). Its own comment (L272-273) states docs and packages/ui/packages/website (ui-website) are excluded because they ship no test suite. webjs check runs on all four (L35), but that is convention validation, not a boot/SSR check.
So a regression that breaks docs or ui-website SSR (a bad importmap, a server-only import leaking to the client, a render throw) passes CI. Today that gap is covered by a MANUAL discipline (boot all four dogfood apps every framework PR), which is fragile because it relies on the agent remembering. Automate it.
Design / approach
Add a boot smoke for docs + ui-website to the apps job. They have no webjs test suite, so use the in-process boot the other dogfood checks use: createRequestHandler({ appDir, dev: false }) from @webjsdev/server, drive a GET on a known route via the handle() harness, and assert status < 400 (and ideally that the served <script type=\"importmap\"> is present for a browser-wire smoke). Run in dist mode where applicable so it covers the prod wire. Keep it lightweight (one or two routes per app), not a full suite.
Implementation notes (for the implementing agent)
Where to edit: .github/workflows/ci.yml, the apps job (~L264-292). Add steps that boot docs (docs/) and ui-website (packages/ui/packages/website/). Update the job comment at L272-273 (it currently justifies their exclusion) and consider renaming the job from "(website + blog)" to "(all in-repo apps)".
Boot pattern: createRequestHandler({ appDir, dev: false }) + handle('GET', '<route>'), assert status < 400. The harness must run from INSIDE the repo (bare @webjsdev/* only resolves from the repo node_modules). A small script under test/ or a scripts/ boot-smoke is cleaner than inline YAML.
Landmines: docs needs its Tailwind built (npm run css:build / the webjs.start.before step) before serving, and ui-website may need its registry built; reproduce each app's start prerequisites or the boot 500s on a missing asset. ui-website currently has a pre-existing no-static-properties violation in its vendored components/ui/* (the in-progress Deprecate static properties field and enforce declare-free factory DX #598 migration) but that does not affect SSR boot.
Invariants: keep packages/ buildless (no new build step for the framework); the smoke is CI-only tooling.
Tests + docs: this IS test/CI infra (no app-runtime change). Update the apps job comment; no docs-site or AGENTS.md change needed.
Acceptance criteria
CI boots all four in-repo apps (blog, website, docs, ui-website) and asserts each serves (status < 400)
A regression that only breaks docs or ui-website SSR fails CI with no manual boot
The apps job comment no longer claims docs / ui-website are uncovered
The manual "boot all 4 dogfood apps every PR" discipline becomes a backstop, not the primary coverage
Problem
The
appsCI job ("In-repo app tests (website + blog)",.github/workflows/ci.yml~L264-292) boots only the website and blog (it runs each app's ownwebjs test). Its own comment (L272-273) states docs andpackages/ui/packages/website(ui-website) are excluded because they ship no test suite.webjs checkruns on all four (L35), but that is convention validation, not a boot/SSR check.So a regression that breaks docs or ui-website SSR (a bad importmap, a server-only import leaking to the client, a render throw) passes CI. Today that gap is covered by a MANUAL discipline (boot all four dogfood apps every framework PR), which is fragile because it relies on the agent remembering. Automate it.
Design / approach
Add a boot smoke for docs + ui-website to the
appsjob. They have nowebjs testsuite, so use the in-process boot the other dogfood checks use:createRequestHandler({ appDir, dev: false })from@webjsdev/server, drive a GET on a known route via thehandle()harness, and assert status < 400 (and ideally that the served<script type=\"importmap\">is present for a browser-wire smoke). Run in dist mode where applicable so it covers the prod wire. Keep it lightweight (one or two routes per app), not a full suite.Implementation notes (for the implementing agent)
.github/workflows/ci.yml, theappsjob (~L264-292). Add steps that boot docs (docs/) and ui-website (packages/ui/packages/website/). Update the job comment at L272-273 (it currently justifies their exclusion) and consider renaming the job from "(website + blog)" to "(all in-repo apps)".createRequestHandler({ appDir, dev: false })+handle('GET', '<route>'), assertstatus < 400. The harness must run from INSIDE the repo (bare@webjsdev/*only resolves from the repo node_modules). A small script undertest/or ascripts/boot-smoke is cleaner than inline YAML.npm run css:build/ thewebjs.start.beforestep) before serving, and ui-website may need its registry built; reproduce each app'sstartprerequisites or the boot 500s on a missing asset. ui-website currently has a pre-existingno-static-propertiesviolation in its vendoredcomponents/ui/*(the in-progress Deprecate static properties field and enforce declare-free factory DX #598 migration) but that does not affect SSR boot.packages/buildless (no new build step for the framework); the smoke is CI-only tooling.appsjob comment; no docs-site or AGENTS.md change needed.Acceptance criteria
appsjob comment no longer claims docs / ui-website are uncovered