Monorepo path resolutions

[clowNay]

First of all, thanks for making this available we have been looking for something like this for some time now.

We have noticed some issues:

• +types from react-router is not located in the same location as the route entry when using relative path. It resolves the types from where the routes.ts file is located, which doesn't match the monorepo setup.
• root layout.tsx in app/routes is not resolved as a layout for a routes inside monorepo workspace directory.

Our react router monorepo setup:
apps/<appName>/app/routes/*
modules/<moduleName>/src/routes/*

With apps and modules being workspaces of the monorepo.
Each module can have it's own routes but not a routes.ts file, which resides in our app/routes.ts.

Example:
Route relative path from cwd: ../../modules/<module>/src/routes
+types get placed relative from routes.ts file which places the type file in the wrong directory.

[kenn]

@codex @claude review

[claude]

Claude finished @kenn's task in 1m 57s —— View job

---

Reviewing Issue #11: Monorepo Path Resolutions

Analysis Summary

After reviewing the codebase, I can now explain what's happening with both reported issues:

Issue 1: +types Path Resolution

Current Behavior:
The +types directory issue is actually not managed by this library. React Router v7's type generation system creates +types folders automatically as part of its own typegen feature (see React Router Type Safety docs).

Key Finding:
This library only generates the route manifest (the RouteConfig[] array) with these properties:

• id: The route identifier
• file: The import path to the route module
• path: The URL path
• index: Whether it's an index route
• children: Nested routes

Looking at src/core/routing/files.ts:111-148, the getRouteInfo() function generates the file property using importFilePath, which is calculated as:

const importFilePath = path
  .join(routeDir.importPrefix, file)
  .split(path.win32.sep)
  .join('/')

The importPrefix is determined in src/utils.ts:159-166 and is relative to the app directory, not to where routes.ts lives. This is correct for the route imports themselves.

The Problem:
React Router's own typegen (not this library) generates +types folders based on the route manifest's file paths. Since those paths are relative to the app directory, React Router places the +types folders relative to the app directory—which doesn't match the actual filesystem location of your monorepo routes.

This is a React Router v7 issue, not a react-router-auto-routes issue. The library correctly generates import paths, but React Router's typegen doesn't account for monorepo layouts where routes live outside the app directory structure.

Issue 2: Root Layout Not Resolving Across Directories

Current Behavior:
Looking at src/core/routing/structure.ts:86-184, the buildRouteTree() function determines parent-child relationships using:

1. A parentLookup map keyed by mountPath + segments (line 36-37)
2. Parent resolution that only searches within the same mountPath (line 93-113)

The Problem:
Line 97-98 shows that for index routes, it looks for parents using:

parentId = parentLookup.get(keyFor(route.mountPath, route.segments))?.id

Line 101-109 shows that for non-index routes, it searches for parents by walking up segments:

for (let length = route.segments.length - 1; length > 0; length--) {
  const candidate = parentLookup.get(
    keyFor(route.mountPath, route.segments.slice(0, length)),
  )
  // ...
}

Key Finding: The keyFor() function (line 36-38) includes mountPath in the key:

function keyFor(mountPath: string, segments: readonly string[]): string {
  return `${mountPath}::${segments.join('/')}`
}

This means layouts can only be found within the same mount path. A route at mount path /modules will never find a layout at mount path / even if they share the same segments.

This is by design to keep route trees isolated per mount point. However, this doesn't match the user's expectation that a root layout.tsx in app/routes should apply to routes from other directories.

Recommendations

For Issue 1 (+types):

This needs to be addressed in React Router v7 itself or worked around by:

1. Filing an issue with the React Router team about monorepo typegen support
2. Using TypeScript path mapping to redirect +types imports
3. Restructuring your monorepo so all routes live under the app directory

For Issue 2 (Cross-mount layouts):

The current architecture intentionally isolates mount points. To support your use case, you'd need to:

Option A (Recommended): Use a single mount point with subdirectories:

autoRoutes({
  routesDir: 'app/routes'  // Single mount, organize with folders
})

Then structure your files as:

app/routes/
  _layout.tsx              → Root layout for all routes
  index.tsx
  modules/
    moduleA/
      route1.tsx
    moduleB/
      route2.tsx

Option B: Duplicate the root layout in each mount:

apps/<appName>/app/routes/_layout.tsx
modules/<moduleName>/src/routes/_layout.tsx

Option C (Requires code changes): Enhance the library to support cross-mount parent resolution, which would require:

1. Adding a configuration option to allow specific layouts to span mount points
2. Modifying keyFor() and resolveParentId() to optionally check the / mount for shared layouts
3. Careful consideration of edge cases and precedence rules

This would be a significant architectural change and may introduce complexity.

Conclusion

• Issue 1 is a React Router v7 limitation, not this library's responsibility
• Issue 2 is working as designed - mount points are intentionally isolated for predictable behavior

Would you like me to implement Option C to support cross-mount layouts, or do you prefer to restructure your setup using Option A or B?

---

[kenn]

It's really two separate things:

1. React Router typegen (+types) and external route files

React Router’s typegen (+types) expects route modules to live under your app directory. If you mount route files from outside app/ like the monorepo story, ./+types/* imports inside those external files may not resolve.

This library doesn’t generate files—it only returns a RouteConfig[]—but you can work around typegen limitations by creating shim route modules under app/routes that re-export the real route module code from your workspace package.

Example:

apps/web/
  app/
    routes/
      blog/
        $postId.tsx        (shim route module)
modules/
  blog/
    src/
      routes/
        blog/
          $postId.tsx      (real route module)

apps/web/app/routes/blog/$postId.tsx:

export { default } from '../../../../../modules/blog/src/routes/blog/$postId'
export * from '../../../../../modules/blog/src/routes/blog/$postId'

If your workspace is published/aliased, prefer package imports:

export { default } from '@acme/blog/routes/blog/$postId'
export * from '@acme/blog/routes/blog/$postId'

Keep any ./+types/* imports in the shim (since that’s where React Router will generate them).

2. Root layout not applying to module routes

That’s expected with the current design—mounts are intentionally isolated for parent/layout resolution. If you need a shared shell, I'd recommend to import root layout then re-export everything as it is. That way, you'd still get DRY layout across mount points.

export { default } from '~/routes/root-layout'
export * from '~/routes/root-layout'

Can you let me know if these answers your questions?

[clowNay]

Thank you @kenn - This seems solveable and I can even create a watcher script, which looks for routes in the modules workspace and creates the related shim routes for each route 👍

[kenn]

Cool, when you have time pls share your final solution!

[clowNay]

It seems creating shim routes, opens up another issue which is probably also react-router related. It doesn't seem to be able to handle the loaders correctly.

I have a shim route in my modules in app/routes, it as you gave an example of just exports everything from the actual route residing in the module workspace. When I use that it seems to be unable to hydrate and have mismatches between client and server.

When I move the file from the module back in to the app routes it works perfectly.

My react-router contexts lives in a package by it self, could it be that it creates a new instance of those contexts, when used in two different workspaces?

Also I am using the v8_middleware future feature in the config of react-router.

I will post a solution here once I figure it out :)