typescript-express-starter: PM2 is included in one section and in progress in another, and 8 of 8 is a matrix of twelve

PM2 is promised as included and then listed as not yet built

The feature summary says the generator produces production ready projects with Docker, PM2 and NGINX configurations included. Two sections later, the development tools table lists four categories as currently available: a linter, a bundler, a testing framework and a container. Underneath it is a second table headed as things to be added later and currently in progress, which contains a process category with pm2, a CI/CD category with GitHub Actions workflows, a git hooks category with husky, and an API documentation category with swagger. So the process manager appears in both tables with opposite statuses, and NGINX appears only in the first list, since neither tools table mentions it at all. NGINX is still in the published keywords, alongside docker, docker-compose, pm2, swagger and husky, which describes the project's ambitions rather than its current output.

A table titled fully tested contains a template marked pending

The template section introduces itself with comprehensive compatibility tested and then shows a table under a heading for production ready and fully tested templates. Three rows appear. The default Express plus TypeScript starter is marked active with a baseline compatibility label. The Drizzle ORM with PostgreSQL template is active with a full compatibility figure. The express-cargo template, described as decorator based request binding and validation, is also active, and its compatibility cell reads pending. A template that is pending compatibility testing is not fully tested, so the heading and the table disagree for one of the three rows. A fourth table for ORM and database integrations is introduced as coming soon, which is consistent with the feature list promising support for a range of object mappers while only a SQL oriented one appears under tested.

Eight combinations claimed against a matrix that lists twelve pairings

The one template that gets a detailed matrix is the Drizzle one, and the numbers do not line up. The section lists three linters: a unified tool that lints and formats together, the traditional ESLint plus Prettier pair, and a Rust based linter described with a timing in milliseconds. It lists two bundlers, one esbuild based with a build time in milliseconds and one Rust based compiler. It lists two test runners. Three times two times two is twelve pairings, and the compatibility cell for that template reads 100 percent with 8 of 8, repeated in a closing line claiming all 8 combinations were tested and verified. So either two of the listed tools are not counted in the matrix or the figure is from an earlier state. The per-tool timings are given to the millisecond with no hardware, no project size and no method, which is worth noting before treating them as guidance.

Published templates deliberately exclude lock files and dotenv files

The manifest's files list is the clearest statement of what a consumer gets, and it is mostly subtractions. The bin, devtools and templates directories are published. Inside templates, everything is excluded: dependency directories, three different build output directories, coverage, logs, turbo directories, macOS metadata files, dotenv files and their local variants, and every lock file pattern, with explicit entries for pnpm and yarn. Excluding dotenv files from the template payload is good hygiene, since a starter should not ship secrets or a local configuration. Excluding lock files has a bigger consequence: a generated project arrives with a dependency manifest but no resolved graph, so the first install picks whatever satisfies the ranges at that moment and two people generating the same template on different days can get different trees.

clean-templates runs the validator, and the project tests itself with Node's runner

The scripts have a few things worth reading twice. The test script runs Node's built in test runner across the files in the test directory, with no framework flag, even though the CLI's headline feature is letting you choose Jest or Vitest for the project it generates. There is a separate template validation script, a compatibility suite run from a module file under a scripts directory, and a preset benchmark script. Then there is the naming: a script called clean-templates does not clean anything, it runs the template validation. The bin directory also carries a project-doctor command and a performance profiler, which suggests the maintainer treats diagnosis of generated projects as a first class task rather than an afterthought. One development script is a one-line node evaluation that imports the presets module and prints its exported keys, which is a quick way to see the presets without starting the CLI.

Two samples in the document stop mid-sentence

The quick start is two commands:

# Install globally
npm install -g typescript-express-starter

# Run the interactive CLI
typescript-express-starter

After them it reproduces the CLI own question frames as a block of box drawing characters. The first two questions are complete: pick a setup mode between a quick start preset and a step by step custom mode, and pick a package manager between npm, pnpm and yarn. The third question, which asks you to choose a template, is cut in the middle of a word: the Drizzle PostgreSQL entry stops after the words describing a modern SQL toolkit with type safety and full devtools and the beginning of a difficulty label. The generated project structure block has the same problem. It lists a source directory with configuration, controllers, data transfer objects, entities, exceptions, interfaces, middlewares, repositories and routes, then ends on a line that has only started drawing the next entry. Both truncations land on the two places a reader most needs the complete list.

The starter's own repository lints with eslint and locks with pnpm

The repository that generates your project is configured one way, and it is worth comparing with the menu it offers. At its root are an ESLint configuration in the older single file style, an ESLint ignore file and a Prettier configuration. The lock file in the tree is the pnpm one. There is also a project level agent instruction file, a GitHub directory, a package ignore file alongside the standard Git ignore, and two READMEs, one English and one Korean, with the English one presented first. So the default this project ships for itself is the traditional linter pair and the pnpm package manager, out of a menu that also offers a unified formatter and linter, a Rust based linter, and npm or yarn. That is not a contradiction, since the CLI is explicitly package manager agnostic, but it is the most reliable signal about what the author actually uses.

Ten templates claimed, three listed, and two years between two of the releases

The introduction promises ten or more templates and ten or more database and ORM combinations, while the template section lists three as active and a fourth table as coming soon. The gap between promise and table is the kind of thing a changelog settles, and the repository does have release tags to consult. Those tags have their own shape: 10.2.1 from October 2023, then nothing for more than two years, then 11.0.1 in January 2026 and 11.1.1 in March 2026. So the project had a long gap followed by two releases close together, and the manifest version matches the newest tag. The last push on the default branch is dated 2026-10-01, three days before this writing, which is a busy branch relative to a twice-yearly release habit.

Editorial conclusion

typescript-express-starter fits a developer who wants a decided opinionated Express skeleton in under a minute and does not mind losing control of the dependency graph. Four things to check before you generate a project with it. The documentation contradicts itself about the process manager, so do not assume a PM2 setup exists in the output. The compatibility numbers are not reproducible from the tables, so verify the combination you want yourself. The published package excludes every lock file, which means the first install in a generated project resolves versions fresh and your build is not reproducible until you commit a lock file of your own. And the starter's own repository uses one of the tools it asks you to choose between, which is a reasonable default and a mild hint about what the maintainer prefers.

Frequently asked questions

Official sources

1. License: MIT
2. ljlm0402/typescript-express-starter on GitHub
3. Project website
4. README
5. Releases