Review: fix(build): apply default server externals

I verified this against the authoritative Next.js source and the package list matches exactly. Solid PR. A few notes below — none are blocking, one is worth a second look.

Verified correct against Next.js

• Package list parity. The 79-entry DEFAULT_SERVER_EXTERNAL_PACKAGES in server-external-packages.ts is byte-for-byte identical to next/dist/lib/server-external-packages.jsonc in the installed Next.js (16.2.7). I diffed both sets programmatically — zero entries differ. (Minor: the header comment says "Next.js 16.2.6" while the repo ships 16.2.7; the lists are identical, but you may want to bump the comment to avoid confusion.)

• Conflict semantics match Next.js. next/dist/build/webpack-config.js:667-678 throws The packages specified in the 'transpilePackages' conflict with the 'serverExternalPackages': ... only for the intersection of user-explicit serverExternalPackages and transpilePackages. mergeServerExternalPackages reproduces this exactly (userPackages.filter(name => transpiled.has(name))), including the error message string.

• Merge/override semantics match Next.js. webpack-config.js:681 computes EXTERNAL_PACKAGES.concat(serverExternalPackages).filter(pkg => !transpilePackages.includes(pkg)). The PR filters transpiled only out of the defaults, relying on the conflict check to guarantee no user package overlaps transpiled — functionally equivalent, and typescript staying external is the intended fix for the twoslash 500s.

Worth a second look

• Client dep-optimizer exclude now spans all 79 packages (index.ts:2434-2438). Previously this optimizeDeps.exclude only received the (usually empty) user serverExternalPackages; it now receives the full default set. The comment there only motivates server-only conditional-export packages (file-type-style). The default list includes packages that can legitimately be imported from client components in some apps (e.g. shiki, autoprefixer, postcss). Excluding them from the client optimizer means they get resolved lazily rather than prebundled, which at worst causes a late re-optimization + full reload on first client use rather than a hard failure. This matches Next.js's optOutBundlingPackages treatment, so it's defensible — but it's a wider behavioral change than the PR description implies, and the inline comment no longer fully explains why the entire default set is excluded. Consider a one-line comment update noting these are the Next.js default server externals.

Minor / non-blocking

• index.ts:2043 now merges config.ssr.external into the top-level viteConfig.ssr.external array alongside nextServerExternal. This is a genuine improvement (user ssr.external was previously dropped on the Pages-Router/single-build path), and duplicates with the default list are harmless since Vite dedupes external matching. Just calling it out as an in-scope behavioral change not mentioned in the summary.

Testing

• Ran tests/server-external-packages.test.ts + tests/next-config.test.ts (205 passed) and a scoped tsc --noEmit on the package (clean).
• The new app-router-production-build.test.ts case is a strong end-to-end check — it builds, asserts typescript is in vinext-externals.json, and exercises the TS language service through a real production route handler for both default and ESNext lib configs. Good port of Next.js's test/e2e/twoslash.

Overall: behavior matches Next.js, tests are well-targeted, and the fix is sound. The only thing I'd action is tightening the comments around the widened client-optimizer exclusion and the 16.2.6/16.2.7 version note.