DEV Community

Victor Daodu
Victor Daodu

Posted on

Nx Monorepo Setup in 2026: Skip the Confusion, Build the Right Architecture

#nx #monorepo #angular #webdev

When I first started exploring Nx monorepos, I thought the process would be simple:

  1. Create the workspace
  2. Generate an application
  3. Start coding

So I ran:

npx create-nx-workspace@latest my-workspace
Enter fullscreen mode Exit fullscreen mode

…and immediately hit my first moment of confusion.

Not because Nx did too much — but because I didn't yet understand what it had created, or why a monorepo is shaped the way it is.

This article walks through how to approach an Nx monorepo in 2026 without the early confusion most of us run into: what the create command really gives you, how libraries actually show up, and how to grow a clean architecture from there.

Versions used here: Nx 23, Angular 22. Commands are stable across recent Nx versions, but output details can shift slightly.

What is Nx?

Nx is a build system and monorepo framework that helps you manage multiple applications and shared libraries in a single repository.

Instead of maintaining separate repos:

frontend-repo
backend-repo
shared-ui-repo
shared-types-repo
Enter fullscreen mode Exit fullscreen mode

you keep everything together, with clear boundaries:

platform/
├── apps/
│   ├── web
│   ├── admin
│   └── api
└── libs/
    ├── ui
    ├── shared
    ├── models
    └── data-access
Enter fullscreen mode Exit fullscreen mode

One repo, shared tooling, and enforced boundaries between projects.

Creating an Nx Workspace

Start with:

npx create-nx-workspace@latest workspace-name
Enter fullscreen mode Exit fullscreen mode

Nx asks you a few questions. The two that matter most for beginners:

1. Which stack / preset?

Preset Good for
Angular / React / Vue / etc. Learning Nx or starting a real app — you get framework config for free
Node / Express / Nest Backend-only or API-first projects
TS / None (minimal) Experienced users who want an empty, custom architecture
Package-based Building and publishing reusable npm packages

If you're new, pick a framework preset. You'll get a working app and sensible defaults instead of a blank canvas.

2. Should I enable Nx Cloud?

You'll see something like:

Speed up GitHub Actions, GitLab CI, and more with Nx Cloud?
Enter fullscreen mode Exit fullscreen mode

For beginners, Skip for now is usually the right call. Nx Cloud is genuinely useful — remote caching, distributed task execution — but it solves problems you hit later:

  • slow CI pipelines
  • large teams
  • distributed builds

You can turn it on any time as the project grows.

The Part Nobody Explains: What You Actually Get

Here's the thing I wish someone had told me on day one.

A fresh create-nx-workspace with a framework preset generates one application and its e2e project. That's it.

For an Angular preset, you get something like:

Projects:

shop
shop-e2e
Enter fullscreen mode Exit fullscreen mode

You do not automatically get feature-products, shared-ui, models, or a data-access layer. Those are libraries you create later — either by hand with generators, or by following one of the Nx tutorials that builds them out step by step.

This trips up a lot of people. You read a tutorial showing a rich structure like this:

Projects:

shop
shop-e2e
products
feature-products
feature-product-detail
shared-ui
models
data
api
Enter fullscreen mode Exit fullscreen mode

…and you assume the create command produced all of it. It didn't. That's the end state of a tutorial, not the output of one command.

Rule of thumb: the create command gives you a starting app. Every library after that is a deliberate choice you make.

Once you internalize that, Nx stops feeling like a black box and starts feeling like a set of tools you're in control of.

nx show projects output listing shop, shop-e2e, api and the feature/ui/data/models libraries

First Thing To Do: Read the Graph

Before you generate — or delete — anything, look at your dependency graph:

npx nx graph
Enter fullscreen mode Exit fullscreen mode

This opens an interactive view of how your projects connect:

shop-e2e
   │
   ▼
  shop
   │
   ├── feature-products
   │
   └── shared-ui
Enter fullscreen mode Exit fullscreen mode

