chore: delete the docs and ui-website redirect-only apps - #1305
Conversation
Both apps had stopped being apps. Since #1098 moved the documentation to website/app/docs and #1099 moved the component gallery to website/app/ui, each was one middleware.ts returning a 301 plus a stub page, carried as a full npm workspace, a Railway service, a Dockerfile stage and a compose service. Two Cloudflare Redirect Rules on the webjs.dev zone do that work at the edge now, so neither host needs an origin at all. Verified before removing anything: every probed URL on both hosts redirects, and no response carries x-railway-request-id, so Cloudflare answers and never contacts Railway. The rules are a deliberate downgrade from the middleware they replace. The middleware was path-aware; the rules collapse each host onto its hub page. That was measured rather than assumed: no third-party page links to either host, both Railway services show no recent HTTP traffic, neither subdomain is in the sitemap, and the destinations are already canonicalised and indexed, so there is no ranking signal left to lose. The two e2e suites that drove the ui-website dev server move to the website gallery at /ui/<name>, which is the same nested-layout shape they were written for. The one exception is the scroll-restoration block, which now runs against /docs: the router restores window scroll correctly there, but on a /ui/<name> page it reproducibly lands on 1563 instead of the 800 it was given. That is a live website behaviour rather than anything this change introduces, and the block asserts the router, not the gallery.
The deletion left a set of claims behind that are now false rather than merely stale, and two of them sit in published source: the ui fetcher's doc block and the registry README both stated that the old ui.webjs.dev/registry URLs still resolve to their new equivalents. They redirect to the gallery page instead, so a fetch gets HTML, which is exactly the 0.3.1 through 0.3.8 break this change accepts. Both now say so, as does the fetcher test that pointed at a mapping test deleted here. framework-dev.md gains the only in-repo record of what the two Cloudflare rules match and where they send. The deleted middleware files carried that plus the reason the hosts can never be retired, and nothing replaced it, so a future edit to the zone had nothing to restore from. The rest is reference drift: packages/ui/AGENTS.md still listed the deleted workspace and an `npm run ui:dev` script that no longer exists, packages/cli/AGENTS.md still counted four apps behind the doctor gate, and the docs site's own architecture tree still showed docs/.
vivek7405
left a comment
vivek7405
left a comment
There was a problem hiding this comment.
Went through the whole diff against the live zone rather than just the hunks, and the deletion side is solid: the Dockerfile COPY set, compose, the workspace/lockfile pair, the boot-check and preload lists, and the .docs-sidebar / .docs-nav selectors the moved e2e suites depend on all line up.
What it missed is the other half of a deletion like this: the claims left behind elsewhere. A dozen places still describe these hosts as live, path-preserving, or registry-serving, and two of them are in PUBLISHED source rather than docs. packages/ui/src/registry/fetcher.js tells a reader the old registry URL still works and must keep working forever, which is the stated rationale for the local-first design sitting right under it. It does not work any more, and this change is what stopped it. Same claim in the registry README, and the fetcher test points at a mapping test this PR deletes.
The one I care about most is that nothing in the repo records what the two Cloudflare rules actually are. The deleted middleware files carried the mapping tables AND the reason these hosts can never be retired. Both are gone and framework-dev.md only says they serve no assets, so the next person to touch the zone has nothing to restore from.
Everything here is a text fix, so I have taken all of it.
|
Review resolutions: every finding taken, one deliberately left as is All the findings sat on lines this PR had not touched, so they went in the summary rather than as inline anchors. Fixed in
The one worth calling out separately is that nothing recorded what the two rules actually are. The deleted middleware carried the mapping tables and the reason these hosts can never be retired, and losing both was a real gap rather than drift. Left as is: the scroll-restoration block running against |
1 participant
Closes #1304
Summary
docs/andpackages/ui/packages/website/had stopped being apps. Since #1098 moved the documentation towebsite/app/docsand #1099 moved the component gallery towebsite/app/ui, each was onemiddleware.tsreturning a 301 plus a stub page, carried as a full npm workspace, a Railway service, a Dockerfile stage and a compose service. Two Cloudflare Redirect Rules on thewebjs.devzone do that work at the edge now, so neither host needs an origin at all.The rules were deployed and verified BEFORE anything was deleted. Redirect Rules fire in the request phase, before Cloudflare fetches the origin, so they took over while Railway was still serving:
x-railway-request-iddocs.webjs.dev/https://webjs.dev/docsdocs.webjs.dev/docs/routinghttps://webjs.dev/docsui.webjs.dev/https://webjs.dev/uiui.webjs.dev/docshttps://webjs.dev/uiui.webjs.dev/docs/components/buttonhttps://webjs.dev/uiui.webjs.dev/registry/button.jsonhttps://webjs.dev/uiui.webjs.dev/public/og.pnghttps://webjs.dev/uiThe absent header is the load-bearing part: Cloudflare answers and never contacts Railway, so removing the services changes nothing about what those hosts serve.
What this gives up, deliberately
The rules are a downgrade from the middleware they replace. The middleware was path-aware; the rules collapse each host onto its hub page. That was measured rather than assumed: no third-party page links to either host, both Railway services show no recent HTTP traffic, neither subdomain is in the 139-URL sitemap, and the destinations (43
/docsURLs, 33/uiURLs) are already canonicalised and indexed. There is no ranking signal left to lose.Two consequences, both accepted:
ui.webjs.dev/registry/<name>.jsonnow redirects to an HTML page. Published@webjsdev/ui0.3.1 through 0.3.8 hard-code that URL (confirmed by unpacking the 0.3.5 tarball) and will fetch HTML then fail to parse it as JSON. 0.3.9+ resolves local-first (ui: local-first registry, on-demand example delivery, MCPuitool #983) and is unaffected.ui.webjs.dev/public/og.png, referenced by already-scraped social cards) now redirect to the gallery page.Coverage gap, stated rather than papered over
test/docs/docs-host-redirect.test.mjsandtest/ui/ui-host-redirect.test.mjsasserted that the redirect hosts keep resolving. That behaviour lives in Cloudflare now and CI cannot see it. I deliberately did NOT add a network test against the live zone to replace them: a CI job that reds when Cloudflare has a bad minute is worse than the gap.The e2e suites that drove the deleted app
test/e2e/nested-layout-partial-swap.test.mjsandtest/e2e/form-submission-and-race.test.mjsboth booted the ui-website dev server. Rather than delete them, they move to the website gallery at/ui/<name>, which is the same nested-layout shape they were written for (same.docs-sidebaraside, same sibling-link nav). Three real adjustments, not just a path rename:.docs-navinside the aside, not the aside itself, so the scroll assertions moved to it./docs/and had to become/ui/.Both suites pass: 2/2 and 6/6 against a live website dev server.
One finding I did not chase
The scroll-restoration block now runs against
/docsrather than/ui, and the reason is a real behaviour worth knowing about. The router restores window scroll correctly on/docs/*: set 800, navigate away, go back, get 800. On a/ui/<name>gallery page the same sequence reproducibly lands on 1563, stable across timings and independent of how the click is dispatched. No focused element and noscrollIntoViewin the gallery shell explains it, and I stopped there because it is a live website behaviour rather than anything this change introduces, and the block asserts the router rather than the gallery. Flagging it rather than filing it.Test plan
npm cisucceeds against the regenerated lockfile (validated in a clean tree)test/e2e/nested-layout-partial-swap.test.mjs2/2 against a live website dev servertest/e2e/form-submission-and-race.test.mjs6/6 against a live website dev servernpm test: 3928 tests, 3927 pass, 1 skip, 0 fail (a first run failedtest/integration/blog-http.test.mjsagainst an unmigrated blog DB, the documented environment requirement; 12/12 afterdb:migrate+db:seed)docker build -t webjs-delete-check ., exit 0), which is the check that matters here since a COPY of a missing source is a hard Docker error invisible to every in-process testwebjs checkpasses onexamples/blogandwebsite;webjs doctor0 failed on both (10 passed / 2 warn, and 9 passed / 3 warn)/,/docs/no-build,/docs/components,/ui,/ui/buttonall 200,/ui/buttonwith 50 modulepreloads and none brokenDoc surfaces
A review round caught that the first commit updated the surfaces naming the deleted DIRECTORIES but not the ones making claims about the HOSTS, and two of those claims were in published source. Corrected in the second commit.
AGENTS.md(the doctor gate now names two apps),framework-dev.md,README.md(repo tree, ports table, dev commands),website/AGENTS.md,.claude/skills/webjs-start-work/SKILL.md,.claude/hooks/route-skills.sh,.claude/hooks/require-docs-with-src.shpackages/ui/src/registry/fetcher.jsandpackages/ui/packages/registry/README.mdboth said the oldui.webjs.dev/registryURLs still resolve to their new equivalents, which is exactly what this change stops;packages/ui/test/fetcher.test.jspointed at a mapping test deleted here;README.mdsaiddocs.webjs.devredirects path-preservingly;packages/ui/AGENTS.mdlisted the deleted workspace and annpm run ui:devscript that would now fail;packages/cli/AGENTS.mdcounted four apps behind the doctor gate; plus stale comments inpurge-cdn.yml,generate-favicon.mjs,site-seo-tags.test.mjsand theDockerfileheaderwebsite/app/docs/architecture/page.ts, whose repo tree still listeddocs/. My earlier "docs site N/A" was wrongframework-dev.mdgains the only in-repo record of the two Cloudflare rules: what they match, where they send, why they are static rather than path-preserving, why they can never be removed, and a manual verification command. The deleted middleware carried that and nothing replaced it