With Nx Workspace, I updated the Vite Config as follows:

/// <reference types='vitest' />import{defineConfig}from'vite';importreactfrom'@vitejs/plugin-react';import{nxViteTsPaths}from'@nx/vite/plugins/nx-tsconfig-paths.plugin';import{TanStackRouterVite}from'@tanstack/router-vite-plugin';import{join}from'path';exportdefaultdefineConfig({root:__dirname,cacheDir:'../../node_modules/.vite/apps/web',server:{port:4200,host:'localhost',},preview:{port:4300,host:'localhost',},plugins:[react(),TanStackRouterVite({routesDirectory:join(__dirname,'src/routes'),generatedRouteTree:join(__dirname,'src/routeTree.gen.ts'),routeFileIgnorePrefix:'-',quoteStyle:'single',}),nxViteTsPaths(),],// Uncomment this if you are using workers.// worker: {//  plugins: [ nxViteTsPaths() ],// },build:{outDir:'../../dist/apps/web',reportCompressedSize:true,commonjsOptions:{transformMixedEsModules:true,},},test:{globals:true,cache:{dir:'../../node_modules/.vitest',},environment:'jsdom',include:['src/**/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}'],reporters:['default'],coverage:{reportsDirectory:'../../coverage/apps/web',provider:'v8',},},});

Hi@tl-frameplay@rahulretnan , can you please help me in figuring out how routing will work in Microfrontend architecture.. I am using turborepo and tanstack Router
I am just now sure, routing which are defined in packages will work in apps

I guess,@tannerlinsley finally heard us.😅 He is including a example of tanstack router in monorepo. Thanks, Really, appreciate the Effort. ✨

Basic:
https://github.com/tanstack/router/tree/main/examples/react/router-monorepo-simple

With React Query:

https://github.com/TanStack/router/tree/main/examples/react/router-monorepo-react-query

I gave it a go and made a turborepo template with tanstack router at the core:

• https://github.com/nktnet1/rt-stack

It's not a small example, with many other components such as

• tailwind/shadcn
• trpc
• hono
• drizzle-orm
• better-auth

and so on, but hopefully someone finds it helpful :).

I'm going to hijack this discussion post to try to explain my main difficulty with the current recommendation of how Router supports monorepos, and what I think some potential solutions are. It all revolves around cyclical dependencies (get it?). What do I mean?

Lets say I have the monorepo setup that's currently in the docs:

.└── packages/    ├── app    ├── package-1    ├── package-2    └── router

The main thing to note here is thatrouter is where our routes folder,routeTree.gen.ts file, and router instance are defined. For the sake of this example, lets only worry about file based routing.app is really just an empty shell that consumes the routes. This setup looks great because now the exported functions fromrouter can now be consumed by the other packages to get that sweet, sweet, type inference. In theory too, if we had multiple apps / multiple routers, we'd be able to know which app/router is which because they export their own instance. Cool, looks good.

Now lets imagine that inrouter I have a route with some search params with some validation:

import { createFileRoute } from "@tanstack/react-router";import * as v from "valibot";const searchSchema = v.object({  redirect: v.optional(v.string()),});export const Route = createFileRoute("/sign-in")({  component: SignInPage,  validateSearch: searchSchema,});function SignInPage() {  const { redirect } = Route.useSearch();  return <>Hello</>;}

Now lets add a component frompackage-1 to the route:

import { Redirect } from "@acme/package-1"import { createFileRoute } from "@tanstack/react-router";import * as v from "valibot";const searchSchema = v.object({  redirect: v.optional(v.string()),});export const Route = createFileRoute("/sign-in")({  component: SignInPage,  validateSearch: searchSchema,});function SignInPage() {  const { redirect } = Route.useSearch();  return (    <>      <Redirect />    </>  );}

Lets say that this this component is the actual thing that cares about our search param. These typed & validated search params are a really powerful feature of Router. Personally, I really like the idea of having component that require / consume these params be responsible for getting them, similar to other ideas of having components that consume specific data be responsible for getting that data. Router thought of that too, and it's great that you can access to these typed & validated values even outside of route components via theRoute object or thegetRouteApi function.

Except wait a second, how doespackage-1 access those types or objects? Well it would need to install ourrouter package as a workspace dependency, consume those typed APIs, and then export our component again to be consumed byrouter:

import { getRouteApi } from "@acme/router";const routeApi = getRouteApi('/sign-in');export const Redirect = () => {  const routeSearch = routeApi.useSearch();  return <>Do something with redirect {routeSearch.redirect}</>;}