The graph is one of Nx's strongest features. It tells you:

  • what depends on what
  • what's safe to remove
  • how your apps and libraries actually wire together

You can also list projects as plain text:

npx nx show projects
Enter fullscreen mode Exit fullscreen mode

Nx project graph showing shop-e2e depending on shop, shop on the feature libraries, and everything converging on models

Removing Projects the Right Way

If you scaffolded something you don't want (say, an example app), don't just delete the folder. Manually removing a directory leaves behind config, path mappings, and graph references.

Use the generator instead:

npx nx g @nx/workspace:remove project-name
Enter fullscreen mode Exit fullscreen mode

For example:

npx nx g @nx/workspace:remove shop
Enter fullscreen mode Exit fullscreen mode

Sometimes Nx pushes back:

shop is still a dependency of shop-e2e
Enter fullscreen mode Exit fullscreen mode

That's not an error — it's Nx protecting your architecture. It's telling you:

shop-e2e  ──▶  shop
Enter fullscreen mode Exit fullscreen mode

Remove the dependent project first, then work inward:

shop-e2e
   ↓
 shop
   ↓
feature libraries
Enter fullscreen mode Exit fullscreen mode

Always remove from the outside in.

A Solid Nx Monorepo Structure

Once you're building your own thing, a common, scalable layout looks like this:

workspace/
├── apps/
│   ├── web
│   ├── admin
│   ├── mobile
│   └── api
└── libs/
    ├── features/
    ├── ui/
    ├── data-access/
    ├── models/
    └── utilities/
Enter fullscreen mode Exit fullscreen mode

Workspace folder tree with apps/ (shop, shop-e2e, api) and packages/ holding the feature, ui, data and models libraries

The layers, and what each one owns

Applications — things you deploy. They wire everything together: routing, configuration, app bootstrap.

apps/web
apps/admin
apps/api
Enter fullscreen mode Exit fullscreen mode

Feature libraries — business functionality: pages, workflows, and rules.

feature-auth
feature-dashboard
feature-products
Enter fullscreen mode Exit fullscreen mode

UI libraries — reusable, presentational components with no business logic.

ui-button
ui-card
ui-modal
ui-table
Enter fullscreen mode Exit fullscreen mode

Data-access libraries — talk to APIs and manage state.

auth-data-access
products-data-access
api-client
Enter fullscreen mode Exit fullscreen mode

Models libraries — shared types and interfaces.

export interface User {
  id: string;
  name: string;
}
Enter fullscreen mode Exit fullscreen mode

This layering is what lets Nx enforce boundaries — for example, stopping a UI library from importing a feature, or a model from depending on data-access.

Three Mistakes I Made Early

1. Treating the monorepo like one big folder

A monorepo isn't big-folder-with-everything. Its value comes from boundaries, ownership, and dependency rules. Without those, you just have a large repo with extra config.

2. Creating too many libraries too soon

You do not need 100 libraries on day one. Create a library when there's a real reason:

  • code that's genuinely reused
  • a clear ownership boundary
  • a distinct business domain

Premature splitting adds friction with no payoff.

3. Ignoring the graph

The graph isn't decoration — it's the map of your system. If you're not looking at it, you're guessing.

A Workflow That Actually Works

  1. Create the workspace — npx create-nx-workspace@latest
  2. See what you have — npx nx show projects
  3. Visualize it — npx nx graph
  4. Remove anything you don't need — npx nx g @nx/workspace:remove <name>
  5. Generate your own libraries deliberately — apps in apps/, libraries in libs/
  6. Start building features

Final Thoughts

Nx isn't hard because of the commands. It's hard because a monorepo asks you to think about the shape of your system before you write much code.

Once applications, libraries, dependencies, and boundaries click, Nx becomes a genuinely powerful way to build and scale large applications.

The biggest lesson I took away:

Don't rush into writing code. First understand the shape of your system. A clean architecture today saves months of refactoring later.

If this helped, drop a ❤️ or a comment with how you structure your own Nx workspaces — I'd love to compare setups.

Top comments (0)