express-generator-typescript: a TypeScript-first Express scaffolder

A generator for people who want no build step at all

The classic `express-generator` package produces a JavaScript project with no TypeScript, no linting and no test setup. express-generator-typescript exists to produce the same shape of project with those pieces already decided, and the repository description puts it as a CLI that generates a production-ready Express plus TypeScript project with prettier, ESLint and a working CRUD example baked in.

The distinguishing decision is the absence of a build step. The documentation says the generated project runs TypeScript directly with Node's built-in type stripping, with no build step in development or production. The server restarts when you change it and the browser refreshes when you change front-end files. There is no `tsc` in the loop and no `dist/` directory to keep out of version control.

That choice has a hard prerequisite, and it is the first thing to check. Installation requires Node.js 22.18 or newer in the 22 line, 24.x, or 26+, and the package manifest states the same constraint as `^22.18.0 || ^24.0.0 || >=26.0.0`. On an older Node version the whole premise fails, because the runtime cannot strip the types.

The intended user is a backend developer who wants an API service, not a server-rendered site. The documentation describes the defaults as aimed at APIs, suitable for SPAs, mobile backends or services, with no view engine, ORM or UI layer, only the essentials for Express and TypeScript.

The generated project is an ES module with a #src/* import alias

Two structural choices run through the generated code. The project is an ES module, and it comes with a `#src/*` import alias so that imports stay clean as the app grows.

The alias is the detail that matters after the first week. Without it, a file four directories deep has to import a sibling with a chain of relative paths, and every file move breaks the imports. The documentation states that the alias works in development, in tests and in production, which is the part that usually fails in a template, since an import alias configured only in `tsconfig.json` will not be understood by the runtime that strips the types, nor by the test runner, nor by ESLint.

The other structural point is what the project does not contain. There is no view engine, no ORM and no UI layer. The `views/` directory exists for HTML pages, and `public/` holds front-end scripts and styles, but nothing renders a template for you and nothing talks to a database.

That is a deliberate trade. A generator that includes an ORM makes a decision about your data layer and your migrations, and most teams would rather make that decision themselves. The cost is that the CRUD example it ships is wired to whatever minimal repository the template contains, and the first thing you do in a real project is replace it.

The generated app is a layered CRUD example you can argue with

The generated template is a small CRUD app for a `User` record, and the documentation is explicit that it exists to show how to structure models, services and routes in Express with TypeScript.

The layout is layered, and the documentation says so directly, adding that the layout suits a small CRUD app and that if you plan to grow it you should consider switching to a domain-based layout. The two patterns are explained in the Typescript Best Practices README that the project links to, and the generated structure is:

- config/         → .env files for each environment
- src/            → Source code
  - common/       → Shared code
    - classes/    → Shared classes (e.g. route errors)
    - constants/
      - Paths.ts  → Single source of truth for all API routes
    - types/      → Shared types
    - utils/      → Shared helper functions
  - entities/     → Describe and handle database records (one folder per entity)
  - routes/       → Read and validate values from Express requests; send responses
  - services/     → Business logic (where everything comes together)
  - repos/        → Talk to the database

Two conventions in that listing are worth copying whatever happens to the rest. The `routes/` layer reads and validates request values and sends responses, while `services/` holds business logic, and `repos/` talks to the database. Separating the three means a handler cannot quietly contain a query, which is the failure mode that makes a small Express codebase expensive to change later.

The `common/constants/Paths.ts` file is described as the single source of truth for all API routes, and `entities/` gets one folder per entity. Both are the kind of convention that is cheaper to inherit than to invent.

The script set is small enough to read in one screen

The generated `package.json` comes with a documented set of scripts, and the list is short enough to be worth reading in full.

- `npm run dev` runs the server in development with live reload and browser refresh. - `npm test` runs the tests with Node's built-in test runner. - `npm test -- tests/users.test.ts` runs a single test file. - `npm run lint` checks the code with ESLint. - `npm run format` formats the code with Prettier. - `npm start` runs the server in production mode, with no build step. - `npm run typecheck` checks for TypeScript errors. - `npm run install:clean` deletes `node_modules` and the lockfile, then reinstalls.

The choice of Node's built-in test runner is consistent with the rest of the design. The philosophy is to use what the runtime already provides, so the project has fewer tools to install, configure and keep current. There is no Jest, no Vitest and no separate test transpiler, and the template uses ESLint and Prettier for the parts the runtime does not cover.

