Optimize Nx Monorepo Management

This skill covers production patterns for Nx monorepo management. It describes the Nx workspace architecture (apps/ for deployable applications, libs/ for shared libraries, tools/ for custom executors/generators, nx.json and workspace.json for configuration) and five library types by purpose - feature (smart components, business logic), ui (presentational components), data-access (API calls, state management), util (pure functions, helpers), and shell (app bootstrapping). It provides six templates: an nx.json configuration with cacheable operations, target defaults (build/test/lint/e2e with dependency and input rules), named inputs distinguishing production from test/lint config files, and React generator defaults; a project.json for a web app defining build/serve/test/lint targets with development and production configurations; module boundary rules via @nx/enforce-module-boundaries in ESLint, constraining which type: and scope: tags may depend on which; a custom TypeScript generator (featureLibraryGenerator) that wraps libraryGenerator to scaffold a tagged feature library and inject template files; a GitHub Actions CI workflow deriving affected SHAs (nrwl/nx-set-shas) and running nx affected for lint, test, build, and e2e in parallel; and remote caching setup both via Nx Cloud (accessToken, cacheDirectory) and a self-hosted S3-backed cache runner. It lists common commands (nx g @nx/react:lib, nx affected -t test --base=main, nx graph, nx build --configuration=production, nx reset, nx migrate), and a Do's/Don'ts list: use tags consistently and enforce them with module boundaries, enable caching early for CI savings, keep libraries single-responsibility, use generators for consistency, and document boundaries for new developers - versus creating circular dependencies, skipping affected-only testing, ignoring boundary violations, or over-granularizing the library count.

Use it for setting up new Nx workspaces, configuring project boundaries, optimizing CI with affected commands, implementing remote caching, managing dependencies between projects, or migrating to Nx. It does not apply outside Nx workspace patterns - a different domain or tool is out of scope.

Inputs: the monorepo's apps and libraries, their intended type/scope tags, and CI/caching requirements. Outputs: nx.json/project.json configuration, ESLint module-boundary rules, a CI workflow running only affected targets, a remote-caching configuration (Nx Cloud or self-hosted), and, optionally, a custom generator for scaffolding new libraries consistently.

Nx (@nx/react, @nx/webpack, @nx/jest, @nx/eslint, @nx/devkit), ESLint's @nx/enforce-module-boundaries rule, GitHub Actions with nrwl/nx-set-shas, and Nx Cloud or a self-hosted S3 cache runner (@nx-aws-cache/nx-aws-cache).

# 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

Frontend and platform engineers managing an Nx monorepo who need correct module boundaries, affected-command CI, and remote caching rather than an unenforced, slow-to-build workspace.