But now we've created a cyclical dependency:

router -> package-1 -> router -> app

Big no-no in monorepos, most tools will yell at you if you have cyclical dependencies, if notoutright refuse to run.

So how to solve this? Well there's a few ideas I can think of:

1). Router concerns are router concerns.

Leave the router stuff to the router and have packages expect that data via props / another data contract:

function SignInPage() {  const { redirect } = Route.useSearch();  return (    <>      <Redirect redirect={redirect} />    </>  );}

I'm totally cool with this being the answer. It's not what Iwant, but it makes sense. Now our graph has the correct direction again:package-1 -> router -> app. But we lose that composability that can be really powerful with component based design. I can't have the component that actually cares about & uses the data be responsible for getting it .

2). Loosen types

Loosen up our types as outlined in the docs:

const search = useSearch({    strict: false,  })

I'm down to loosen these types, and type them inside our package instead. But we're better than that, right? Ok cool, moving on.

3). Create a new sink for the Route APIs in our graph

Go onto any of these GitHub issues where people complain about cyclical dependencies and the first answer is to create a new package or combine existing packages. We're not gonna combinepackage-1 androuter, the whole point of the monorepo is to split them up, so lets focus on the former. Our graph would become something like

package-that-has-router-apis -> package-1 && router -> app

But Router doesn't really support this at the moment. When I generate my types for therouter, they're kind of stuck inside thatrouter package. Maybe this is the reasoning behind the idea of "Move all generated code out of the src and app directories. Preferably a .tanstack directory." in theV2 ideas. This opens up a can of worms if you have multiple router instances in the same repo, so I can see why this might be tricky. You might have to have separate sink packages for each router, idk.

4). Import the package in the app only

This is how the current monorepo example is set up. In this paradigm,package-1 would export the page, not found, and error components for that route, then we set those components on that route inapp. This is the real answer, right? I'm not convinced. To me--and this is just pure personal preference--theapp is the router, and the router is the app. I don't really like the idea of splitting up mypage from myrouter, I think the DX of having my router far away from the page / layout / outlet that's rendered is kind of backwards.

With file based routing, I really like how we can look at our files in our routes folder and understand the structure of the app at a glance, AND seeing the actual page rendered on the route. This colocation of pages and routes is really powerful and is a big reason for me why these file based routes are so powerful. I think by spreading them out like this we've taken the idea of the monorepo too far. I want my router to be responsible for pages and routing, not just routing. Maybe this means that we do need to go back to the single responsibility pattern outlined in solution 1, I'm not sure. All of this is to say that something about splitting my pages from my router feels off to me. I'm open to being wrong on this, but I feel like I'm losing a key advantage of what I like about file based routing.

5). Cheat

This is kind of what@davidturissini mentioned in their reply above, which is to just grab thetypes via a script or task and make them available at a lower package in the graph. I'd go even further honestly, I'd be fine with putting something like that at the root of the repo, something like arouterGen.d.ts at the root of the repo that only overwrites types. A package is probably better, but the point is to get these types available somewhere lower in the graph / ambiently available in the repo. This has the same issue as above for if there are multiple routers in the same repo, but probably alleviated by good package management.

My preferred solution
I would love for Router to be able to generate these types for me, but not necessarily tie them to myrouter orapp package. The type generation & type safety is probably my favorite feature of Router, but it's difficult to leverage them in a monorepo. I would love to be able to tell Router "Generate X files in Y directories, I'll handle hooking everything up so they're imported and used correctly.". If there's a way to do that now, I haven't really been able to get it to work correctly by changing thegeneratedRouteTree path option.

Someone tell me if I'm missing something or doing something wrong, because I've found it difficult to get my sweet, sweet type safety with Router in a monorepo. Idk, let me know what you think or if I'm over complicating this.

Hey everyone,
I’m still trying to figure out the best way to set up my monorepo with TanStack Router while keeping type autocompletion working.

My structure looks like this:

.└── apps/    ├── app-1    └── app-2└── packages/    ├── router    ├── shared    └── ...

The main thing I’m aiming for is thatapp-1 andapp-2 share a bunch of identical routes (same paths and content), which I’d like to keep inshared. Then each app would add its own extra routes on top of those. Ideally, autocompletion would only show the shared routes inside shared, and then app-specific routes would autocomplete only in their respective apps.

Has anyone found a good way to do this with the current state of TanStack Router?