A monorepo holds many projects — apps and shared libraries — in a single repository. It makes sharing code, coordinating changes across projects, and running atomic cross-project commits much easier than juggling many separate repos.

What is the difference between apps and packages?

Apps in apps/* are deployable applications like a web frontend or API. Packages in packages/* are internal libraries — UI components, config, utilities — consumed by the apps. Keeping the two separate clarifies what ships and what is shared.

What does the workspace protocol do?

Referencing an internal package as workspace:* tells the package manager to link the local source instead of fetching from a registry. Apps always use the current in-repo version, so a change to a shared package is picked up immediately.

Should I use fixed or independent versioning?

Fixed versioning releases every package under one shared version, which is simple but bumps everything each release. Independent versioning lets each package version on its own cadence, which suits libraries consumed at different rates — Changesets manages this well.

Why use Turborepo or Nx instead of plain workspaces?

Plain workspaces handle linking but not caching or task orchestration. Turborepo and Nx add a task graph, caching, and affected-only runs, so CI only rebuilds and tests what actually changed — a big speedup as the repo grows.

Monorepo Setup Guide Builder

One repo, many projects, clear rules

A monorepo only stays pleasant if everyone follows the same structure and conventions. This builder generates the guide that makes that happen: a labeled directory tree, the config for your chosen tool, how shared packages are referenced, your versioning strategy, and a CI/CD outline. Commit it at the repo root and new contributors know where everything goes.

How it works

You name the organization and package scope (like @acme), then list your apps and shared packages. The tool renders a directory tree with apps/* for deployable applications and packages/* for internal libraries, and shows how an app depends on a package using the workspace protocol ("@acme/ui": "workspace:*") so apps always use the local source.

It then emits tool-specific configuration for your choice — a turbo.json task pipeline, an Nx note, a Lerna note, or a pnpm-workspace.yaml. The versioning section explains the trade-off between fixed and independent releases, and the CI/CD outline describes the install-frozen-lockfile, lint, test, build, and deploy steps a pipeline should run.

Tips and example

Keep the apps/packages split strict. If an “app” is being imported by another app, it is really a package — move it.
Use the workspace protocol everywhere internally so a change to a shared package is reflected instantly, with no publish step in development.
Run affected-only tasks in CI (turbo run with caching, or nx affected) so a one-line change does not rebuild the entire repo.
Pin shared tool versions — Node in .nvmrc, the package manager in package.json engines — so every machine and CI runner behaves identically.

Monorepo Setup Guide Builder

Email me this result

One repo, many projects, clear rules

How it works

Tips and example