TSH Stack: Node.js
tsh-stack-nodejs carries TSH's conventions for TypeScript on Node.js: the compiler configuration for a Node runtime, how to model types in a backend, and NestJS API implementation and review.
A stack in this marketplace is a runtime target, not a language. Browser-targeted TypeScript lives in tsh-stack-frontend, because a bundled app and a Node service need genuinely different compiler configuration, and because most projects have a frontend whatever their backend is written in. A fullstack TypeScript repository installs both plugins. Framework skills live inside their runtime's plugin: implementing-nestjs-api belongs here, not in a separate NestJS plugin.
Who installs it and where
Install it at project scope, so it travels with the repository: the repository already knows what it runs on. Your discipline plugin (for example tsh-product-engineering) and tsh-core travel with you at user scope. The install commands live on the installation page, which renders the repository README, so they are not repeated here.
Once installed, skills are invoked as /tsh-stack-nodejs:<skill>. Release notes are on the changelog page.
What it ships
| Skill | Invoke | What it does |
|---|---|---|
| configuring-typescript-for-nodejs | /tsh-stack-nodejs:configuring-typescript-for-nodejs | Configures TypeScript for Node.js server projects: which version to pin, the tsconfig baseline for a Node-resolved runtime, and the decorator-metadata settings NestJS and TypeORM require. Use when starting a Node service, editing a server tsconfig, diagnosing emitDecoratorMetadata or class-field problems, or upgrading TypeScript in a backend. |
| implementing-nestjs-api | /tsh-stack-nodejs:implementing-nestjs-api | Guides implementation and review of NestJS 11 REST APIs with TypeScript, @nestjs/cqrs, TypeORM 0.3, and @nestjs/platform-express. Use when bootstrapping a service, organizing vertical feature slices, adding CQRS behavior, implementing a REST API change, or reviewing a NestJS change — a command or query handler, module, TypeORM repository, or DTO — for framework, CQRS, persistence and testability risks. |
| modelling-types-for-nodejs | /tsh-stack-nodejs:modelling-types-for-nodejs | How to express a type in a Node.js/TypeScript backend so the compiler catches the bug instead of the runtime: discriminated unions that make illegal states unrepresentable, branded ids, const-object unions over enums, satisfies, unknown over any, and validating every boundary into a schema-derived type. Use when deciding how to model a DTO, entity, command or event payload, choosing union versus enum or interface versus type, or reviewing backend code for any, unsafe casts, or types that lie. |
All three skills are model-invocable: Claude loads them when the work matches their description, so you do not have to type the command.
How the skills layer
The three skills build on each other, and because they ship in one plugin, the links between them always resolve.
| Layer | Skill | Owns |
|---|---|---|
| Compiler baseline | configuring-typescript-for-nodejs | Version pin, tsconfig.json baseline for a Node runtime, decorator-metadata and class-field settings |
| Type shapes | modelling-types-for-nodejs | How to express a backend type so illegal states cannot compile |
| Framework | implementing-nestjs-api | NestJS module, CQRS, TypeORM and REST guidance, on top of the compiler baseline |
Near-twins in other stack plugins
configuring-typescript-for-nodejs has a near-twin, configuring-typescript-for-frontend, in tsh-stack-frontend. Version policy, the strictness ladder and the upgrade procedure exist in both on purpose, because a skill cannot link across plugins. The target-specific parts stay different. tsh-stack-serverless carries a third relative, configuring-typescript-for-serverless, for bundler-emitted Lambda code.
MCP servers, hooks and agents
This plugin ships no agents, no .mcp.json and no hooks.
Not covered yet
The plugin README lists these gaps as deliberate scope:
- Build toolchain choice:
tscversus SWC versus esbuild versustsx. The type-gate rule is covered, but picking the transpiler is not. - Monorepo project references beyond a short note.
- Non-Nest frameworks: Express, Fastify and Hono have no skill of their own.