Monorepo where multiple repositories can export routes
Unanswered
Barbary Lion posted this in #help-forum
Barbary LionOP
Hi,
We are making a monorepo where there will be multiple repositories that export pages (eg.
The only way to achieve that using Next.js that I know is to use Multi Zones. But with Zones approach when navigating from
There will be shared navigation between both apps and the transition from one app to another should be smooth.
App router has route groups which would work great, but it doesn't support monorepos, meaning you can't export a route group from another package.
Are there any solutions to this or should we stick to React-router-dom which works without full page reload?
We are making a monorepo where there will be multiple repositories that export pages (eg.
app1/app/page.tsx & app2/app/blog/page.tsxThe only way to achieve that using Next.js that I know is to use Multi Zones. But with Zones approach when navigating from
app1 to app2 there's a full page reload.There will be shared navigation between both apps and the transition from one app to another should be smooth.
App router has route groups which would work great, but it doesn't support monorepos, meaning you can't export a route group from another package.
Are there any solutions to this or should we stick to React-router-dom which works without full page reload?
7 Replies
Why don't exporting a component from other repositories instead? You can still reuse the logic while having a maintainable project structure
Barbary LionOP
@fuma But we want to store routing in corresponding packages, so that
blog package has all the routes for blogThen you might use
export * from "@repo/blog/page" as an alternative. Next.js doesn't have such functionality for nowHonestly, that is not the purpose of monorepo.
We usually put components, utilities, or shared logic, such as functions for fetching blogs, into another package.
This project structure enables extra benefits for build caching and unit tests. Putting your whole route into a package isn't a recommended way and can't bring you any benefits
We usually put components, utilities, or shared logic, such as functions for fetching blogs, into another package.
This project structure enables extra benefits for build caching and unit tests. Putting your whole route into a package isn't a recommended way and can't bring you any benefits
Barbary LionOP
I agree with your point, but the rest of the team does not.
The purpose they want it is because one team will be working on eg,
The purpose they want it is because one team will be working on eg,
/store part of the website, and other team on /blogI'm not sure what arguments should I use in that :/
Then your team might need someone to create the all routes I guess. Like a code previewer or a senior.
I can't help you discussing this with your team, but personally, I think that's not a great idea as many teams I worked in doesn't do such a thing.
It's normal to have many people working in the same repo
I can't help you discussing this with your team, but personally, I think that's not a great idea as many teams I worked in doesn't do such a thing.
It's normal to have many people working in the same repo