generator-jhipster-nodejs: a NestJS backend blueprint for JHipster

What generator-jhipster-nodejs replaces, and for whom

A standard JHipster application generates a Java Spring Boot backend and an Angular, React or Vue client. This blueprint keeps the client and replaces the backend with NestJS, generating TypeScript files rather than Java. The README is explicit about that split: "The UI is inherited from standard JHipster app client. So only backend generation changes." The audience is therefore narrow and specific. You already use JHipster, or you want its entity subgenerator and JDL import, and your team writes TypeScript rather than Java. If neither of those is true, the blueprint adds a layer without removing one.

The generated backend is not bare NestJS. According to the README, the generator applies a standard configuration: web controllers, Swagger documentation through the nestjs/swagger package, and JWT or OAuth2 passport authentication services. It also seeds the database with four users covering admin, basic user and anonymous roles, which mirrors the standard JHipster monolithic application. TypeORM handles persistence and, per the README, is also used for "the automatically migration and versioning of the database scripts". That last point matters more than it looks. Schema migration is usually the part teams hand-roll first, and here it comes out of the generator.

How the blueprint plugs into the JHipster generator pipeline

The repository is laid out as a Yeoman generator, with generators/ holding the templates and cli/ holding the command-line entry point. The package.json declares "type": "module" and points main at generators/app/index.js, while the bin field maps the nhipster command to cli/cli.cjs. The primary language listed for the repository is EJS, which is consistent with a blueprint whose job is rendering templates rather than shipping runtime code: the artifact you care about is the application it writes into your working directory, not the generator itself.

Because it is a blueprint, it does not run standalone. The README frames it as something "meant to be used in a JHipster application" and lists JHipster and its related tools as prerequisites, including Yeoman. The generation flow is: you have JHipster installed, you install this package globally, and you invoke nhipster instead of jhipster. The CLI is described as a shortcut, and the README lists three things it supports: general app generation via a bare nhipster, JDL model support via nhipster jdl my_file.jdl, and CI/CD generation via nhipster ci-cd. Sample JDL models live in the .blueprint/generate-sample/templates/samples folder and in the separate jhipster/jdl-samples repository.

One design consequence is worth stating plainly. Since the client is untouched, the practical way to evaluate this project is to read generated code, not to click around a demo. The README says as much, noting that a live app is "less useful than the code and the app structure" and pointing at three sample repositories instead: a React client with Okta OAuth2, an Angular client with JWT auth, and a Vue.js client with MongoDB.

Installing the blueprint and generating a first app

The README requires JHipster and Yeoman to be installed first, following the JHipster installation guide, and it pins Node.js 14.16.0 with an emphatic note: "Please attention to install that node.js version!!" Treat that as a hard constraint rather than a suggestion. A global install brings in the nhipster binary.

npm install -g generator-jhipster-nodejs

After that, generation happens through the blueprint's own command. Running it bare starts the interactive questionnaire, the same shape as jhipster, where you answer the database and authentication questions.

nhipster

If you already have a JDL model describing entities and relationships, the README documents a single-command path that skips the questionnaire. The sample models referenced by the README live in .blueprint/generate-sample/templates/samples and in the jhipster/jdl-samples repository.

nhipster jdl my_file.jdl

There is also a Docker route for people who would rather not install the toolchain on their machine. The README's steps download the Dockerfile from the repository's docker directory, build an image tagged jhipster-generator-nodejs:latest, create an empty app folder, and then run the image with the current directory mounted into /home/jhipster/app.

docker run -it --rm -v $PWD:/home/jhipster/app jhipster-generator-nodejs

What you should see is a generated project directory containing a NestJS backend in TypeScript alongside the client you selected. Updating later is a single global command, either npm update -g generator-jhipster-nodejs or yarn global upgrade generator-jhipster-nodejs.

MongoDB is experimental, and the README says so twice

