Exploring a modern Nx-native NestJS v12 plugin aligned with Nest CLI and Project Crystal

Originally posted by vrxj81 April 28, 2026 Hi Nx team and community,

I’m currently exploring the design of a modern Nx-native NestJS plugin aligned with the upcoming NestJS v12 direction, and I’d like to ask for early feedback from the Nx core team and community before investing too much implementation effort.

This is not meant as a complaint about the existing @nx/nest plugin. The current plugin has served the ecosystem well. The question is whether the NestJS v12 shift creates an opportunity — or need — for a more modern integration model.

Context

From what I understand, NestJS v12 is moving more strongly toward:

• ESM-first / modern Node.js conventions
• SWC-based build workflows
• Vitest-friendly testing setups
• stronger alignment with the official Nest CLI
• less reliance on older Angular-era schematic assumptions
• potentially more schema-first / Standard Schema-oriented validation patterns
• continued support for Fastify as a serious platform option

At the same time, Nx has evolved significantly with:

• Project Crystal
• inferred targets
• plugin-based workspace intelligence
• stronger support for polyglot / framework-specific tooling without requiring every target to be manually configured

That raises the question:

Should a future NestJS v12 integration for Nx continue the current pattern of deeply wrapping/generating Nest projects, or should it delegate framework scaffolding to the official Nest CLI where possible and focus the Nx plugin on workspace integration, target inference, and monorepo ergonomics?

Current thinking

The design principle I’m exploring is:

Nest owns framework generation. Nx owns workspace orchestration. Optional architecture conventions should be explicit and configurable.

In practical terms, this would mean a plugin that:

• delegates as much Nest-specific scaffolding as possible to the official Nest CLI

• avoids copying Nest templates into the Nx plugin

• adds Nx workspace intelligence on top:

  • project registration
  • tags
  • source roots
  • path aliases
  • project graph integration
  • module boundary support
  • target inference

• supports Project Crystal-style inferred targets for:

  • serve
  • build
  • test
  • lint
  • possibly e2e

• aligns with Nest v12 defaults:

  • ESM-first
  • SWC-first
  • Vitest-first where appropriate

• treats Fastify as a first-class option

• provides a migration path for existing Nx/Nest projects

Possible plugin shape

The current architecture I’m considering is roughly:

packages/nest
├── core/
│   ├── create-nodes.ts
│   ├── detect-nest-project.ts
│   └── infer-targets.ts
├── cli-adapter/
│   ├── run-nest-cli.ts
│   ├── map-options.ts
│   └── patch-generated-output.ts
├── generators/
│   ├── application/
│   ├── library/
│   └── resource/
├── config/
│   ├── configure-esm.ts
│   ├── configure-swc.ts
│   └── configure-vitest.ts
├── fastify/
│   ├── configure-fastify.ts
│   └── patch-bootstrap.ts
├── schema/
│   └── configure-schema-validation.ts
└── migrations/
    └── migrate-nx-nest-to-v12.ts

Generator strategy

The main distinction would be between three categories:

1. Hybrid Nx/Nest generators

These would use the Nest CLI where possible, then apply Nx-specific workspace integration.

Examples:

nx g @anarchitects/nest:application my-api
nx g @anarchitects/nest:library users

The application generator would likely:

1. invoke the Nest CLI
2. configure the generated project for Nest v12-style defaults
3. add Nx metadata and/or enable target inference
4. integrate with the Nx project graph and workspace boundaries

2. Thin CLI delegation

For generators that Nest already owns well, the Nx plugin should avoid duplicating behavior.

Examples:

• controller
• service
• module
• provider
• guard
• interceptor
• pipe
• filter
• middleware
• gateway
• resolver
• class
• interface
• decorator

The open question is whether these should be exposed as Nx generators at all, or whether users should simply call the Nest CLI directly inside the workspace.

3. Value-add generators

Some generators might justify Nx-specific or Anarchitects-specific behavior.

Examples:

nx g @anarchitects/nest:resource users --schema zod --platform fastify

This is where the plugin could add value beyond the Nest CLI by supporting:

• schema-first scaffolding
• Fastify bootstrap integration
• Nx path awareness
• architectural conventions

Target inference idea

Rather than creating many explicit targets in project.json, the plugin could infer common targets from Nest/Vitest/ESLint configuration.

For example:

serve -> nest start -b swc
build -> nest build
test  -> vitest run
lint  -> eslint

The detection could be based on signals such as:

• nest-cli.json
• src/main.ts
• @nestjs/core dependency
• Vitest/Jest config
• ESLint config

The goal would be to keep generated projects close to standard Nest projects while still making them feel native inside Nx.

Main questions for the Nx team/community

I would especially appreciate input on these points:

1. Is this direction aligned with where Nx sees framework plugins going, especially with Project Crystal and inferred targets?

2. For a NestJS v12-oriented plugin, would you recommend:

   • contributing directly to @nx/nest,
   • building a separate community plugin first,
   • or prototyping externally and later discussing upstream opportunities?

3. Does a CLI-delegation approach fit well with Nx plugin best practices, or are there pitfalls around reproducibility, dry-runs, generators, and task hashing that I should consider early?

4. Should Nest artifact generators be re-exposed as Nx generators, or is it better to document direct Nest CLI usage for those?

5. For inferred targets, would the preferred implementation be to avoid custom executors entirely and infer plain command targets?

6. Are there existing Nx plugin patterns or packages I should study before implementing this?

7. How should migration from existing @nx/nest projects be approached?

   • explicit migration generator
   • automatic inference compatibility
   • documentation-only
   • or a staged approach?

Why I’m asking early

I’m trying to avoid building another plugin that simply copies framework templates and slowly drifts away from the framework itself.

The goal is to help the Nx + Nest ecosystem transition smoothly to NestJS v12 by keeping Nest as the source of truth for framework scaffolding, while using Nx for what it is very strong at: workspace intelligence, project graph integration, inferred targets, and monorepo ergonomics.

Any feedback, concerns, recommendations, or pointers to existing Nx internals would be very welcome.

Thanks!