Skip to content

[DO NOT MERGE] Enable server HMR by default for testing#90389

Draft
wbinnssmith wants to merge 2 commits intoserver-hmr-sourcemapsfrom
server-hmr-default
Draft

[DO NOT MERGE] Enable server HMR by default for testing#90389
wbinnssmith wants to merge 2 commits intoserver-hmr-sourcemapsfrom
server-hmr-default

Conversation

@wbinnssmith
Copy link
Member

Do not merge this. This PR currently exists only so that we can run the e2e test suite with server hmr applied.

Copy link
Contributor

@vercel vercel bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additional Suggestion:

Test file uses removed --experimental-server-fast-refresh CLI flag and asserts on removed feature.experimentalServerFastRefresh trace tag, causing test failure.

Fix on Vercel

@nextjs-bot
Copy link
Collaborator

nextjs-bot commented Feb 23, 2026

Failing test suites

Commit: de01a81 | About building and testing Next.js

pnpm test-start test/e2e/app-dir/navigation/navigation.test.ts (job)

  • app dir - navigation > hash > should scroll to the specified hash (DD)
Expand output

● app dir - navigation › hash › should scroll to the specified hash

expect(received).toBe(expected) // Object.is equality

Expected: false
Received: true

  199 |           url.includes('with-query-param')
  200 |         )
> 201 |         expect(hasQueryParamRscRequest).toBe(false)
      |                                         ^
  202 |       }
  203 |
  204 |       await checkLink('query-param', 2284)

  at Object.toBe (e2e/app-dir/navigation/navigation.test.ts:201:41)

pnpm test-start-turbo test/production/deterministic-build/deployment-id.test.ts (turbopack) (job)

  • deterministic build - changing deployment id > build output API - builder > should produce identical build outputs even when changing deployment id (DD)
Expand output

● deterministic build - changing deployment id › build output API - builder › should produce identical build outputs even when changing deployment id

thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."

  50 |       }
  51 |
