router fix react-basic-ssr-streaming-file-based example

The react basic-ssr-streaming-file-based example is a bit outdated and no longer working.

This fix updates the server.js and entry-server.tsx to match those of the basic-ssr-file-based example as these were using the new createRequestHandler and defaultStreamHandler.

This also addresses an issue with the index route where the deferred value is causing an error when accessing the getDate() function. The value when streamed in is not being transformed back into a date. I assume this will be addressed with the serializer re-write/seroval but until then this at least allows the example to run.

Jun 14 '25 15:06 nlynzaad

thanks! can you please rename package.disabled.json back to package.json?

Jun 14 '25 19:06 schiller-manuel

View your CI Pipeline Execution ↗ for commit 1a45da5b5f704aa2662ba94b697aceafc1bf35b9.

Command	Status	Duration	Result
`nx affected --targets=test:eslint,test:unit,tes...`	✅ Succeeded	5m	View ↗
`nx run-many --target=build --exclude=examples/*...`	✅ Succeeded	2m 22s	View ↗

☁️ Nx Cloud last updated this comment at 2025-06-16 22:42:14 UTC

Jun 14 '25 19:06 nx-cloud[bot]

Will do.

Was wondering why it was named as such but didn't want to change it.

Jun 14 '25 19:06 nlynzaad

the name was just a way to disable it from building (and failing) in CI

Jun 14 '25 20:06 schiller-manuel

needs updating the lockfile as well

Jun 14 '25 20:06 schiller-manuel

More templates

@tanstack/arktype-adapter

npm i https://pkg.pr.new/TanStack/router/@tanstack/arktype-adapter@4429

@tanstack/directive-functions-plugin

npm i https://pkg.pr.new/TanStack/router/@tanstack/directive-functions-plugin@4429

@tanstack/eslint-plugin-router

npm i https://pkg.pr.new/TanStack/router/@tanstack/eslint-plugin-router@4429

@tanstack/history

npm i https://pkg.pr.new/TanStack/router/@tanstack/history@4429

@tanstack/react-router

npm i https://pkg.pr.new/TanStack/router/@tanstack/react-router@4429

@tanstack/react-router-devtools

npm i https://pkg.pr.new/TanStack/router/@tanstack/react-router-devtools@4429

@tanstack/react-router-with-query

npm i https://pkg.pr.new/TanStack/router/@tanstack/react-router-with-query@4429

@tanstack/react-start

npm i https://pkg.pr.new/TanStack/router/@tanstack/react-start@4429

@tanstack/react-start-client

npm i https://pkg.pr.new/TanStack/router/@tanstack/react-start-client@4429

@tanstack/react-start-plugin

npm i https://pkg.pr.new/TanStack/router/@tanstack/react-start-plugin@4429

@tanstack/react-start-server

npm i https://pkg.pr.new/TanStack/router/@tanstack/react-start-server@4429

@tanstack/router-cli

npm i https://pkg.pr.new/TanStack/router/@tanstack/router-cli@4429

@tanstack/router-core

npm i https://pkg.pr.new/TanStack/router/@tanstack/router-core@4429

@tanstack/router-devtools

npm i https://pkg.pr.new/TanStack/router/@tanstack/router-devtools@4429

@tanstack/router-devtools-core

npm i https://pkg.pr.new/TanStack/router/@tanstack/router-devtools-core@4429

@tanstack/router-generator

npm i https://pkg.pr.new/TanStack/router/@tanstack/router-generator@4429

@tanstack/router-plugin

npm i https://pkg.pr.new/TanStack/router/@tanstack/router-plugin@4429

@tanstack/router-utils

npm i https://pkg.pr.new/TanStack/router/@tanstack/router-utils@4429

@tanstack/router-vite-plugin

npm i https://pkg.pr.new/TanStack/router/@tanstack/router-vite-plugin@4429

@tanstack/server-functions-plugin

npm i https://pkg.pr.new/TanStack/router/@tanstack/server-functions-plugin@4429

@tanstack/solid-router

npm i https://pkg.pr.new/TanStack/router/@tanstack/solid-router@4429

@tanstack/solid-router-devtools

npm i https://pkg.pr.new/TanStack/router/@tanstack/solid-router-devtools@4429

@tanstack/solid-start

npm i https://pkg.pr.new/TanStack/router/@tanstack/solid-start@4429

@tanstack/solid-start-client

npm i https://pkg.pr.new/TanStack/router/@tanstack/solid-start-client@4429

@tanstack/solid-start-plugin

npm i https://pkg.pr.new/TanStack/router/@tanstack/solid-start-plugin@4429

@tanstack/solid-start-server

npm i https://pkg.pr.new/TanStack/router/@tanstack/solid-start-server@4429

@tanstack/start-client-core

npm i https://pkg.pr.new/TanStack/router/@tanstack/start-client-core@4429

@tanstack/start-plugin-core

npm i https://pkg.pr.new/TanStack/router/@tanstack/start-plugin-core@4429

@tanstack/start-server-core

npm i https://pkg.pr.new/TanStack/router/@tanstack/start-server-core@4429

@tanstack/start-server-functions-client

npm i https://pkg.pr.new/TanStack/router/@tanstack/start-server-functions-client@4429

@tanstack/start-server-functions-fetcher

