Expose a new napi binding for accessing the source map _path_ of a source asset#95942
Draft
lukesandberg wants to merge 3 commits into
Draft
Expose a new napi binding for accessing the source map _path_ of a source asset#95942lukesandberg wants to merge 3 commits into
lukesandberg wants to merge 3 commits into
Conversation
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Contributor
Failing test suitesCommit: 1519927 | About building and testing Next.js
Expand output● Error overlay - RSC build errors › should error when catchError from next/error is imported in proxy.js |
Contributor
Stats from current PR🔴 5 regressions, 1 improvement
📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📝 Changed Files (2 files)Files with changes:
View diffspages-api.ru..time.prod.jsDiff too large to display pages.runtime.prod.jsDiff too large to display 📎 Tarball URLCommit: 1519927 |
gaearon
reviewed
Jul 20, 2026
gaearon
added a commit
to gaearon/next.js
that referenced
this pull request
Jul 20, 2026
Built on vercel#95942 (getSourceMapFilePath): findSourceMapURLDEV asks the bundler for the emitted source map file of the referenced chunk and returns its file: URL instead of inlining the payload as a data: URL. React embeds the returned URL into every eval'd fake stack frame function, each with a unique sourceURL, so inlined payloads made Node.js parse and retain a copy of a potentially multi-megabyte source map per fake function in a never-evicted cache, and made every eval spend time linear in the payload size. On a component-heavy repro one page load dropped from 29s to 7s (3s with a release binding) and from 2.7GB to 0.3GB of heap, with 2763 fake scripts referencing 0.2MB of URLs instead of 1.3GB of inlined payloads. file: URLs keep working for every consumer, unlike data: (works everywhere, costs the above) or dev-server http: URLs (not resolvable by Node.js or the dedicated Chrome DevTools frontend): - attached debuggers read the emitted map from disk, whenever they attach, - terminal symbolication resolves fake frames by devirtualizing them to the underlying chunk, whose source map Node.js knows. Also canonicalize devirtualized URLs to match Node.js' percent-encoded cache keys (e.g. chunks named [root-of-the-server]), and normalize single-slash file: URLs when printing frames. - the implementation hook is shared via globalThis since source-maps is compiled both into the server runtime bundles (where Flight clients run) and next/dist/server (where the dev server registers it). Includes a fixup for vercel#95942: append .map to the returned path (see SourceMapAsset::path); the fake-frame e2e test caught the chunk path being returned once the file: transport was active. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gaearon
added a commit
to gaearon/next.js
that referenced
this pull request
Jul 20, 2026
Built on vercel#95942 (getSourceMapFilePath): findSourceMapURLDEV asks the bundler for the emitted source map file of the referenced chunk and returns its file: URL instead of inlining the payload as a data: URL. React embeds the returned URL into every eval'd fake stack frame function, each with a unique sourceURL, so inlined payloads made Node.js parse and retain a copy of a potentially multi-megabyte source map per fake function in a never-evicted cache, and made every eval spend time linear in the payload size. On a component-heavy repro one page load dropped from 29s to 7s (3s with a release binding) and from 2.7GB to 0.3GB of heap, with 2763 fake scripts referencing 0.2MB of URLs instead of 1.3GB of inlined payloads. file: URLs keep working for every consumer, unlike data: (works everywhere, costs the above) or dev-server http: URLs (not resolvable by Node.js or the dedicated Chrome DevTools frontend): - attached debuggers read the emitted map from disk, whenever they attach, - terminal symbolication resolves fake frames by devirtualizing them to the underlying chunk, whose source map Node.js knows. Also canonicalize devirtualized URLs to match Node.js' percent-encoded cache keys (e.g. chunks named [root-of-the-server]), and normalize single-slash file: URLs when printing frames. - the implementation hook is shared via globalThis since source-maps is compiled both into the server runtime bundles (where Flight clients run) and next/dist/server (where the dev server registers it). Includes a fixup for vercel#95942: append .map to the returned path (see SourceMapAsset::path); the fake-frame e2e test caught the chunk path being returned once the file: transport was active. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gaearon
added a commit
to gaearon/next.js
that referenced
this pull request
Jul 20, 2026
Built on vercel#95942 (getSourceMapFilePath): findSourceMapURLDEV asks the bundler for the emitted source map file of the referenced chunk and returns its file: URL instead of inlining the payload as a data: URL. React embeds the returned URL into every eval'd fake stack frame function, each with a unique sourceURL, so inlined payloads made Node.js parse and retain a copy of a potentially multi-megabyte source map per fake function in a never-evicted cache, and made every eval spend time linear in the payload size. On a component-heavy repro one page load dropped from 29s to 7s (3s with a release binding) and from 2.7GB to 0.3GB of heap, with 2763 fake scripts referencing 0.2MB of URLs instead of 1.3GB of inlined payloads. file: URLs keep working for every consumer, unlike data: (works everywhere, costs the above) or dev-server http: URLs (not resolvable by Node.js or the dedicated Chrome DevTools frontend): - attached debuggers read the emitted map from disk, whenever they attach, - terminal symbolication resolves fake frames by devirtualizing them to the underlying chunk, whose source map Node.js knows. Also canonicalize devirtualized URLs to match Node.js' percent-encoded cache keys (e.g. chunks named [root-of-the-server]), and normalize single-slash file: URLs when printing frames. - the implementation hook is shared via globalThis since source-maps is compiled both into the server runtime bundles (where Flight clients run) and next/dist/server (where the dev server registers it). Includes a fixup for vercel#95942: append .map to the returned path (see SourceMapAsset::path); the fake-frame e2e test caught the chunk path being returned once the file: transport was active. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
lukesandberg
force-pushed
the
lukesandberg/get_source_map_url_sync
branch
from
July 20, 2026 02:20
f8fdc4c to
7734b44
Compare
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
gaearon
added a commit
that referenced
this pull request
Jul 20, 2026
Built on #95942 (getSourceMapFilePath): findSourceMapURLDEV asks the bundler for the emitted source map file of the referenced chunk and returns its file: URL instead of inlining the payload as a data: URL. React embeds the returned URL into every eval'd fake stack frame function, each with a unique sourceURL, so inlined payloads made Node.js parse and retain a copy of a potentially multi-megabyte source map per fake function in a never-evicted cache, and made every eval spend time linear in the payload size. On a component-heavy repro one page load dropped from 29s to 7s (3s with a release binding) and from 2.7GB to 0.3GB of heap, with 2763 fake scripts referencing 0.2MB of URLs instead of 1.3GB of inlined payloads. file: URLs keep working for every consumer, unlike data: (works everywhere, costs the above) or dev-server http: URLs (not resolvable by Node.js or the dedicated Chrome DevTools frontend): - attached debuggers read the emitted map from disk, whenever they attach, - terminal symbolication resolves fake frames by devirtualizing them to the underlying chunk, whose source map Node.js knows. Also canonicalize devirtualized URLs to match Node.js' percent-encoded cache keys (e.g. chunks named [root-of-the-server]), and normalize single-slash file: URLs when printing frames. - the implementation hook is shared via globalThis since source-maps is compiled both into the server runtime bundles (where Flight clients run) and next/dist/server (where the dev server registers it). Includes a fixup for #95942: append .map to the returned path (see SourceMapAsset::path); the fake-frame e2e test caught the chunk path being returned once the file: transport was active. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gaearon
added a commit
that referenced
this pull request
Jul 20, 2026
Built on #95942 (getSourceMapFilePath): findSourceMapURLDEV asks the bundler for the emitted source map file of the referenced chunk and returns its file: URL instead of inlining the payload as a data: URL. React embeds the returned URL into every eval'd fake stack frame function, each with a unique sourceURL, so inlined payloads made Node.js parse and retain a copy of a potentially multi-megabyte source map per fake function in a never-evicted cache, and made every eval spend time linear in the payload size. On a component-heavy repro one page load dropped from 29s to 7s (3s with a release binding) and from 2.7GB to 0.3GB of heap, with 2763 fake scripts referencing 0.2MB of URLs instead of 1.3GB of inlined payloads. file: URLs keep working for every consumer, unlike data: (works everywhere, costs the above) or dev-server http: URLs (not resolvable by Node.js or the dedicated Chrome DevTools frontend): - attached debuggers read the emitted map from disk, whenever they attach, - terminal symbolication resolves fake frames by devirtualizing them to the underlying chunk, whose source map Node.js knows. Also canonicalize devirtualized URLs to match Node.js' percent-encoded cache keys (e.g. chunks named [root-of-the-server]), and normalize single-slash file: URLs when printing frames. - the implementation hook is shared via globalThis since source-maps is compiled both into the server runtime bundles (where Flight clients run) and next/dist/server (where the dev server registers it). Includes a fixup for #95942: append .map to the returned path (see SourceMapAsset::path); the fake-frame e2e test caught the chunk path being returned once the file: transport was active. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gaearon
added a commit
that referenced
this pull request
Jul 20, 2026
Built on #95942 (getSourceMapFilePath): findSourceMapURLDEV asks the bundler for the emitted source map file of the referenced chunk and returns its file: URL instead of inlining the payload as a data: URL. React embeds the returned URL into every eval'd fake stack frame function, each with a unique sourceURL, so inlined payloads made Node.js parse and retain a copy of a potentially multi-megabyte source map per fake function in a never-evicted cache, and made every eval spend time linear in the payload size. On a component-heavy repro one page load dropped from 29s to 7s (3s with a release binding) and from 2.7GB to 0.3GB of heap, with 2763 fake scripts referencing 0.2MB of URLs instead of 1.3GB of inlined payloads. file: URLs keep working for every consumer, unlike data: (works everywhere, costs the above) or dev-server http: URLs (not resolvable by Node.js or the dedicated Chrome DevTools frontend): - attached debuggers read the emitted map from disk, whenever they attach, - terminal symbolication resolves fake frames by devirtualizing them to the underlying chunk, whose source map Node.js knows. Also canonicalize devirtualized URLs to match Node.js' percent-encoded cache keys (e.g. chunks named [root-of-the-server]), and normalize single-slash file: URLs when printing frames. - the implementation hook is shared via globalThis since source-maps is compiled both into the server runtime bundles (where Flight clients run) and next/dist/server (where the dev server registers it). Includes a fixup for #95942: append .map to the returned path (see SourceMapAsset::path); the fake-frame e2e test caught the chunk path being returned once the file: transport was active. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gaearon
added a commit
that referenced
this pull request
Jul 20, 2026
Built on #95942 (getSourceMapFilePath): findSourceMapURLDEV asks the bundler for the emitted source map file of the referenced chunk and returns its file: URL instead of inlining the payload as a data: URL. React embeds the returned URL into every eval'd fake stack frame function, each with a unique sourceURL, so inlined payloads made Node.js parse and retain a copy of a potentially multi-megabyte source map per fake function in a never-evicted cache, and made every eval spend time linear in the payload size. On a component-heavy repro one page load dropped from 29s to 7s (3s with a release binding) and from 2.7GB to 0.3GB of heap, with 2763 fake scripts referencing 0.2MB of URLs instead of 1.3GB of inlined payloads. file: URLs keep working for every consumer, unlike data: (works everywhere, costs the above) or dev-server http: URLs (not resolvable by Node.js or the dedicated Chrome DevTools frontend): - attached debuggers read the emitted map from disk, whenever they attach, - terminal symbolication resolves fake frames by devirtualizing them to the underlying chunk, whose source map Node.js knows. Also canonicalize devirtualized URLs to match Node.js' percent-encoded cache keys (e.g. chunks named [root-of-the-server]), and normalize single-slash file: URLs when printing frames. - the implementation hook is shared via globalThis since source-maps is compiled both into the server runtime bundles (where Flight clients run) and next/dist/server (where the dev server registers it). Includes a fixup for #95942: append .map to the returned path (see SourceMapAsset::path); the fake-frame e2e test caught the chunk path being returned once the file: transport was active. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Fixes review feedback on get_source_map_file_path: - It returned the chunk's file:// URL, not the source map's. Resolve the chunk's referenced SourceMapAsset and use its own path(), which is authoritative in every mode (content-hashed prod client chunks derive the map name from the map's own content, so <chunk>.map is wrong there). - Client source map assets live on a VirtualFileSystem; rebase them onto the disk-backed node_root (as emit does) before building the file:// URL. - Discriminate server-vs-client by whether a chunk exists at the path and references a SourceMapAsset, instead of generating the source map content just to test is_content() -- the file-path getter no longer pays for source-map codegen. Also document the production-extension path in get_source_map_asset.
lukesandberg
force-pushed
the
lukesandberg/get_source_map_url_sync
branch
from
July 20, 2026 16:47
e9a61d9 to
1519927
Compare
lukesandberg
commented
Jul 20, 2026
| } else { | ||
| // Not under a known output root (e.g. produced on some other filesystem); we can't map | ||
| // it to a disk `file://` URL. | ||
| return Ok(Vc::cell(None)); |
Contributor
Author
There was a problem hiding this comment.
this is an error condition
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.
Add a new synchronous napi endpoint for computing the sourcemap filename from a source in dev
This can be used by
findSourceMapURLDEVto create a more efficient solution in the future