> 52 |       const result = Reflect.apply(target, thisArg, args)
     |                              ^
  53 |       return typeof result === 'function' ? wrapJestTestFn(result) : result
  54 |     },
  55 |     get(target, prop, receiver) {

  at Object.apply (lib/e2e-utils/index.ts:52:30)
  at it (production/deterministic-build/deployment-id.test.ts:245:7)
      at Array.forEach (<anonymous>)
  at production/deterministic-build/deployment-id.test.ts:217:41
  at Object.<anonymous> (production/deterministic-build/deployment-id.test.ts:197:58)

@nextjs-bot
Copy link
Collaborator

nextjs-bot commented Feb 23, 2026

Stats from current PR

✅ No significant changes detected

📊 All Metrics
📖 Metrics Glossary

Dev Server Metrics:

  • Listen = TCP port starts accepting connections
  • First Request = HTTP server returns successful response
  • Cold = Fresh build (no cache)
  • Warm = With cached build artifacts

Build Metrics:

  • Fresh = Clean build (no .next directory)
  • Cached = With existing .next directory

Change Thresholds:

  • Time: Changes < 50ms AND < 10%, OR < 2% are insignificant
  • Size: Changes < 1KB AND < 1% are insignificant
  • All other changes are flagged to catch regressions

⚡ Dev Server

Metric Canary PR Change Trend
Cold (Listen) 457ms 507ms ▁▁█▁▁
Cold (Ready in log) 459ms 461ms ▁▁█▂▂
Cold (First Request) 942ms 909ms ▁▁█▄▄
Warm (Listen) 457ms 457ms ▁▁█▁▁
Warm (Ready in log) 454ms 458ms ▁▁█▁▁
Warm (First Request) 370ms 373ms ▁▁█▂▁

⚡ Production Builds

Metric Canary PR Change Trend
Fresh Build 4.296s 4.343s ▁▁█▁▁
Cached Build 4.359s 4.305s ▁▁█▁▁
📦 Production Builds (Webpack) (Legacy)

📦 Production Builds (Webpack)

Metric Canary PR Change Trend
node_modules Size 475 MB 475 MB ▁▁▁▁▁
📦 Bundle Sizes

Bundle Sizes

⚡ Turbopack

Client

Main Bundles: **400 kB** → **400 kB** ✅ -13 B

80 files with content-based hashes (individual files not comparable between builds)

Server

Middleware
Canary PR Change
middleware-b..fest.js gzip 764 B 764 B
Total 764 B 764 B
Build Details
Build Manifests
Canary PR Change
_buildManifest.js gzip 451 B 452 B
Total 451 B 452 B ⚠️ +1 B

🔄 Shared (bundler-independent)

Runtimes
Canary PR Change
app-page-exp...dev.js gzip 320 kB 320 kB
app-page-exp..prod.js gzip 170 kB 170 kB
app-page-tur...dev.js gzip 319 kB 319 kB
app-page-tur..prod.js gzip 169 kB 169 kB
app-page-tur...dev.js gzip 316 kB 316 kB
app-page-tur..prod.js gzip 168 kB 168 kB
app-page.run...dev.js gzip 316 kB 316 kB
app-page.run..prod.js gzip 168 kB 168 kB
app-route-ex...dev.js gzip 70.8 kB 70.8 kB
app-route-ex..prod.js gzip 49.2 kB 49.2 kB
app-route-tu...dev.js gzip 70.8 kB 70.8 kB
app-route-tu..prod.js gzip 49.2 kB 49.2 kB
app-route-tu...dev.js gzip 70.4 kB 70.4 kB
app-route-tu..prod.js gzip 49 kB 49 kB
app-route.ru...dev.js gzip 70.4 kB 70.4 kB
app-route.ru..prod.js gzip 49 kB 49 kB
dist_client_...dev.js gzip 324 B 324 B
dist_client_...dev.js gzip 326 B 326 B
dist_client_...dev.js gzip 318 B 318 B
dist_client_...dev.js gzip 317 B 317 B
pages-api-tu...dev.js gzip 43.2 kB 43.2 kB
pages-api-tu..prod.js gzip 32.9 kB 32.9 kB
pages-api.ru...dev.js gzip 43.2 kB 43.2 kB
pages-api.ru..prod.js gzip 32.8 kB 32.8 kB
pages-turbo....dev.js gzip 52.5 kB 52.5 kB
pages-turbo...prod.js gzip 38.5 kB 38.5 kB
pages.runtim...dev.js gzip 52.5 kB 52.5 kB
pages.runtim..prod.js gzip 38.4 kB 38.4 kB
server.runti..prod.js gzip 62 kB 62 kB
Total 2.82 MB 2.82 MB ⚠️ +1 B
📎 Tarball URL
next@https://vercel-packages.vercel.app/next/prs/90389/next

@wbinnssmith wbinnssmith force-pushed the server-hmr-default branch 2 times, most recently from ff2f17a to 4c3a0f3 Compare February 23, 2026 23:56
wbinnssmith added a commit that referenced this pull request Feb 24, 2026
This is cherry-picked from #90389, which also serves as a test case for server hmr being enabled by default.

This fixes a number of issues with server hmr, most notably that pages router updates weren’t reflected:

1. **Pages Router pages weren't clearing the chunk cache** — the old condition (which just checked the cli flag) meant the chunk cache was only cleared when server HMR was entirely absent. Once server HMR was enabled, Pages Router pages (which don't use the Turbopack module registry) got stale.

2. **`deleteCache` was skipped for files with server HMR subscriptions** — this left stale entries in `evalManifest`'s `sharedCache`, causing "Could not find module in React Client Manifest" errors when new `'use client'` components were added.

