NX CLI for monorepo projects

Nx was one of the first monorepo tools I tried seriously for React and Next.js work. My experience was mixed in a predictable way: the generator story was useful, but the deployment edges mattered more than the demo screen.

Nx started in the Angular world and later expanded hard into React and Next.js. The pitch was attractive: applications and libraries in one workspace, shared tooling, generated Jest/Cypress/Storybook config, and a project graph that makes larger repos easier to reason about.

That part mostly worked. The project graph was useful, and the generated shape made the repo feel organized quickly.

The rough part was deploying a Next.js app to Vercel from the generated workspace shape.

Vercel project root

Vercel did not treat the root of the Nx workspace as a normal Next.js app, because the actual app lived under apps/your_app. The fix was to set the project root in Vercel:

After that, Vercel could build the app from the right directory.

Config files still matter

Changing the root directory solved one problem and created another: runtime files that lived at the monorepo root were no longer automatically in the build context. I had to copy or duplicate the files the app needed at runtime.

I also had to make sure the app-level package.json used normal Next scripts:

{
  "scripts": {
    "start": "next start",
    "build": "next build"
  }
}

None of this is hard once you know it. It is just the kind of detail that does not show up in a happy-path generator demo. Local success and production success were different problems.

Storybook rough edges

Storybook integration was another reminder that generated config is only as good as the version you are on. At the time, Nx failed to generate Storybook for the Next.js app because a required config file was missing. The issue was later patched, but it was not obvious how users on older versions should repair their workspace.

Heavy generators save time while you stay on the supported path. When you fall off it, the generated files stop feeling like a gift and start feeling like code you still own.

My take

For a small app, I would not reach for Nx first. A plain Next.js repo is easier to deploy, easier to debug, and easier for a new teammate to understand.

For a larger workspace with multiple apps, shared libraries, tests, Storybook, and affected builds, Nx can still be worth it. I would just test deployment on day one. If the generated shape needs Vercel exceptions, find that out before the repo has ten packages depending on it.