Structure a monorepo running multiple Next.js apps without duplicating your design system

You are designing the monorepo layout for several Next.js apps that need to share code, using Turborepo and pnpm workspaces, with shared code living in internal packages that each app depends on via the workspace protocol rather than files copy-pasted between app directories.

APPS NEEDED
marketing site (apps/web), customer dashboard (apps/dashboard), internal admin tool (apps/admin)

SHARED CODE NEEDED
A design-system UI package, shared TypeScript types for the API, shared eslint/tsconfig config

DEPLOYMENT MODEL
Each app deploys independently as its own Vercel project with its own domain and preview deployments

STRUCTURE REQUIREMENTS
Put apps/ at the repo root, holding one folder per deployable Next.js app, each with its own next.config file, package.json, and env files — Next.js resolves .env files relative to each app's own root directory, not the monorepo root, so every app needs its own env files even for values that happen to be identical across apps; a shared .env file sitting at the repo root silently does nothing for any of them. Put packages/ at the repo root too, holding shared, non-deployable code: a UI package for shared components, a config package for shared eslint, tsconfig, and Tailwind config, a types package if there's a shared domain model worth centralizing, each with its own package.json so it can be versioned and depended on independently. Wire apps to internal packages via the workspace protocol — for example "@repo/ui": "workspace:*" — so a change to a shared package is picked up by every app that depends on it without a publish step in between; without this live link, "shared" UI components tend to get copy-pasted at the first point of divergence, since there's no actual dependency forcing consumers to stay in sync. Configure turbo.json's task pipeline so build, lint, and test tasks declare their real dependencies — a shared package's build must complete before an app that depends on it builds — so Turborepo's caching can actually skip rebuilding an app when nothing it depends on has changed; don't leave every task marked as depending on the whole repo by default, since that defeats the caching benefit that's the entire reason to accept a monorepo's coordination overhead in the first place. Decide, and state explicitly, whether each app deploys independently as separate projects and domains or as part of one coordinated deployment, since this affects whether environment variables and preview deployments get configured per-app or centrally.

OUTPUT FORMAT
The folder tree showing apps/ and packages/ with their contents, an example turbo.json pipeline entry showing the dependency between a shared package's build and an app's build, and one paragraph specifically explaining the env-file resolution gotcha above and how it changes what each app's setup instructions need to say.