Skip to main content
nestrs generate (aliased as nestrs g) creates individual source files or full multi-file resource scaffolds from built-in templates. Every generated file uses real nestrs macros and compiles out of the box. For resource generators, the CLI also automatically wires the new module into your parent main.rs, lib.rs, or mod.rs.

Syntax

<name> is converted to snake_case for file names and field references and to PascalCase for struct names automatically.

Generator kinds and aliases

Flags

Always run with --dry-run first when you are generating into an existing source tree. The CLI will print every file it would create — and show any parent module wiring — without touching the disk.

File naming: --style nest vs --style rust

Files are named <stem>.<kind>.rs, matching the Nest CLI convention:
The mod.rs uses #[path = "..."] attributes to load the dotted filenames.

Automatic parent module wiring

After generating a resource, the CLI searches the --path directory for main.rs, lib.rs, or mod.rs in that order. If it finds one, it appends:
If no parent file is found, it prints the lines to add manually:
Automatic wiring only touches main.rs, lib.rs, or mod.rs. It will not modify arbitrary Rust files.

Resource generator: transport options

The resource generator is the most complete generator — it creates a module, service, two DTOs, a mod.rs, and a transport-specific entry file in one command.
Each transport produces a different entry file while sharing the same CRUD service and DTOs.

Generated files per transport

Generator templates

The code below shows the exact template output for a generator named users (snake: users, pascal: Users). Real names are substituted at generation time.
The standalone resolver generator produces a bare stub. For a full GraphQL CRUD resolver, use nestrs g resource users --transport graphql.
The standalone gateway generator produces a bare stub. For a full WebSocket gateway, use nestrs g resource users --transport ws.
The standalone transport generator produces a bare stub. For full message patterns, use nestrs g resource users --transport microservice or --transport grpc.
Shared across all transport kinds. Uses an in-memory HashMap store — swap it for a real database in production.
The REST controller registers five routes and includes optional OpenAPI attributes. Add features = ["openapi"] to nestrs in Cargo.toml and chain .enable_openapi() on NestFactory to activate the /openapi.json endpoint.
Requires nestrs = { version = "...", features = ["graphql"] } and async-graphql = "=7.0.17" in Cargo.toml. Wire the schema in main.rs via app.enable_graphql(schema).
Requires nestrs = { version = "...", features = ["ws"] }. Client frames use { "event": "...", "data": { ... } } JSON envelopes.
Requires nestrs features microservices and microservices-grpc. Bootstrap with NestFactory::create_microservice_grpc::<RootModule>(...).
Requires the microservices feature. Bootstrap with NestFactory::create_microservice::<RootModule>(...). The generated code is identical to the gRPC transport except for the bootstrap method and the excluded microservices-grpc feature requirement.
Both DTOs are generated for every resource regardless of transport.
The #[module] declaration varies by transport to wire the correct providers and controllers.

Examples

The generator will refuse to overwrite existing files unless you pass --force. Run with --dry-run first to preview output and avoid accidentally clobbering files in an existing module directory.