3. **`clearModuleContext` was skipped for middleware and edge routes** — server HMR subscriptions include edge runtime chunks, but `__turbopack_server_hmr_apply__` can't reach those sandboxes. They need `clearModuleContext` called explicitly.

4. **Chunk cache wasn't cleared for `.env`/config changes** — when `force: true` (no code change), module-level env captures stayed stale. Now `__next__clear_chunk_cache__()` is called unconditionally when `force` is set.
wbinnssmith added a commit that referenced this pull request Feb 24, 2026
This is cherry-picked from #90389, which also serves as a test case for server hmr being enabled by default.

This fixes a number of issues with server hmr, most notably that pages router updates weren’t reflected:

1. **Pages Router pages weren't clearing the chunk cache** — the old condition (which just checked the cli flag) meant the chunk cache was only cleared when server HMR was entirely absent. Once server HMR was enabled, Pages Router pages (which don't use the Turbopack module registry) got stale.

2. **`deleteCache` was skipped for files with server HMR subscriptions** — this left stale entries in `evalManifest`'s `sharedCache`, causing "Could not find module in React Client Manifest" errors when new `'use client'` components were added.

3. **`clearModuleContext` was skipped for middleware and edge routes** — server HMR subscriptions include edge runtime chunks, but `__turbopack_server_hmr_apply__` can't reach those sandboxes. They need `clearModuleContext` called explicitly.

4. **Chunk cache wasn't cleared for `.env`/config changes** — when `force: true` (no code change), module-level env captures stayed stale. Now `__next__clear_chunk_cache__()` is called unconditionally when `force` is set.
wbinnssmith added a commit that referenced this pull request Feb 24, 2026
This is cherry-picked from #90389, which also serves as a test case for server hmr being enabled by default.

This fixes a number of issues with server hmr, most notably that pages router updates weren’t reflected:

1. **Pages Router pages weren't clearing the chunk cache** — the old condition (which just checked the cli flag) meant the chunk cache was only cleared when server HMR was entirely absent. Once server HMR was enabled, Pages Router pages (which don't use the Turbopack module registry) got stale.

2. **`deleteCache` was skipped for files with server HMR subscriptions** — this left stale entries in `evalManifest`'s `sharedCache`, causing "Could not find module in React Client Manifest" errors when new `'use client'` components were added.

3. **`clearModuleContext` was skipped for middleware and edge routes** — server HMR subscriptions include edge runtime chunks, but `__turbopack_server_hmr_apply__` can't reach those sandboxes. They need `clearModuleContext` called explicitly.

4. **Chunk cache wasn't cleared for `.env`/config changes** — when `force: true` (no code change), module-level env captures stayed stale. Now `__next__clear_chunk_cache__()` is called unconditionally when `force` is set.
wbinnssmith added a commit that referenced this pull request Feb 24, 2026
This is cherry-picked from #90389, which also serves as a test case for server hmr being enabled by default.

This fixes a number of issues with server hmr, most notably that pages router updates weren’t reflected:

1. **Pages Router pages weren't clearing the chunk cache** — the old condition (which just checked the cli flag) meant the chunk cache was only cleared when server HMR was entirely absent. Once server HMR was enabled, Pages Router pages (which don't use the Turbopack module registry) got stale.

2. **`deleteCache` was skipped for files with server HMR subscriptions** — this left stale entries in `evalManifest`'s `sharedCache`, causing "Could not find module in React Client Manifest" errors when new `'use client'` components were added.

3. **`clearModuleContext` was skipped for middleware and edge routes** — server HMR subscriptions include edge runtime chunks, but `__turbopack_server_hmr_apply__` can't reach those sandboxes. They need `clearModuleContext` called explicitly.

4. **Chunk cache wasn't cleared for `.env`/config changes** — when `force: true` (no code change), module-level env captures stayed stale. Now `__next__clear_chunk_cache__()` is called unconditionally when `force` is set.
wbinnssmith added a commit that referenced this pull request Feb 24, 2026
This is cherry-picked from #90389, which also serves as a test case for server hmr being enabled by default.

