fix(nextjs): Correct in_app for Turbopack dev server stack frames - #23248
Conversation
Turbopack's dev chunk names (node_modules_<pkg>_<hash>.js, [project]/...) defeat filenameIsInApp, so vendor frames are marked in_app and the real app crash frame is not. The dev symbolication processor already resolves frames back to their original source paths but preserved the wrong in_app via the ...frame spread. Re-derive in_app from the resolved path instead.
size-limit report 📦
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e0d8aed. Configure here.
| const vendorFrames = frames.filter(frame => frame.filename?.includes('node_modules')); | ||
| for (const vendorFrame of vendorFrames) { | ||
| expect(vendorFrame.in_app, `vendor frame ${vendorFrame.filename} should not be in_app`).toBe(false); | ||
| } |
There was a problem hiding this comment.
Vacuous vendor in_app assertion
Low Severity
The vendor in_app checks can pass without verifying any frames: vendorFrames is filtered and asserted in a loop, but nothing requires that filter to match. That weakens coverage for the half of this regression where vendor frames were wrongly marked in_app. Sibling tests in this app assert filtered collections are non-empty before checking their contents. Flagged because the PR review rules ask for thorough assertions of newly added behavior in fix tests.
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit e0d8aed. Configure here.
| filename: resolvedFilename, | ||
| // The parse-time `in_app` is derived from Turbopack's dev chunk names (`node_modules_<pkg>_<hash>.js`, | ||
| // `[project]/…`), which invert the classification. Re-derive it from the resolved original source path. | ||
| in_app: resolvedFilename ? !resolvedFilename.includes('node_modules') : frame.in_app, |
There was a problem hiding this comment.
Are the filenames always starting with this string? Then we could tighten this to .startsWith('node_modules_') 🤔
There was a problem hiding this comment.
I didn't want to make that assumption since it may rely on the project being in a workspace or something so the starting path wouldn't be node_modules_[...]
Also noticed that npm and yarn would yield absolute paths (/Users/...node_modules) at least from one test I tried. The downside is if someone does have a file called node_modules then it would be incorrectly tagged but I wonder how common is that.
chargome
left a comment
chargome
left a comment
There was a problem hiding this comment.
I think this is still overwritten in symbolication though according to the ticket
3 participants
Under
next devwith Turbopack, server-side stack frames get theirin_appclassification inverted: vendor code fromnode_modulesshows as in-app while the actual app crash frame shows as non-app.Turbopack's dev chunk naming flattens
node_modules/to underscores (node_modules_ai_<hash>.js) and prefixes app modules with[project]/, both of which defeatfilenameIsInApp.closes #23176