nest-cli

@nestjs/cli is the official command-line tool for the NestJS framework, handling everything from project scaffolding to production builds. It wraps Angular DevKit’s schematics engine to generate controllers, modules, services, and other building blocks through the nest generate command, while nest new bootstraps a complete project structure with your choice of package manager.

Under the hood, the CLI supports interchangeable compiler backends — tsc, Webpack, and the newer SWC/rspack pipeline — selectable per project via nest-cli.json, along with a watch mode for incremental rebuilds during development. Additional commands cover monorepo project management, third-party library installation (nest add), guided major-version upgrades (nest upgrade), and deployment to NestJS Mau through an on-demand companion binary.

What You Get

• Project scaffolding via nest new with interactive package-manager and configuration prompts
• Schematics-driven code generation (nest generate) for modules, controllers, services, and more, backed by @nestjs/schematics with support for custom collections
• Pluggable compiler backends (tsc, Webpack, and SWC/rspack) selectable per project, with a watch mode for incremental development builds
• Monorepo support for managing multiple apps and libraries from one nest-cli.json configuration
• nest add for installing and wiring up NestJS ecosystem libraries in one step
• nest upgrade for guided, schematics-driven migration to new major NestJS versions
• One-command deployment to NestJS Mau via an on-demand companion binary

Common Use Cases

• Bootstrapping a new NestJS project with a chosen package manager and TypeScript configuration
• Generating boilerplate for a new REST resource (module + controller + service + DTOs) in one command
• Switching a project’s build pipeline from Webpack to SWC for faster incremental compiles
• Managing a monorepo with multiple NestJS apps and shared libraries under one CLI
• Running guided upgrades when migrating an existing app to a new major NestJS release

Under The Hood

Architecture

The CLI is organized as a thin bin/nest.ts entrypoint that boots a Commander.js program and hands off to commands/command.loader.ts, which registers one Command/Action pair per verb (NewCommand/NewAction, BuildCommand/BuildAction, GenerateCommand/GenerateAction, and so on) — a clean command-pattern separation where each commands/*.command.ts only parses CLI options into a typed context object and each actions/*.action.ts extends AbstractAction to perform the actual work. Cross-cutting concerns live in dedicated lib/ subsystems: lib/configuration loads and merges nest-cli.json, lib/schematics wraps Angular DevKit’s schematics engine behind an AbstractCollection/CollectionFactory so nest generate, nest add, and nest upgrade all share one schematic-execution path, lib/compiler swaps between Webpack, rspack, and a plain tsc-based compiler behind a common interface selected via nest-cli.json’s builder field, and lib/runners normalizes package-manager invocations behind an AbstractRunner/RunnerFactory pair. This layering means a new package manager or compiler backend can be added by implementing one interface rather than touching the command layer, and the deploy action’s lazy install-on-first-use pattern for the companion Mau binary shows the same swap-in-a-dependency philosophy applied to an entire external command.

Tech Stack

Built as an ESM-only TypeScript codebase with strict mode enabled, the CLI layers Commander.js for argument parsing, Inquirer for interactive prompts, and lightweight terminal-UI helpers for colors, spinners, and tables. Code generation delegates to Angular DevKit’s schematics packages and the official NestJS schematics collection rather than reimplementing a template engine. Build backends span multiple toolchains simultaneously — Webpack, rspack, and SWC — all declared as optional peer dependencies so a project only installs the one it actually uses, with path-alias resolution plugins wired in for each. A file-watching library powers incremental rebuilds, a glob-matching library handles the asset manager’s copy rules, and the package ships its own compiled output through a dedicated build step plus Git-hook-driven linting and formatting on commit.

Code Quality

The test suite is extensive, with unit specs mirroring the actions/, commands/, and lib/ source tree closely, plus a separate end-to-end suite that exercises real command invocations rather than only mocking collaborators. Strict TypeScript is enabled across the whole source tree, error handling favors typed catch guards that check error instanceof Error over swallowing exceptions, and naming is consistent throughout (matching Command/Action pairs, shared abstract base classes). Continuous integration runs install, build, and test on every push, a linter and formatter enforce style, and pre-commit hooks gate what reaches the repository — together a well-tested, typed, and CI-enforced codebase.

API Design The CLI’s public surface is a small, memorable verb set — new, generate, build, start, add, upgrade, deploy, info — with consistent flag conventions across commands, and getting started requires a single scaffolding command with no manual configuration authoring beforehand. Ergonomics lean on existing ecosystem conventions rather than inventing new ones: schematics for code generation matching Angular’s model, Commander for argument parsing, and interactive prompts as a fallback when required flags are omitted. The main friction point is the peer-dependency surface for build backends — a project must know which compiler package to install depending on its chosen builder — but this is a deliberate flexibility tradeoff made explicit through optional peer-dependency metadata rather than a hidden requirement.