Optimize Nx Monorepo Management
Production Nx monorepo patterns - library types, module boundaries, affected-based CI, and remote caching configuration.
Why it matters
Streamline your Nx monorepo development with production-ready patterns. This asset provides best practices for setting up, configuring, and optimizing your Nx workspaces for efficient CI and dependency management.
Outcomes
What it gets done
Configure project boundaries and dependencies within Nx workspaces.
Optimize CI pipelines using Nx's affected commands and remote caching.
Implement best practices for Nx workspace architecture and library types.
Generate custom Nx project structures and configurations.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-nx-workspace-patterns | bash Overview
Nx Workspace Patterns
Production Nx monorepo patterns covering workspace architecture, library types, module-boundary rules, a custom generator, affected-based CI, and remote caching with Nx Cloud or S3. Use when setting up or hardening an Nx workspace's structure, boundaries, CI, or caching, not for non-Nx monorepo tooling.
What it does
Production patterns for managing an Nx monorepo: workspace architecture (apps/ for deployable applications, libs/ for shared libraries, tools/ for custom executors and generators, governed by nx.json and workspace.json), a five-type library taxonomy (feature for smart components and business logic, ui for presentational components, data-access for API calls and state, util for pure helper functions, shell for app bootstrapping), and six ready-to-use configuration templates: an nx.json with cacheable operations (build, lint, test, e2e, build-storybook), target defaults, and named inputs separating production from spec and test files; a project.json for an application target with webpack build and serve executors and dev/production configurations; module-boundary ESLint rules that constrain which library tags can depend on which others, so apps can depend on feature, ui, data-access, or util libs, ui can only depend on ui or util, and scope-based constraints keep scope:web from depending on scope:api; a custom Nx generator, a TypeScript function wrapping the built-in library generator to scaffold a tagged feature library with custom files; a GitHub Actions CI workflow that uses nx affected for lint, test, build, and e2e so only projects touched by a change are re-tested, driven by nrwl/nx-set-shas to compute the diff base; and remote caching setup for both Nx Cloud and a self-hosted S3-backed cache runner. It also lists the standard Nx CLI commands for generating a tagged library, running affected tests, viewing the dependency graph, building with a configuration, resetting the cache, and running workspace migrations.
When to use - and when NOT to
Use when setting up a new Nx workspace, configuring module or project boundaries with tags, optimizing CI to only build and test affected projects, implementing remote build caching, managing inter-project dependencies, or migrating an existing codebase into Nx. Not for non-monorepo projects or monorepos managed with a different tool such as Turborepo, Lerna, or Bazel, where these specific nx.json and project.json shapes and nx affected semantics don't apply.
Inputs and outputs
Input is the workspace's app and library structure plus its build, test, and lint targets. Output is a set of configuration files (nx.json, project.json per project, ESLint module-boundary rules, a CI workflow using affected commands, and remote-cache configuration) and, where needed, a custom generator for scaffolding new libraries consistently.
### Generate new library
nx g @nx/react:lib feature-auth --directory=libs/web --tags=type:feature,scope:web
### Run affected tests
nx affected -t test --base=main
### View dependency graph
nx graph
### Run specific project
nx build web --configuration=production
### Reset cache
nx reset
### Run migrations
nx migrate latest
nx migrate --run-migrations
Integrations
Built on the Nx CLI and @nx/devkit, with @nx/react, @nx/webpack, @nx/jest, and @nx/eslint executors, GitHub Actions for CI, and either Nx Cloud or a self-hosted S3 cache runner (@nx-aws-cache/nx-aws-cache) for remote caching.
Who it's for
Frontend and full-stack teams running an Nx monorepo who need concrete, copy-pasteable configuration for module boundaries, CI affected-command optimization, and remote caching rather than assembling Nx conventions from the docs each time.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.