@neohm/nh-cli — nh

A scaffolding CLI that accelerates development on neohm. NestJS projects built on top of the shared @neohm/nestend library.

nh generates fully wired modules, entities, controllers, DTOs, data processors, migrations and seeds — and keeps your import barrels (es6.classes.ts) and app.module.ts registration in sync, so the project builds without any manual import wiring.

Every generated artifact matches the conventions of the nestjs-boilerplate reference project:

• Filenames are dot.separated.lowercase (no hyphens) — e.g. shape.entity.ts, and a multi-word RoundShape becomes round.shape.entity.ts.
• Class names are PascalCase — e.g. ShapeEntity, AddShapeDataDto.

Installation

# from the neohm-cli directory
npm install
npm link            # exposes `nh` globally

# or run without linking
npx nh --help

Run nh from inside a target NestJS project (e.g. nestjs-boilerplate). The project root is auto-detected by walking up from the current directory for a package.json next to a src/ folder.

Commands

| Command | Description | | --------------------- | ---------------------------------------------------------------------------------------------------------------- | | nh gen | Interactive wizard: scaffold a module + entity + optional controller/DTO/processor/migration, then auto-wire it. | | nh migration | Generate a standalone migration <timestamp>M-<Name>.ts. | | nh seed | Generate a seed file <timestamp>S-<Name>.ts. | | nh sync | Rebuild every es6.classes.ts barrel and register modules in app.module.ts. | | nh check | Dry-run of sync — show what would change without writing. | | nh list | List scaffolded modules with their entities and providers. | | nh remove <name> | Safely remove a scaffolded module and de-register it (migrations are preserved). | | nh --help / nh -v | Help and version. |

nh gen

$ nh gen
? Module name (e.g. shape): shape
? Entity name (e.g. Shape): Shape
? Table name (e.g. nh_shapes): nh_shapes
? Create controller (ShapeController)? Yes
? Create DTO (AddShapeDataDto)? Yes
? Create data processor (ShapeDataProcessor)? Yes
? Create listing processor (ShapeListProcessor)? Yes
? Create migration (M-AddShapeTable)? Yes

Produces, under src/shape/:

shape/
  shape.module.ts                    # ShapeModule (imports CommonModule, QueueModule, ...)
  es6.classes.ts                     # barrel of controllers/services/jobs/subscribers
  controllers/shape.controller.ts
  dtos/add.shape.data.dto.ts
  dtos/shape.list.filter.dto.ts
  entities/shape.entity.ts
  libraries/shape.data.processor.ts
  libraries/shape.list.processor.ts
  enums/  jobs/  services/  subscribers/

plus src/database/migrations/<timestamp>M-AddShapeTable.ts, and it registers ShapeModule in src/app.module.ts.

It also registers the entity and its job in the project constant registries — shapeJob: 'shape.job' in src/constants/job.constants.ts (which the generated job references as JobConstants.shapeJob) and shape: 'shape' in src/constants/entity.constants.ts — and mirrors them in the identifier → class map registries: [JobConstants.shapeJob]: ShapeJob in src/constants/job.maps.ts and [EntityConstants.shape]: ShapeEntity in src/constants/entity.maps.ts (imports included). Missing registry files are created spreading baseJobConstants / baseEntityConstants / baseJobMaps / baseEntityMaps from @neohm/nestend; existing ones (whatever their export is named) just get the entry appended.

Generated artifacts extend the @neohm/nestend base classes:

• Entity → CommonEntity (with an empty attributes jsonb column)
• DTO → CommonPayloadDto
• Data processor → CommonDataProcessor (process() → validate() → set())
• List filter DTO → CommonListFilterDto (plus a custom_filter example field)
• Listing processor → CommonListProcessor (column allowlist config, id default sort, and an example custom filter)

When both a controller and a listing processor are generated, the controller ships with a POST list endpoint that runs the listing processor (with SqlService injected via the constructor).

• Migration → MigrationUtility
• Seed → SeederUtility

Re-running gen for an existing module reuses it and only adds new files — existing files are never overwritten.

nh sync and nh check

sync scans every module under src/ and regenerates its es6.classes.ts barrel from the files actually present in controllers/, services/, jobs/ and subscribers/, then ensures each module is imported and listed in app.module.ts. Files are classified by their folder and the presence of an exported class — not by a fragile filename suffix — so non-standard names are never silently dropped. The operation is idempotent.

check performs the same analysis but only prints what would change:

$ nh check
es6.classes barrels:
  ok      src/shape/es6.classes.ts
  update  src/test/es6.classes.ts
            + services: TestService

app.module.ts:
  ok      src/app.module.ts

Project layout

neohm-cli/
  bin/nh.js                 # executable entry
  src/index.js              # commander program
  src/commands/             # gen, migration, seed, sync, check, list, remove
  src/lib/naming.js         # word-splitting + case conversions
  src/lib/paths.js          # project-root detection
  src/lib/templates.js      # code templates
  src/lib/sync.engine.js    # module scan + barrel + app.module wiring
  src/lib/fs.utils.js       # safe writes + console reporting

See documentation.tex for the full technical reference.

Requirements

• Node.js (active LTS) and a recent npm
• A target project that depends on @neohm/nestend