react-exp-workspace - an Nx monorepo with React and Express

One command, three positional names:

• →npx create-nx-react-express-workspace <workspace-name> <client-name> <server-name>
• →Bootstraps an empty Nx workspace via create-nx-workspace.
• →Generates a React app with the Nx React generator - Vite bundler, styled-components, routing, and Cypress e2e.
• →Generates an Express API with the Nx Express generator.
• →Scaffolds the client source layout (apis, components, constants, helpers, hocs, hooks, pages, redux, routes, types) and the server layout (constants, controllers, helpers, middleware, routes, types), with an index.ts barrel in every folder.

Node CLI

A single entry point that composes official Nx generators and writes the skeleton.

Nx workspace

Generated with the empty preset, then extended with two app generators.

@nx/react

Client app generated with Vite, styled-components, routing, and Cypress.

@nx/express

Server app generated into apps/, ready for middleware, routes, and controllers.

TypeScript

Every scaffolded folder opens with an index.ts barrel so imports resolve immediately.

• →create-nx-workspace builds the empty workspace in the current directory.
• →The React app is generated first, with the generators taking flags instead of prompting, so the whole run is unattended.
• →The Express app is generated second, targeting the same apps/ directory the client already occupies.
• →Both src trees are scaffolded with index.ts barrels, then the CLI reports the exact layout you can start coding in.

• →Generator composition is order-sensitive. The empty workspace, the React app, and the Express app have to be created in sequence against the right cwd - a mistake in the working directory breaks the whole project graph.
• →Generator flags drift between Nx majors. --bundler, --style, --e2eTestRunner come from generator schemas that change; pinning the expectations is part of keeping the scaffold reproducible.
• →Strict CLI contract. All three positional names are required and anything less exits with usage - the npm command fails loudly instead of half-finishing a workspace.
• →Deterministic skeleton on both sides of the stack. Client and server get different folder shapes, and both are pre-created with index.ts barrels so the project compiles the moment the command finishes.
• →Quiet failures. The whole run is wrapped so a single failed generator writes a clear message and exits non-zero instead of leaving the user inside a half-built workspace.