`reactStrictMode: true` is recognized but not enforced (root not wrapped in <StrictMode>)

[hyf0]

Problem

reactStrictMode: true in next.config is recognized but not enforced — the app root is not wrapped in <React.StrictMode>.

npx vinext check even reports it:

~ reactStrictMode — config option recognized but not yet enforced; root is not wrapped in <React.StrictMode>

react.dev sets reactStrictMode: true. Under vinext the dev-time double-invoke / strict checks the project opted into are silently lost (production is unaffected — StrictMode is dev-only).

Workaround used

Wrap pages/_app.tsx's tree in <StrictMode> manually.

Suggested fix

Inject the <React.StrictMode> wrapper when reactStrictMode: true, like Next.js does.

[hyf0]

🔎 Triage — Next.js behavior vs vinext behavior

Method: grounded in the installed Next.js 15.1.12 source (node_modules/next/dist) and the exact vinext 0.1.8 dist (node_modules/vinext/dist) this issue was filed against; each conclusion independently re-checked by an adversarial second pass. vinext targets the Next.js 16 API surface, so a possible version difference was tested explicitly.

Verdict: 🐞 vinext bug (parity gap — fix needed) · should vinext fix: yes · scope: dev-only · confidence: high

Next.js behavior

Next.js wraps the app root in React.StrictMode when reactStrictMode is true. For the Pages Router, doRender's renderReactElement passes children = process.env.__NEXT_STRICT_MODE ? jsx(React.StrictMode, {children: elem}) : elem. That env var is injected at build by define-env-plugin from config.reactStrictMode (null/false => no wrapper, true => wrapper). The App Router does the equivalent via StrictModeIfEnabled = process.env.__NEXT_STRICT_MODE_APP ? React.StrictMode : React.Fragment. Default config value is null (off); react.dev explicitly opts in with reactStrictMode: true, so Next does wrap the tree. StrictMode is a no-op in production builds, so the visible effect (dev double-invoke, deprecation/legacy warnings) is dev-only.

_{Evidence: node_modules/next/dist/client/index.js:582 · node_modules/next/dist/build/webpack/plugins/define-env-plugin.js:153 · node_modules/next/dist/client/app-index.js:161 · node_modules/next/dist/client/app-index.js:179 · node_modules/next/dist/server/config-shared.js:81 · node_modules/react.dev/next.config.js:22}

vinext behavior

vinext recognizes the reactStrictMode config option but never wraps the React tree in React.StrictMode. A grep of the entire dist shows StrictMode appears ONLY in check.js, where it is reported as status "partial" with detail "config option recognized but not yet enforced; root is not wrapped in <React.StrictMode>". The actual render paths never reference StrictMode: the Pages client hydration entry builds the root element via React.createElement(AppComponent/PageComponent, ...), wraps it only with wrapWithRouterContext, and calls hydrateRoot(container, element) directly; the Pages server entry's createPageElement/enhancePageElement likewise build the element from App/Page components with no StrictMode wrapper before renderToReadableStream. So the user-opted-in dev strict checks are silently dropped (production is unaffected since StrictMode is a prod no-op anyway).

_{Evidence: node_modules/vinext/dist/check.js:265 · node_modules/vinext/dist/check.js:267 · node_modules/vinext/dist/entries/pages-client-entry.js:156 · node_modules/vinext/dist/entries/pages-client-entry.js:183 · node_modules/vinext/dist/entries/pages-server-entry.js:331 · node_modules/vinext/dist/entries/pages-server-entry.js:345}

Is it a version difference (vinext → Next 16 vs react.dev → Next 15)?

No. Wrapping the root in React.StrictMode based on the reactStrictMode config is stable, long-standing Next.js behavior (present since the option was introduced, well before v13, and unchanged through v15/v16). The Next 15 source confirms the wrapper (client/index.js:582 + define-env-plugin.js:153), and the App Router equivalent (app-index.js StrictModeIfEnabled) is the same mechanism Next has used for years. The only version nuance is the default: Next 13.5+ documents reactStrictMode defaulting to true for new apps, but here react.dev sets it explicitly to true, so the default is irrelevant. There is no Next 15->16 behavioral change driving this diff.

Fix

Inject React.StrictMode in the render-tree construction when config.reactStrictMode === true: pages-client-entry.js (around the element build at lines 156-183, before hydrateRoot) and pages-server-entry.js createPageElement/enhancePageElement (lines 331-361), plus the App Router entries (app-browser-entry/app-ssr-entry/app-rsc-entry). check.js can then upgrade reactStrictMode from "partial" to "supported".

---

_{🤖 Triaged with Claude Code (Opus 4.8) — read-only analysis against installed Next 15.1.12 + vinext 0.1.8 sources, adversarially verified.}

[hyf0]

Fixed upstream: cloudflare/vinext#2433 (feat(pages): enforce reactStrictMode by wrapping client root in <StrictMode>), merged. Lands in the next vinext release (after 0.2.0), so this port keeps the explicit <StrictMode> wrap in _app.tsx until it upgrades. Closing as fixed upstream.