The clearest limitation is stated in the project's own description and repeated in the README: MongoDB support is experimental in TypeORM, and therefore experimental in JHipster NodeJS. The README links to the TypeORM README as the source of that status. This is not a footnote about an edge case. It means that if your data model needs a document store, the persistence layer underneath you carries an experimental label from its own maintainers, and the blueprint inherits it.

The practical default is SQL. The README describes SQLite for development and a configurable SQL database for production, with the generator asking which database you want. The Vue.js sample repository is the one the README points at for a MongoDB setup, which suggests the path exists and is demonstrated, but a sample is not a support commitment.

A second constraint is the Node.js version. Pinning to 14.16.0 in the prerequisites is unusually specific, and it interacts badly with the rest of your toolchain if you run several Node projects on one machine. The README does not document a supported range, only that single version, so the safe reading is that other versions are untested rather than forbidden.

A third gap is operational rather than technical. The README documents how to install and how to generate, and it points at CONTRIBUTING.md and a ROADMAP.md for contributors. It does not document rollback, nor how to regenerate an application after the blueprint is upgraded, nor what happens to hand-edited generated files on the next run. For a generator that writes a whole application into your repository, that silence is the thing to probe before you commit a real project to it.

Compared with plain JHipster and with NestJS CLI

The obvious alternative is stock JHipster itself. The difference is the backend language and runtime: stock JHipster generates Spring Boot in Java, this blueprint generates NestJS in TypeScript. Everything else in the README's description is framed as inherited, including the client and the four seed users with admin, basic user and anonymous roles. So the decision is not "JHipster or this" in terms of features. It is whether you want a JVM in your deployment at all. If your team already runs Java services and your build pipeline is Maven-shaped, stock JHipster is the lower-friction choice and this blueprint buys you nothing. If your team is TypeScript-first and would otherwise maintain a hand-written NestJS backend next to a generated client, the blueprint is what keeps the two in sync through JDL.

The other alternative is the NestJS CLI plus hand-written modules, which is what most NestJS teams do. That gives you full control and no generator opinions. What you give up is the entity subgenerator, the JDL import, and the TypeORM migration generation the README attributes to this blueprint. Those are the parts that are tedious to build yourself and easy to get subtly wrong. The honest comparison is that the NestJS CLI scales with your patience, while this blueprint scales with how closely your application resembles the JHipster model of entities, roles and a REST API.

Maintenance, release cadence and licence

The repository is not archived. Its last push was on 2026-07-21, and that same date carries release v4.0.0. The two releases before it were v3.2.0 on 2025-04-03 and v3.1.0 on 2025-02-20, so the gap between v3.2.0 and v4.0.0 is roughly fifteen months. That is a slow but real cadence, and the major version bump suggests breaking changes rather than a patch. The package declares jhipster-8 among its keywords, which tells you which JHipster generation the current release targets. If you are on a different JHipster major version, check compatibility before upgrading, because the README does not publish a compatibility matrix.

Upgrade cost has two layers. Updating the generator is one global npm or yarn command. Regenerating an existing application is the expensive part, and the README does not describe how conflicts between generated and hand-edited files are resolved. Plan on treating generated output as the source of truth and keeping your own code in files the generator does not own.

The licence is Apache-2.0, declared in both package.json and the LICENSE.txt file at the repository root. Apache-2.0 is permissive and includes an explicit patent grant, and the repository also carries a NOTICE file, which the licence expects you to preserve in redistributions. That is a description of the files present, not legal advice; if you redistribute the generator or embed it in a product, have counsel read the NOTICE and LICENSE.txt rather than relying on this paragraph.

Editorial conclusion

Adopt generator-jhipster-nodejs if your team writes TypeScript, wants NestJS controllers and TypeORM migrations generated for you, and is comfortable pinning Node.js 14.16.0 as the README instructs. Skip it if you need MongoDB in production, since the README states MongoDB support is experimental in TypeORM and therefore in JHipster NodeJS, or if you are not already running JHipster. Before committing, generate one throwaway app with nhipster, confirm the CLI lands in your PATH, and check whether the SQL database you actually run in production is among the options the generator prompts for.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes