A Consistent Starting Point for Full-Stack Products
Starting a full-stack application often means repeating the same setup work before product development can begin. The frontend and API need separate scaffolds, common dependencies, predictable ports, environment examples, shared root scripts, and enough operational metadata for deployment tooling to understand the result.
NexstJS packages that setup into one Node.js CLI. It creates a Next.js frontend and a NestJS backend under one project root, initializes an opinionated application toolkit, and emits consistent scripts and environment contracts without introducing a workspace framework.
npx nexstjs my-app
cd my-app
pnpm dev
The generated project remains two ordinary applications that can be inspected and changed independently.
What the CLI Generates
NexstJS creates a deliberately simple structure:
my-app/
├── frontend/ Next.js App Router application
├── backend/ NestJS application and Prisma setup
├── nexst.json Deployment-readable application contract
└── package.json Combined development and production scripts
The root package uses concurrently to provide combined and per-service commands for development, builds, and production startup. The frontend defaults to port 3000, while the backend reads PORT with a fallback of 4000.
The normal mode lets the current create-next-app and shadcn/ui prompts remain visible. For CI or scripted project creation, --no-ux selects a deterministic preset and skips interactive setup choices.
npx nexstjs my-app --no-ux
npx nexstjs my-app --pm npm
npx nexstjs my-app --pm npm --no-alias
Frontend Foundation
The frontend begins with create-next-app@latest, uses the App Router and TypeScript, and initializes shadcn/ui. NexstJS then installs a broad toolkit covering:
- Lucide icons and shadcn/ui components.
- GSAP, Framer Motion, Lenis, Lottie, Three.js, and React Three Drei.
- Axios and TanStack Query.
- React Hook Form and Zod.
- Date utilities, toast notifications, environment validation, and class-name composition.
This gives a new product access to common interface and data primitives immediately. It does not prescribe the final application architecture or force every installed library into the shipped bundle.
Backend Foundation
The backend begins with @nestjs/cli@latest, initializes Prisma, and installs libraries commonly used for headers, cookies, validation, configuration, file uploads, Supabase, Passport, JWT, throttling, Argon2, and Swagger.
These packages are a prepared foundation, not a finished security system. NexstJS does not currently wire complete authentication modules, call Helmet, configure CORS, register throttling, or generate a Swagger setup on the developer's behalf. Product-specific policies and middleware remain explicit implementation work after scaffolding.
That distinction is intentional for the detail page: NexstJS standardizes the starting environment without pretending that installing a dependency is equivalent to configuring it correctly.
Environment and Deployment Contracts
Generated frontend and backend environment examples document the expected API URL, application identity, server port, JWT values, Supabase credentials, database connection, CORS origin, and throttle values. Developers copy those templates and replace placeholders with real environment-specific secrets and endpoints.
The nexst.json file provides a machine-readable summary of the generated services:
{
"name": "my-app",
"apps": {
"web": { "path": "frontend", "port": 3000, "health": "/" },
"api": { "path": "backend", "port": 4000, "health": "/health" }
},
"packageManager": "pnpm",
"node": "20"
}
The contract is designed for deployment automation to discover paths, ports, health targets, package-manager preference, and the Node.js expectation without guessing the project layout. The API /health endpoint itself is not generated yet and remains listed on the roadmap, so downstream deployment tooling must not assume it already exists.
Latest-First by Design
NexstJS requests current upstream CLIs and packages instead of maintaining a frozen template. This keeps newly generated projects close to the contemporary Next.js, NestJS, and shadcn/ui ecosystem, but it also means output can change when those upstream tools release new defaults.
That tradeoff makes NexstJS appropriate for developers who want a current, opinionated foundation and consistent operational contracts. It is less appropriate when a team needs byte-for-byte reproducibility, fixed dependency versions, a highly customized build system, or migration support for an existing codebase.
CLI Stack
The published CLI is an ECMAScript module requiring Node.js 20.12 or newer. Commander parses commands, Inquirer handles confirmation, Execa runs the upstream tooling, and fs-extra writes generated files. Chalk, Ora, Boxen, and Figlet provide the terminal presentation.
Version 1.0.9 supports pnpm and npm, with pnpm as the recommended default. It is distributed under the MIT License.
What NexstJS Is and Is Not
NexstJS is a scaffolding CLI. It is not a framework, a monorepo platform, a complete authentication implementation, or a promise that every generated dependency is already configured for production.
Its value is narrower and more practical: remove repetitive setup, give the frontend and backend a shared operational contract, and leave the generated source understandable enough for the developer to own after the command finishes.