CodeVetter · Repo Unpack · Contributor handoff
nrwl/nx
Begin with the owning package and follow the smallest concrete command or API path before changing shared orchestration. Tests and CI were inspected, not executed, and this inventory is bounded rather than exhaustive. Native builds, inferred targets, export conditions, and cache relocation make seemingly local changes cross several boundaries. Validation commands below are future workflow guidance; none were run during this read-only investigation.
- Read AGENTS.md and owning package configuration first; use the root pnpm 12.4.2 pin and workspace package membership, including native packages and separate example workspaces.
- Treat explicit project targets as partial configuration: workspace targetDefaults add dependency/cache behavior, and plugins infer TypeScript, Jest, Playwright, Next, Gradle, and .NET targets with include/exclude rules.
- For CLI changes, read bin/nx.ts, init-local.ts, nx-commands.ts, and the command handler together; preserve completion/version initialization shortcuts and global-to-local delegation.
- For cache changes, read cache-directory.ts and db-connection.ts together: relocation is memoized, environment/configured paths disable sharing, and artifact/database scope must stay aligned while running-task state remains local.
- Keep source implementations separate from generated distributions; package exports select TypeScript under @nx/nx-source and dist otherwise, while native build outputs include bindings and generated declarations.
- Core test edits must respect Vitest's fork pool and source conditions; its setup notes that lazy require-loaded modules are separate from Vite imports and do not see vi.mock, and its preload guard blocks writes to the real root nx.json/package.json.
- For a separately authorized change, the documented sequence is project test/build/lint, affected build/test/lint, affected e2e-local, and nx prepush before committing, with package-manager-prefixed Nx commands. Tests and CI here were inspected, not executed; no passing status is established.
- Documentation work starts with astro-docs/README.md and edits .mdoc/.mdx content; plugin/CLI references derive from implementation schemas and require rebuild/restart. CONTRIBUTING.md still describes the older docs layout, so use the current documentation-specific guidance.