next/constants shim throws ReferenceError: process is not defined in client bundles

[jlucaso1]

Summary

Importing anything from next/constants in client code crashes production browser bundles with ReferenceError: process is not defined.

The shim (packages/vinext/src/shims/constants.ts) has a top level bare reference to process:

export const CONFIG_FILES = [
  "next.config.js",
  "next.config.mjs",
  "next.config.ts",
  // process.features can be undefined on Edge runtime
  ...(process?.features?.typescript ? ["next.config.mts"] : []),
];

Optional chaining does not guard an undeclared identifier, so evaluating the module in a browser throws. Real Next.js has the same expression in its constants module but survives because webpack injects a process polyfill into client bundles. Vite does not polyfill process.

Since next/constants is aliased for every environment (public-shim-map applies to the shared resolve.alias), the shim is a legitimate client import. @sentry/nextjs for example imports PHASE_PRODUCTION_BUILD in code that ends up in the client graph. And because the shim lands in the shared vinext-* client manual chunk, the failed evaluation takes down that whole runtime chunk, not just the importer. In our case the visible symptom was Sentry's client SDK never initializing in production.

Reproduction

Add a "use client" page that imports PHASE_PRODUCTION_BUILD from next/constants to the app-basic fixture, build for production, open in a real browser: the page logs ReferenceError: process is not defined (we saw 3 page errors from the shared chunk).

Suggested fix

...(typeof process !== "undefined" && process.features?.typescript ? ["next.config.mts"] : []),

Behavior is unchanged in any runtime that has process, and the module becomes safe to evaluate in the browser. Verified locally: 0 page errors after the change, same rendered output.

Happy to send a PR. Thanks for vinext, it has been great to run Next apps on Vite!