next.js

In dev mode, Next.js Fast Refresh re-evaluates modules on every save, so a top-level new DatabaseConnection(...) (or postgres(), PrismaClient, etc.) creates a new connection each time until PostgreSQL fails with remaining connection slots are reserved for non-replication superuser connections. Fix it by caching the client on globalThis so the connection survives reloads:

import postgres from 'postgres';

declare module globalThis {
  let postgresSqlClient: ReturnType<typeof postgres> | undefined;
}

function connectOnceToDatabase() {
  if (!globalThis.postgresSqlClient) globalThis.postgresSqlClient = postgres();
  return globalThis.postgresSqlClient;
}

export const sql = connectOnceToDatabase();

The same singleton pattern works for Prisma (globalThis.prisma ??= new PrismaClient()) and other drivers. This only affects development; production builds don't re-evaluate modules per request.

This is a known Turbopack dev regression introduced by #97664 in Next.js 16.4.0. Page modules can be omitted from client chunks when the page chunk group reuses _app availability data, causing SSR to succeed but hydration to fail with module factory is not available.

Permanent fix: upgrade to a Next.js canary/preview release containing PR #98823, which chains the Pages Router development client module graph. The fix was verified with next@16.5.0-preview-358550b2-20261009.

npm install next@canary
rm -rf .next
npm run dev

If you cannot upgrade, use one of these workarounds:

# Downgrade to the last unaffected release
npm install next@16.3.8
rm -rf .next
npm run dev

Or run development with webpack instead of Turbopack:

npx next dev --webpack -p 3456

Production builds are not affected, so next build && next start also works on 16.4.0.

Next.js 16.4 enables experimental.turbopackSharedRuntime by default. With cacheComponents: true, Turbopack inlines its chunk-group bootstrap into the prerendered shell without adding the request nonce. A strict CSP such as script-src 'self' 'nonce-<random>' blocks that inline <script id="_R_">, so the client runtime never starts and hydration fails.

Workaround: disable the shared runtime in next.config.js:

module.exports = {
  experimental: {
    turbopackSharedRuntime: false,
  },
};

Then rebuild and restart:

next build && next start

This restores the previous behavior where the bootstrap is loaded as an external script allowed by 'self'. The issue affects Next.js 16.4.0 with Turbopack, React 19.2, and cacheComponents: true; using a script hash is impractical because the bootstrap changes per route and build.

Upgrade Next.js to **16.4.0 or later**, where this Windows symlink issue was fixed:

pnpm add next@^16.4.0
# or
yarn add next@^16.4.0

Then remove the old build output and rebuild:

rm -r .next
pnpm build

The generated symlinks under .next/standalone/node_modules should now resolve within .next/standalone/node_modules/.pnpm instead of the build machine’s root node_modules or absolute Windows paths. The bug was reproduced with Next.js 16.2.10 and 16.3.0 on Windows with pnpm, and similar absolute-symlink behavior was reported with yarn. If upgrading is not immediately possible, a reported workaround is to build the standalone output on Linux or use webpack for local Windows container builds.

Next.js clears distDir before building. With distDir: "../../" in apps/web, the resolved path is the monorepo root, so Next.js recursively deletes that directory. Keep distDir inside the Next.js project root:

1. Edit apps/web/next.config.ts and remove the unsafe setting or use a local directory:

const nextConfig = {
  distDir: '.next',
}

2. Do not point distDir at the repository root, home directory, /, or another project.
3. For Vercel monorepo deployments, go to **Project Settings → General → Root Directory** and set it to apps/web instead of moving .next to the repository root. Vercel will then detect the build output automatically.
4. Verify the resolved path before building from apps/web:

node -e "console.log(require('path').resolve('../../'))"

If it prints the monorepo root or another directory containing unrelated files, the configuration is unsafe.
5. Upgrade from Next.js 16.3.5 to a newer release containing the custom distDir safety validation.

The deletion is permanent and does not use the system trash; restore affected files from Git or another backup.