Fix the frontend dev server 404ing every route after the SSR migration - #1347
Merged
Conversation
Vite lists `lightningcss` as an optional peer and `@tanstack/start-plugin-core` depends on it, so bun installed a second copy of Vite for the plugin. TanStack Start gates its SSR dev middleware on `isRunnableDevEnvironment()`, an `instanceof` check, which cannot match across two copies — the plugin returned without installing anything and left `vite dev` answering every route with a connect 404. That broke `bun dev` and the nightly Playwright journeys, whose webServer probe only accepts a status below 404 and whose `/index.html` fallback disappeared with the SSR migration.
The e2e workflow uploads `playwright-report/` on failure, but the CI reporter list produced only terminal output, so both upload steps found nothing and a red nightly run left no artifact to debug from.
✅ Deploy Preview for vortex-sandbox ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for vortexfi ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for vrtx-dashboard canceled.
|
The rationale lives in `src/tests/vite-single-instance.test.ts`, next to the assertion that enforces it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The nightly e2e run failed with
Timed out waiting 120000ms from config.webServer. The same breakage also affectsbun devlocally, so this is not CI-only.What broke
Vite lists
lightningcssas an optional peer, and@tanstack/start-plugin-coredepends on it directly. Bun therefore resolved that peer only for the plugin and installed a second copy of Vite (vite@7.3.6+859f710…next to the app'svite@7.3.6+4d96f45…).TanStack Start decides whether to install its SSR dev middleware with
isRunnableDevEnvironment(env), which is aninstanceofcheck. Across two Vite copies that check cannot match, and the plugin returns silently — no warning, no error. The result:vite devstarts normally ("ready in 1.3s") but nothing handles requests, so every route falls through to connect's404 Cannot GET /.200 <= status < 404, and its/index.htmlfallback also 404s because Improve SEO by prerendering marketing pages to static HTML #1333 removedindex.html. It polls for the full 120s and fails the job.I confirmed this by instrumenting the plugin at runtime: the SSR environment is a
RunnableDevEnvironment, but the plugin's check resolves from the other Vite copy and reportsrunnable: false.Nothing caught it at PR time because the e2e workflow only runs on
schedule/workflow_dispatch, never on PRs.The fix
Adding
lightningcssas a direct devDependency ofapps/frontendmakes bun resolve the same optional-peer set at both positions, collapsing to a single Vite copy. It is one line inbun.lock(the package was already resolved as a transitive dependency), andbun install --frozen-lockfilestill passes.apps/frontend/src/tests/vite-single-instance.test.tsasserts that the app and the Start plugin resolve the same Vite module, and carries the rationale for the otherwise-unused dependency. It fails with the exact duplicate-copy mismatch when the dependency is reverted, so it genuinely guards the regression.Second issue
Both "Upload report on failure" steps warned
No files were found. The CI reporter list had nohtmlreporter, soplaywright-report/was never written and a red nightly left nothing to debug from. Added it to both the frontend and dashboard configs.Verification
Clean worktree at
origin/staging:typecheck/lint/ frontendbuild