Turbopack: enable server HMR for app route handlers#91466
Draft
wbinnssmith wants to merge 1 commit intocanaryfrom
Draft
Turbopack: enable server HMR for app route handlers#91466wbinnssmith wants to merge 1 commit intocanaryfrom
wbinnssmith wants to merge 1 commit intocanaryfrom
Conversation
nextjs-bot
added
created-by: Turbopack team
Collaborator
Failing test suitesCommit: c011b8e | About building and testing Next.js
Expand output● twoslash › should annotate twoslash types default ● twoslash › should annotate twoslash types esnext
Expand output● app dir client cache with parallel routes › prefetch={true} › should re-use the cache for the full page, only for 5 mins |
Merging this PR will not alter performance
Comparing 
Footnotes
|
wbinnssmith
force-pushed
the
wbinnssmith/server-hmr-routes
branch
from
aeb6fd2 to
abbe1d9
Compare
Collaborator
Stats from current PR🔴 1 regression
📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📝 Changed Files (8 files)Files with changes:
View diffsapp-route-ex..ntime.dev.jsDiff too large to display app-route-ex..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route-tu..ntime.dev.jsDiff too large to display app-route-tu..time.prod.jsDiff too large to display app-route.runtime.dev.jsDiff too large to display app-route.ru..time.prod.jsDiff too large to display 📎 Tarball URL |
wbinnssmith
force-pushed
the
wbinnssmith/server-hmr-routes
branch
3 times, most recently
from
78ba0d7 to
74c72dc
Compare
App router handlers are already built with the Turbopack runtime, so they can use server HMR. We also already get subscription events for their chunks. However, unlike app pages which use `__next_app__.require()` for dynamic devModuleCache lookup, route handlers capture userland exports statically in AppRouteRouteModule at construction time. This change makes routes behave a lot like pages, dynamically loading the user's code when requests are made. This way, we can freely invalidate and reload it when changes are made without evicting the entire require cache. This change removes the `isAppPage` restriction from `usesServerHmr`, extending server HMR coverage to all App Router entries (pages and route handlers) built with the Node.js runtime. For route handlers, we also clear the entry chunk from Node.js `require.cache` on each rebuild so the next `requirePage()` call re-executes the entry and obtains fresh module exports from `devModuleCache` (which HMR updates in-place). Test Plan: Added an additional e2e test, `with-dep`
wbinnssmith
force-pushed
the
wbinnssmith/server-hmr-routes
branch
from
74c72dc to
c011b8e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
App router handlers are already built with the Turbopack runtime, so they can use server HMR. We also already get subscription events for their chunks. However, unlike app pages which use
__next_app__.require()for dynamic devModuleCache lookup, route handlers capture userland exports statically in AppRouteRouteModule at construction time. This change makes routes behave a lot like pages, dynamically loading the user's code when requests are made. This way, we can freely invalidate and reload it when changes are made without evicting the entire require cache.Only
next devuses this lazy evaluation, asnext startcontinues to eagerly import route handlers.This change removes the
isAppPagerestriction fromusesServerHmr, extending server HMR coverage to all App Router entries (pages and route handlers) built with the Node.js runtime.For route handlers, we also clear the entry chunk from Node.js
require.cacheon each rebuild so the nextrequirePage()call re-executes the entry and obtains fresh module exports fromdevModuleCache(which HMR updates in-place).Test Plan: Added an additional e2e test,
with-dep