The Nest CLI: scaffolding, a watch mode, and the build step you will fight with bundlers
CLI tool for Nest applications 🍹
At a glance
- What is it?
- A 2.2k star TypeScript project that gives Nest applications a nest binary for generating code, running in development, and bundling for production.
- Who is it for?
- The Nest CLI is worth using precisely because Nest's dependency injection relies on file structure, and a generator that knows the conventions removes a category of mistakes you would otherwise make by hand.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 11, 2026, and from our analysis. They are not legal advice.
Editorial analysis
One global binary, three jobs
The package is published as `@nestjs/cli` and installs a single binary called `nest`:
$ npm install -g @nestjs/cliThe README describes that binary in three verbs: initialize, develop and maintain. Initialization means scaffolding a project. Development means serving it with reload. Maintenance means generating the pieces you add as the application grows, plus building and bundling for production distribution. The stated purpose is to embody architectural patterns that encourage well structured applications, which is a claim about defaults rather than about enforcement.
GitHub reports 2,199 stars and 471 forks, with the primary language TypeScript. The fork ratio is high relative to the star count, which fits a tool that gets installed into many projects and then customised.
The generator is Angular schematics under the hood
The one architectural detail worth knowing is that the CLI does not implement its own code generation. It builds on schematics, specifically `@angular-devkit/schematics` at version 22.2.0, with the Nest-specific collection living in `@nestjs/schematics`. That is why the CLI can offer module, controller, service and other generators with the behaviour Angular users already know, and why third party Nest generators are able to plug into the same pipeline.
The same dependency explains a good deal of the package's weight. Beyond the schematics packages, the dependency list includes `@inquirer/prompts` for interactive questions, `chokidar` for file watching, `commander` for argument parsing, `ora` for spinners, `ansi` colours, `cli-table3` for tabular output, `minimatch` and `jsonc-parser`, and `tsconfig-paths`. Typescript sits at `~6.0.2` as a direct dependency rather than a peer one, so the CLI brings its own compiler along.
The practical consequence for a reader: when a Nest generator behaves in a way you did not expect, the answer is often in the schematics package, not in this repository.
Node 20.11 and ES modules, which matters more than the README admits
The package metadata is stricter and more current than the README. The `engines` field requires Node `>= 20.11`, and the package sets `"type": "module"`, so the whole thing is ESM. It also declares `publishConfig.access` as public, which is why a `next` dist tag exists alongside the normal one and why you will see pre-release builds on npm.
Both details matter in practice. A global install on an older Node will fail in a way that does not look like a Node problem, and an ESM package that shells out to build tools has to be careful about how it invokes them.
The repository layout is organised around that split: `bin/` holds the entry point the binary points at, `commands/` holds the individual command implementations, `actions/` holds longer running work such as builds, `lib/` holds shared code, `tools/` holds maintenance scripts, and `test/` holds the suite. There are separate unit and end to end Vitest configs, `vitest.config.ts` and `vitest.e2e.config.ts`, with `test` running `vitest run` and `test:e2e` running the second config.
Twelve point zero is a bundler compatibility line
Read the 12.0.x releases together and a theme emerges: the work is about making builds agree with each other when different tools are in the pipeline.
Version 12.0.8, published 2026-09-28, fixes preserving CommonJS entry exports in rspack and webpack builds, and preserving parent links for aliased re-exports. Version 12.0.7 from 2026-09-25 forks the swc type checker with the application's own plugins, and fixes webpack resolving tsconfig absolute paths. Version 12.0.6 from 2026-09-24 resolves tsc path aliases from the tsconfig directory rather than the working directory, and bumps `@rspack/core` to 2.2.7 through Renovate.
Three separate fixes about module resolution in three days is a signal. Nest's decorator and metadata based dependency injection means the compiler has to see accurate paths and types, and any mismatch between what the type checker resolved and what the bundler resolved shows up as an injection failure at runtime rather than a build error. The repository was last pushed on 2026-09-28, the same day as the 12.0.8 release, so this line is actively being worked on.
Licensing, tooling and a repository that keeps two linters
The README states that Nest is MIT licensed and links to a `LICENSE` file at the root of the repository, while the package metadata carries `"license": "MIT"` and GitHub's own field for the repository reports no recognised licence identifier. All three point the same way in practice: the `LICENSE` file in the tree is the thing to read, and if your compliance tooling depends on GitHub resolving the licence field, you may need to supply the identification yourself.
The linting story is worth a look because it has been through a change. The `lint` script runs `oxlint` over `lib/`, `commands/` and `actions/`, and the root carries an `.oxlintrc.json`. The repository also carries `.prettierrc`, a `.commitlintrc.json`, a `renovate.json`, a `.release-it.json` and a `.husky/` directory, with the `prepare` script running husky plus a postinstall step. Formatting and linting are therefore separate tools with separate configs, and hooks run on commit rather than only in CI.
There is also a `.circleci/` directory alongside `.github/`, so at some point both CircleCI and GitHub Actions were configured. Releases are managed with release-it, and the presence of `.npmignore` and `.npmrc` tells you the published tarball is curated rather than the raw checkout.
What the README deliberately leaves to the documentation site
The Usage section of the README is a single sentence and a link to docs.nestjs.com. That is a deliberate choice, and it makes sense once you realise the command surface is large: project generation with prompts, generators for each building block, development serving with watch and reload, production builds, and bundler configuration. The README's job is to say the tool exists and how to install it.
So the README is an advertisement with accurate facts, not a manual. If you are evaluating the CLI, the questions worth asking are which generator names exist, how the development server reloads, and which bundler you end up with. None of those are answered on the README page, and all of them are answered at the documentation site it links.
For a different kind of answer, the repository itself is informative. Read `commands/` to see the actual command surface, `package.json` to see what the tool depends on, and the recent releases to see which build paths are currently being repaired. That is more current than any tutorial, and it is the only place that tells you what version you would actually install.
Editorial conclusion
The Nest CLI is worth using precisely because Nest's dependency injection relies on file structure, and a generator that knows the conventions removes a category of mistakes you would otherwise make by hand. What the README will not tell you is which compiler and bundler combinations actually work together, and that is where the 12.0.x patch releases are spending their effort: recent fixes cover CommonJS entry exports in rspack and webpack builds, tsc path aliases resolved from the tsconfig directory, and the swc type checker forked with the application's own plugins. Install the CLI globally, and if a build misbehaves, read the last few release notes before debugging your own configuration.
Frequently asked questions
Is NestJS available on NPM?
Yes. The CLI is published as @nestjs/cli and installs globally with npm install -g @nestjs/cli, which puts a nest binary on your PATH. The package requires Node 20.11 or newer and is published as an ES module, with pre-release builds available under the next dist tag.
How do I run NestJS?
You use the nest binary from the globally installed @nestjs/cli, which scaffolds a project, serves it in development mode with reload, and builds it for production. The README itself does not list individual commands and sends you to the CLI overview page in the official documentation for that, so the exact flags are documented there rather than in the repository README.
What is NestJS used for?
Nest is described in this repository's README as a progressive Node.js framework for building scalable server side applications, and the CLI is the tool around it for scaffolding, developing and maintaining those applications. It leans on dependency injection and a module based structure, which is why the CLI includes code generators for the standard building blocks.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/nestjs-nest-cli)