// the take
The official scaffold `nest new` generates: one module, one controller, one service, wired up with Nest's DI container and a hello-world endpoint. It's for someone starting a brand new NestJS project who wants the baseline file layout and config instead of assembling tsconfig/build/test wiring by hand.
Test setup is already correct out of the box — vitest configs for both unit and e2e, with a working e2e spec hitting the actual HTTP layer rather than just a unit stub. It's using oxlint instead of eslint, which is a meaningfully faster lint pass for a starter that's going to get copied into thousands of repos. Being the actual template behind `nest new` means it tracks the framework's current conventions rather than going stale the way third-party boilerplates do.
There's nothing here beyond the DI skeleton — no example of config/env handling, validation pipes, guards, or a module boundary beyond the single trivial one, so it doesn't actually show you how a real Nest app is structured once it has more than one feature. The README is almost entirely sponsor badges, Mau/Observe/Devtools cross-promotion, and links to paid NestJS products rather than guidance on what to do with the starter once you have it. No CI config ships in the repo itself (the badge points at nestjs/nest's CircleCI, not this repo), so you inherit zero testing/build automation and have to write it yourself.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →