nx-workspace-patterns

Create the workspace structure with apps/ for deployables and libs/ for shared code, then configure nx.json with cacheable operations, target defaults, and named inputs. Use Nx generators to scaffold applications and libraries with consistent settings.

Use the @nx/enforce-module-boundaries ESLint rule with depConstraints based on project tags. Assign tags like type:feature or scope:shared to projects, then define which tag combinations may depend on each other.

Nx affected commands compare the current branch against a base SHA to identify only changed projects, then run lint, test, and build targets solely on those. This avoids rebuilding the entire monorepo on every pull request.

Yes, Nx supports remote caching through Nx Cloud by setting the tasks runner to nx-cloud with an access token, or through self-hosted options like @nx-aws-cache/nx-aws-cache backed by an S3 bucket.

Common library types are feature (business logic), ui (presentational components), data-access (API and state), util (pure helpers), and shell (app bootstrapping). Keeping each library focused on one type prevents circular dependencies.

Avoid over-granularizing when libraries become too small to justify their maintenance overhead, since each library adds build graph complexity. Balance library count against team ownership and actual reuse needs.