The generator's own `package.json` shows the same habits. Its test script runs the built-in Node test runner over the tests directory, and it has a separate `test:e2e` script that runs `node scripts/e2e.js`, so the generator tests its own output end to end. The published files list is careful too: it excludes `lib/template/node_modules/`, `lib/template/package-lock.json`, `lib/template/dist/`, `lib/template/.vscode/` and `lib/template/tsconfig.tsbuildinfo`, so the npm tarball carries the template source and not the artefacts of a previous install.

The CLI will not overwrite your work unless you say so

The command line interface is small, and one of its options is a safety feature rather than a convenience.

npx express-generator-typescript
# or install globally
npm install -g express-generator-typescript

The options table lists `project name` as the folder to create, defaulting to `express-gen-ts`, `--use-yarn` to install dependencies with Yarn instead of npm, `--force` to write into a folder that isn't empty with files of the same name overwritten, and `-h` and `--help` for usage and `-v` and `--version` for the generator version.

Without `--force`, the generator will not write into a folder that already has files in it, so it cannot overwrite your work by accident. For a generator that writes a whole tree of files, that is the correct default, and it is worth knowing before you try to regenerate into an existing project.

The quick start is the three commands you would expect:

# generate a project (defaults to express-gen-ts)
npx express-generator-typescript my-api

cd my-api

# start developing at http://localhost:3000
npm run dev

The `--use-yarn` flag is worth noting for teams that standardised on Yarn, since the generated lockfile and install step follow your choice rather than forcing npm.

The VS Code settings are opinionated, and deliberately so

The generator goes as far as shipping editor configuration, and the README explains the reasoning in unusual detail.

The generated project uses ESLint for linting and Prettier for formatting, and the settings file turns on format on save with the Prettier extension as the default formatter. It then sets `"eslint.format.enable": false`, with a comment stating that ESLint should be used for linting only and not for formatting, and adds a code action on save that runs the ESLint fixes without formatting.

The reason is a well known conflict. If both ESLint and Prettier are allowed to format the same file, they disagree about rules such as semicolons and line width, and the file changes back and forth depending on which tool ran last. Splitting the responsibilities removes the fight. The settings also disable the automatic JSDoc suggestions, which the comments label as noise reduction, and pin the editor rulers at 80 with a tab size of 2, which lines up with the Prettier defaults the project ships.

For debugging, the README points at a `.vscode/launch.json` in the generated project, so breakpoints work in VS Code for both the app and the tests without extra setup.

This is the part of the template that most directly shapes a new developer's first day, and it is the part you are most likely to want to keep.

MIT licensed, published on npm, and moving without release tags

The package is published on npm as `express-generator-typescript`, and the homepage in the metadata points at the npm package page. The licence field on the repository says MIT, the manifest records the same, and the LICENSE file sits at the repository root. MIT is permissive, so there is no obstacle to using the generator or the template it produces in a commercial project.

The version in the manifest is 3.2.0, and the keywords list gives a fair idea of the positioning: express, express-generator, typescript, api, rest, rest-api, scaffold, scaffolding, cli, generator, nodejs, backend, boilerplate, starter, template, express-ts, express5, server, tooling, eslint. The topic list on the repository adds express5 and vitest, though the generated project uses Node's built-in test runner rather than Vitest, so treat the topics as search metadata rather than a statement about the template.

On maintenance, the repository is not archived and the last push was on 2026-10-11, so the tool is being worked on. But there are no GitHub releases, which means the npm version is your only version marker and there is no changelog to read before upgrading.

The dependency question deserves a final word. The generated project keeps its dependency list lean, and the generator itself ships as a small CLI whose `main` is `lib/express-generator-typescript.js` with `bin/cli.js` as the executable. That is a package you install once, run, and then own the output of.

Editorial conclusion

express-generator-typescript is a good fit for a team that wants an Express 5 API scaffolded in TypeScript today, especially one that prefers running TypeScript directly over maintaining a build pipeline, and the layered layout with a working User CRUD example gives you something real to argue about on day one. It is the wrong choice if you need a view engine, an ORM or a UI layer, because the generator deliberately ships none of those, and it is the wrong choice if you are still on Node 20, since the engines field requires 22.18 or newer in the 22 line, 24, or 26. Before adopting, run npx express-generator-typescript in a scratch folder and read the generated config/ and src/entities/ layout against the structure you already use, and check the npm version you pin, because the repository has no GitHub releases and the last push was on 2026-10-11.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. seanpmaxwell/express-generator-typescript on GitHub