Configurable __manifest route for lazyRouteDiscovery feature

[johannesbraeunig]

Background

We're running multiple Remix applications on a single domain, structured by distinct basePath segments. For example:

• http://remix.run.com/register → Register App
• http://remix.run.com/docs → Docs App

Each app operates independently and can have deeply nested routes, such as:
http://remix.run.com/docs/intro/first/page/ → served by the Docs App.

---

The Issue

After enabling the future flag v3_lazyRouteDiscovery in a Remix app, we encountered a critical problem:

The __manifest route is shared across all apps on the same domain.
This behavior assumes the __manifest route exists at the root level of the domain, causing conflicts and breaking the app where this flag was enabled.

This issue has been previously highlighted by @JLarky: Discussion Comment.

---

Proposed Solution

To resolve this, the destination of the __manifest route should be configurable or disableable.
As mentioned by @brophdawg11 in the linked discussion, it seems this functionality may already exist but has not been shipped yet.

By allowing customization of the __manifest route location, RR7/Remix applications can operate independently on the same domain without conflict, ensuring compatibility with the lazyRouteDiscovery feature.

---

We’d appreciate feedback on whether this configuration is already available or if there are plans to introduce it soon.

Thank you for your work and support! 🙌

[philippd]

We’ve encountered the same issue and would also like the __manifest route to be configurable.

An even better solution for us, given our relatively small manifest file, would be a configuration option to opt out of lazy route discovery entirely and keep serving a static manifest file instead.

[johannesbraeunig]

@brookslybrand do you think you can take a look at this request? If you need more context, please don't hesitate to let me know! Thank you in advance 🙌

[KnisterPeter]

Another solution would be that the __manifest route respects the basePath setting of vite. I guess that's the most expected way to solve it.

[JLarky]

I hear the same argument used by Astro team (which has very similar global magic routes) but that makes deployment story less flexible. I.e. that means that I can only have one global app that uses urls without a prefix and everyone else have to be scoped to /dashboard, /app and so on. I mean it's definatelly better than nothing, but in case of Remix they don't have as many magical urls yet and opportinity to make them configurable is easier to achieve :)

[KnisterPeter]

I meant when there is a base path configured in vite, I would have expected that all path (!) respect the base path.
That does not mean that configuration is not a good thing and would be good as well.

[KnisterPeter]

What I proposed is already possible and works as expected.
There is a basename config in the remix vite plugin config. It's respected by the router for lazy route discovery.

[johannesbraeunig]

Thank you for the investigations! ♥️ This could be improved in the documentation. I take a look and contribute it. 🤜🤛

I'll close this discussion.

[s-abstract]

In my case, the Lazy Route Discovery feature breaks PWA in offline mode. And I cannot complete Remix -> React Router migration because of that. That would be helpful to be able to opt out of this feature, unless you have a better solution for PWA and Lazy Route Discovery.