Problem
vercel.json configures "outputDirectory": "frontend/dist" (the Vite build output, a flat static site with index.html at its root) but then defines:
"routes": [
{ "src": "/(.*)", "dest": "/frontend/$1" }
]
This rewrites every request path to /frontend/<path> — a directory prefix that does not exist inside outputDirectory (the build output is served from the root of frontend/dist, not from a frontend/ subpath within it). For a single-page app using client-side routing, the standard (and necessary) rewrite is every path -> /index.html, letting the SPA's router handle it after load. As configured, a user who refreshes the browser on any non-root route, or opens a deep link (e.g. a shared link to a specific transaction), is at serious risk of hitting a 404 from Vercel's routing layer instead of the app, since the rewrite target doesn't correspond to any real path in the deployed output.
Suggested approach
- Replace the
routes rewrite with the standard Vercel SPA fallback: "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }] (Vercel's newer rewrites config, which coexists with headers), removing the stale /frontend/$1 destination.
- After deploying, manually verify that refreshing the browser on a non-root client-side route (e.g.
/transactions/123) still loads the app rather than 404ing.
- Re-check this alongside the CSP
connect-src fix in the companion issue, since both live in the same recently-touched vercel.json file from the current Vercel-deploy effort.
Problem
vercel.jsonconfigures"outputDirectory": "frontend/dist"(the Vite build output, a flat static site withindex.htmlat its root) but then defines:This rewrites every request path to
/frontend/<path>— a directory prefix that does not exist insideoutputDirectory(the build output is served from the root offrontend/dist, not from afrontend/subpath within it). For a single-page app using client-side routing, the standard (and necessary) rewrite is every path ->/index.html, letting the SPA's router handle it after load. As configured, a user who refreshes the browser on any non-root route, or opens a deep link (e.g. a shared link to a specific transaction), is at serious risk of hitting a 404 from Vercel's routing layer instead of the app, since the rewrite target doesn't correspond to any real path in the deployed output.Suggested approach
routesrewrite with the standard Vercel SPA fallback:"rewrites": [{ "source": "/(.*)", "destination": "/index.html" }](Vercel's newerrewritesconfig, which coexists withheaders), removing the stale/frontend/$1destination./transactions/123) still loads the app rather than 404ing.connect-srcfix in the companion issue, since both live in the same recently-touchedvercel.jsonfile from the current Vercel-deploy effort.