This fixes a number of issues with server hmr, most notably that pages router updates weren’t reflected:

1. **Pages Router pages weren't clearing the chunk cache** — the old condition (which just checked the cli flag) meant the chunk cache was only cleared when server HMR was entirely absent. Once server HMR was enabled, Pages Router pages (which don't use the Turbopack module registry) got stale.

2. **`deleteCache` was skipped for files with server HMR subscriptions** — this left stale entries in `evalManifest`'s `sharedCache`, causing "Could not find module in React Client Manifest" errors when new `'use client'` components were added.

3. **`clearModuleContext` was skipped for middleware and edge routes** — server HMR subscriptions include edge runtime chunks, but `__turbopack_server_hmr_apply__` can't reach those sandboxes. They need `clearModuleContext` called explicitly.

4. **Chunk cache wasn't cleared for `.env`/config changes** — when `force: true` (no code change), module-level env captures stayed stale. Now `__next__clear_chunk_cache__()` is called unconditionally when `force` is set.
wbinnssmith added a commit that referenced this pull request Feb 24, 2026
This is cherry-picked from #90389, which also serves as a test case for
server hmr being enabled by default.

This fixes a number of issues with server hmr, most notably that pages
router updates weren’t reflected:

1. **Pages Router pages weren't clearing the chunk cache** — the old
condition (which just checked the cli flag) meant the chunk cache was
only cleared when server HMR was entirely absent. Once server HMR was
enabled, Pages Router pages (which don't use the Turbopack module
registry) got stale.

2. **`deleteCache` was skipped for files with server HMR subscriptions**
— this left stale entries in `evalManifest`'s `sharedCache`, causing
"Could not find module in React Client Manifest" errors when new `'use
client'` components were added.

3. **`clearModuleContext` was skipped for middleware and edge routes** —
server HMR subscriptions include edge runtime chunks, but
`__turbopack_server_hmr_apply__` can't reach those sandboxes. They need
`clearModuleContext` called explicitly.

4. **Chunk cache wasn't cleared for `.env`/config changes** — when
`force: true` (no code change), module-level env captures stayed stale.
Now `__next__clear_chunk_cache__()` is called unconditionally when
`force` is set.
@wbinnssmith wbinnssmith force-pushed the server-hmr-default branch 3 times, most recently from 7b9b517 to 57713d3 Compare February 24, 2026 23:07
@nextjs-bot nextjs-bot added the Turbopack Related to Turbopack with Next.js. label Feb 25, 2026
@codspeed-hq
Copy link

codspeed-hq bot commented Feb 25, 2026

Merging this PR will not alter performance

✅ 17 untouched benchmarks
⏩ 3 skipped benchmarks1


Comparing server-hmr-default (5e1b2ff) with canary (34647db)

Open in CodSpeed

Footnotes

  1. 3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports.

@vercel
Copy link
Contributor

vercel bot commented Feb 25, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
next-js Error Error Feb 25, 2026 4:47pm

wbinnssmith added a commit that referenced this pull request Feb 26, 2026
This adds and calls \`maybeInlineSourcemap()\` to the Turbopack Node.js HMR runtime that appends \`//# sourceURL\` and \`//# sourceMappingURL\` (base64-encoded) to each `eval`ed module entry

Test Plan: CI for #90389
@wbinnssmith wbinnssmith changed the base branch from canary to graphite-base/90389 February 26, 2026 06:19
@wbinnssmith wbinnssmith changed the base branch from graphite-base/90389 to server-hmr-sourcemaps February 26, 2026 06:19
Copy link
Member Author

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

Do not merge this. This PR currently exists only so that we can run the e2e test suite with server hmr applied.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

created-by: Turbopack team PRs by the Turbopack team. tests Turbopack Related to Turbopack with Next.js. type: next

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants