Is there any way to share Next.js pages across multiple apps in a Turborepo?

[girishcx07]

Hi everyone,

I am exploring whether it is possible to share Next.js pages across multiple apps inside a Turborepo.

Context

My repository structure looks like this:

apps/
  app1/
  app2/

packages/
  common-ui/
  ui/
  typescript-config/
  tailwind-config/
  eslint-config/
  ...

Both app1 and app2 have almost identical modules and functionality. To avoid duplication, I created a common-ui package and tried moving reusable pages and components into these packages.

Issues I Encountered

However, when I attempted to import Next.js pages or modules from these shared packages, I hit several limitations:

1. Next.js APIs (cookies, headers, server-only modules) cannot be used inside shared packages.
   I received tracing and runtime errors such as: “Cookies can only be used inside a Next.js App Router environment”.

2. Server Components and Client Components behave inconsistently when located in external workspaces.
   Next.js seems to isolate each app at the project root, so external packages lose access to Next.js internals.

3. The Turborepo was originally created using a ShadCN template, which heavily couples the structure to a single app.
   The repository feels heavier than expected and difficult to extend for multi-app sharing.

Additional Context: TSUP Exploration

I also started exploring TSUP to optimise and bundle my shared packages.
However, I am not sure whether TSUP is the appropriate choice in this scenario:

• Should shared React/Next.js components even be bundled using TSUP?
• If pages or server components cannot be executed inside a shared package, is TSUP going to help or cause more isolation issues?
• What is the recommended way to use TSUP in a monorepo with multiple Next.js applications?
• Should shared UI packages be unbundled (plain TypeScript + Next.js transpilePackages) instead of being built with TSUP?

At this stage, I am unsure where TSUP fits into a multi-app Next.js monorepo, especially when the goal is to reuse App Router components.

What I Want to Achieve

• A clean monorepo setup where Next.js pages, layout structures, and server/client components can be shared across multiple applications.
• Ideally, reusable modules should behave exactly like native Next.js files inside app1 and app2.
• I cannot share the actual private repository, but I can share the full directory tree if needed.

Questions

1. Is it currently possible to share Next.js pages or App Router modules (layouts, routes, server components) across apps in a Turborepo?

2. Are there recommended patterns for:

   • sharing server components?
   • sharing client components that rely on Next.js hooks?
   • sharing logic that depends on cookies, headers, or other Next.js server-side features?
   • sharing pages across the projects so that if anything change in the app1 considering app2 might have the impact?

3. How should TSUP be used (or avoided) in a monorepo where shared packages need to integrate tightly with Next.js?

4. If anyone has an example repository with such a setup, could you share guidance or best practices?

5. If recreating the repo from scratch is easier, I am open to step-by-step help.

Any suggestions or sample structures would be greatly appreciated.
Thank you!

[KippieG]

Yes, sharing Next.js pages across Turborepo apps is possible, but the constraints you hit are real — and the solution depends on what you are trying to share.

The core constraint

Next.js APIs (cookies(), headers(), redirect(), notFound()) are only available when code runs inside a Next.js App Router context. This is not a monorepo limitation — it applies even within a single app if you call those APIs from compiled/bundled output instead of source. The error you saw is caused by the package being treated as an external node module rather than as part of the Next.js app root.

What works: shared source packages (no build step)

For components and utilities that use Next.js APIs, do not bundle the shared package. Export raw TypeScript/TSX source and let each Next.js app transpile it:

// packages/common-ui/package.json
{
  "name": "@repo/common-ui",
  "exports": {
    ".": "./src/index.ts"
  }
}

// apps/app1/next.config.ts
const nextConfig = {
  transpilePackages: ["@repo/common-ui"],
};

With transpilePackages, Next.js compiles the shared package as if it were part of the app. cookies(), headers(), Server Components, and Client Components all work correctly because the code runs inside the Next.js compilation boundary.

What about TSUP?

TSUP is the right choice for utility packages that do not use Next.js APIs (pure logic, types, constants, generic UI with no server-only imports). For anything that touches next/headers, next/navigation, or uses "use client" / "use server", skip the build step and use transpilePackages instead.

Package type	Approach
Pure logic / types	TSUP → dist/index.js
Generic React UI (no Next.js APIs)	TSUP or transpilePackages
Server Components / Next.js APIs	transpilePackages only, no build step
Pages	See below

Sharing actual pages

Next.js page files (page.tsx, layout.tsx, loading.tsx) cannot be imported from an external package and treated as routes. Routing is resolved from the file system relative to the app's app/ directory.

The practical pattern for near-identical pages across app1 and app2 is:

1. Extract the page content (the component and its data fetching) into a shared package.
2. Keep a thin page.tsx in each app that just imports and re-exports from the shared package.

// packages/common-ui/src/pages/PostsPage.tsx
export async function PostsPage() {
  // data fetching, Next.js APIs — all fine here with transpilePackages
}

// apps/app1/app/posts/page.tsx
export { PostsPage as default } from "@repo/common-ui/pages/PostsPage";

This keeps routing in each app while sharing 100% of the logic.

TL;DR

• Use transpilePackages for any shared code that touches Next.js APIs — no TSUP needed for those.
• TSUP only for packages that compile to plain JS with no Next.js dependency.
• You cannot share page files directly, but you can share page components and re-export them from thin wrappers in each app.

[girishvisaero]

Thanks for details.