npm i https://pkg.pr.new/TanStack/router/@tanstack/start-server-functions-fetcher@4429

@tanstack/start-server-functions-server

npm i https://pkg.pr.new/TanStack/router/@tanstack/start-server-functions-server@4429

@tanstack/valibot-adapter

npm i https://pkg.pr.new/TanStack/router/@tanstack/valibot-adapter@4429

@tanstack/virtual-file-routes

npm i https://pkg.pr.new/TanStack/router/@tanstack/virtual-file-routes@4429

@tanstack/zod-adapter

npm i https://pkg.pr.new/TanStack/router/@tanstack/zod-adapter@4429

commit: 1a45da5

Jun 14 '25 20:06 pkg-pr-new[bot]

I see it fails a the build test if '@tanstack/react-start' is not added to the ssr external array in vite for this example.

I've added it to the PR

Jun 14 '25 20:06 nlynzaad

please don't merge this yet, we need to still figure out how to handle the ssr noExternal setting properly

Jun 15 '25 22:06 schiller-manuel

Trying this out locally, whilst this does work in dev, it doesn't seem to work once a production build has been made.

Jun 15 '25 22:06 SeanCassiere

Thanks for looking at this.

I've made a couple of updates to resolve the ssr build actions for both server and client builds as well as serving in production.

When building this outside of the mono-repo this builds perfectly without the external clause and runs fine in prod and dev modes.

However as soon as we try and build it in the mono repo the below appears:

Honestly not too sure what might be the cause other than its clearly not able to resolve the virtual import in the mono-repo. If you have any ideas where to start looking I would be more than happy to continue scratching around and resolving it.

Jun 16 '25 01:06 nlynzaad

Scratched a bit further.

From what I can see the dependencies flow from start-server-core => react-start-server => react-start/server.

The virtual modules is part of start-server-core but does not get imported/used in the functions needed for the router ssr (non-start) functionality. However, this is included in the barrel exports and also marked as external dependencies in start-server-core. My guess is this is where it falls over when building in the mono-repo but passes when building for standalone.

By specifically marking the VIRTUAL_MODULES as external the build passes in both the mono-repo and standalone. And since this is not used (from what I can see) for SSR to function in a pure SPA router app this should not be a problem.

Also ran this through the test suite and it passes all tests.

Ideally this should not be making its way into the build process at all but I'm not familiar enough with nx mono-repos to understand how to exclude this specifically in the build and other than stripping it out into either separate exports or alternative package this seems to be the path of least resistance.

Open to any suggestions you might have.

Jun 16 '25 13:06 nlynzaad

@schiller-manuel @SeanCassiere

I was able to avoid the externalising of the VIRTUAL_MODULES by bubbling up an additional export for the core ssr functions from start-server-core all the way through to react-start.

This is in addition to current exports and does not alter those at all.

If this method is acceptable then I'm wondering if this should not be split into separate PRs probably since this is now more than just fixing an example.

Alternatively, these functions can possible be split into a separate package that can be re-exported by start-server-core and hence not affect the current packages but can be used by a pure router only project for SSR purposes.

Again, open to your thoughts on this

Jun 19 '25 21:06 nlynzaad

interesting! why does the separate export solve this?

Jun 20 '25 02:06 schiller-manuel

My understanding is it has to do with how the bundler traverses the barrel exports coming from the dependencies. (see blog post written by TKDodo: Please Stop Using Barrel Files)

When running standalone (not part of the router mono-repo) these packages (and therefore the virtual modules) are included in the NODE_MODULES and by default don't get traversed.

When part of the mono-repo it seems it is traversing the packages, and it then hits the VIRTUAL_MODULES which it can't find and the error occurs. Since the examples is part of the mono-repo the dependencies are resolved from the mono-repo and not from node_modules. As per vite's documentation: "Vite automatically detects dependencies that are not resolved from node_modules and treats the linked dep as source code." Monorepos and Linked Dependencies.

This is not a problem in pure start examples since that uses the start plugin that initializes the VIRTUAL_MODULES but for pure router examples these don't get initialized and it breaks the build.

When doing a separate export for only the essential modules that is required for SSR, the loadVirtualModules.js file is not traversed as it doesn't form part of the export and hence the problem is avoided.

Jun 20 '25 09:06 nlynzaad

The real problem here seems to be that we are using the start package to do the SSR for the router project. It blurs the already grey line separating start from router even more.

I assume you would not be particularly keen on introducing a new package, but the cleanest and most modular solution is probably to move these SSR essentials to a separate package (for example router-ssr). It could even be moved to router-core but this would muddy the responsibilities that router-core has.

Start-server-core could depend on and re-export as it does currently for any project/package that depends on it while router projects would then depend on this "router-ssr" project and would not need to depend on start and hence the import tree is kept clean from start only functionality.

Jun 20 '25 09:06 nlynzaad

i like the idea of having separate packages. we just need to find a clean separation. For example, where should the serialization be put?

Jun 20 '25 10:06 schiller-manuel

The broad idea would be to separate anything that is generic ssr into this package.

This is probably a huge over simplification, but I will work on a proposal tonight and send it through.

Jun 20 '25 10:06 nlynzaad

closing in favour of #4495

Jun 21 '25 23:06 nlynzaad