* fix(cli): allow esbuild builds in Vite templates
* fix(cli): extend pnpm 11 build-script allowlists across app templates
- Add packages: [] to single-app pnpm-workspace.yaml so pnpm 9 does
not reject the file with "packages field missing or empty".
- Add astro-app, react-router-app, start-app, next-app workspace
yamls with the build-script allowlist each template needs
(esbuild, sharp, unrs-resolver as applicable).
- Set msw: false across all app allowlists so the registry component
install runs cleanly under pnpm 11 without executing msw's
service-worker postinstall.
- Add a scaffold test pinning the packages:[] + allowBuilds shape
so the parser keeps treating it as single-app.
* chore: changeset
* fix(templates): allow monorepo pnpm builds
* ci(templates): validate app workspace conversion
---------
Co-authored-by: shadcn <m@shadcn.com>
All monorepo templates hardcoded `packageManager: "pnpm"` which
meant running `bunx --bun shadcn@latest init --monorepo` would
still shell out to `pnpm install`, triggering Corepack and crashing
under Bun because `process.mainModule` is readonly there.
This removes the hardcoded pnpm override from every monorepo template
config so `getPackageManager()` can actually detect what the user is
running. The scaffold step now adapts the cloned template on the fly:
- strips the `packageManager` field from package.json (avoids Corepack)
- converts pnpm-workspace.yaml to a `"workspaces"` array in package.json
- removes pnpm-lock.yaml
- rewrites `workspace:*` refs to `"*"` when the detected PM is npm
(npm doesn't support the workspace: protocol)
- picks the right install flags per PM (`--no-frozen-lockfile` for pnpm,
nothing extra for bun/npm/yarn)
pnpm behavior is completely unchanged — `adaptWorkspaceConfig` early-
returns when the detected PM is pnpm.
