Build with nitro preset 'bun' serves all static assets with a 404

[jebh]

Which project does this relate to?

Start

Describe the bug

We recently upgraded an app from @tanstack/start v1.102.5 and now see that in the production build with the 'bun' preset, static assets are no longer served correctly - the server returns a 404. This applies to all assets in the .output/public folder.

The temporary workaround is to use the 'node-server' preset instead and continue to serve the build with bun run.

Your Example Website or App

https://codesandbox.io/p/devbox/6np3x7

Steps to Reproduce the Bug or Issue

The codesandbox is a copy of the 'Start Basic' example with no changes other than the addition of server: { preset: "bun" } to app.config.ts

1. In a terminal run pnpm build
2. Run bun run .output/server/index.mjs
3. In another terminal or browser access a static asset - e.g. curl -i http://localhost:3000/favicon.png

Expected behavior

The build should continue to function as it did with an earlier version of @tanstack/start.

Screenshots or Videos

No response

Platform

• OS: macOS
• Browser: Chrome

Additional context

No response

[jebh]

Seems like the problem was introduced in 1.103.0. Specifically, overriding @tanstack/start-config in pnpm to version 1.102.6 resolves the issue.

https://discord.com/channels/719702312431386674/1341377700027306015

[ryan-callahan-edo]

"@tanstack/start-config": "1.102.6" isn't working for me with all my tanstack router + start deps on 1.102.x or 1.103.x (I tried all patch versions). Any chance theres a work around for current versions?

[lucasthevenet]

I've recently ran across the exact same issue, and after some fiddling, I found that changing the server.serveStatic prop in the app.config.ts file to either node or inline appears to fix it:

import { defineConfig } from "@tanstack/react-start/config";

export default defineConfig({
  server: {
    preset: "bun",
    serveStatic: "node", // or "inline"
  }
});

[isnifer]

@lucasthevenet omg, THANK YOU! 3 hours wasted 🥲

[pdlug]

@lucasthevenet Another big thank you, wasted a ton of time trying to figure this out!