SourceMaps don't bind on latest next.js version server side (Docker)

[jasonwilliams]

Describe the bug
Next.js now uses eval-source-map from version 9 onwards.
It looks like eval-source-map generates webpack-internal:///./ references.

I added the settings below but it makes no difference:

      "sourceMapPathOverrides": {
        "webpack-internal:///./": "${workspaceFolder}/"
      }

I wonder if

vscode-js-debug/src/targets/browser/browserPathResolver.ts

Lines 111 to 113 in e2191de

	if (parsed.protocol === 'webpack-internal:') {
	return undefined;
	}

has anything to do with it?

Should webpack-internal:///./ be added to this list?

vscode-js-debug/src/configuration.ts

Lines 931 to 939 in 4d7737f

	export function defaultSourceMapPathOverrides(webRoot: string): { [key: string]: string } {
	return {
	'webpack:///./~/*': `${webRoot}/node_modules/*`,
	'webpack:////*': '/*',
	'webpack://?:*/*': `${webRoot}/*`,
	'webpack:///([a-z]):/(.+)': '$1:/$2',
	'meteor://💻app/*': `${webRoot}/*`,
	};
	}

To Reproduce
Steps to reproduce the behavior:

1. Clone https://github.com/jasonwilliams/nextjs9-typescript-server-vscode-example
2. yarn install
3. docker-composer up
4. Launch -> launch server (Docker)
5. set a breakpoint in pages/index.tsx

Log File

VS Code Version: 1.51

[connor4312]

Thanks for the great issue as usual, this is actually an issue with resolveSourceMapLocations being narrowed. Previously for some reason I only removed the narrowing for launch rather than attach types. But I don't recall why I did this and I think it's wrong. Fixed in the next nightly. You don't need to specify a sourceMapPathOverride

[jasonwilliams]

This isn't fixed for me

My nightly version is 2020.11.1117

[connor4312]

To confirm, did you remove the sourceMapPathOverrides in the launch server (Docker) configuration?

[jasonwilliams]

@connor4312 I can confirm its the same whether I have sourceMapPathOverrides set or not. I removed sourceMapPathOverrides and it still doesn't bind and the output I get in diagnostics is the same.
On the test repo I tried launch and it does work for that. Did your change make it to my nightly version? Or maybe the problem is something else.

[jasonwilliams]

@connor4312 This is still broken for me on v2020.11.2317 can we re-open this issue? I can also confirm there is no sourceMapPathOverrides in my configuration

[jasonwilliams]

I've had a go at debugging this, and dusted off my local copy of js-debug. It looks like urlToAbsolutePath fails with webpack-internal:// urls.

You can see here on line 836 it returns an empty string:

However for other files it works fine:

I could be off here, but there's definitely something odd. My head hurts now

[connor4312]

Thanks for the issue. Apologies for the delay, I've been on vacation.

Interestingly, it looks like next.js builds differently depending on whether I clone and run it (yes, in Docker) on Windows versus OSX. On Windows, "file:///app/.next/server/static/development/pages/index.js" has the sourceMap. On OSX, it uses an eval sourcemap where the sourceURL of the evaluated script is set to webpack-internal:///./pages/index.tsx, which is not mapped by the default source map resolution paths. Setting resolveSourceMapLocations: null resolves the issue.

This is messy to solve, since setting the sourceURL in this way entirely overwrites the original location we otherwise would see over CDP. The goal of resolveSourceMapLocations was to avoid scripts in dependencies that are packaged and include sourcemaps from incorrectly mapping to user code. It seems like we need to allow webpack-internal:///* to map by default, and this will break that safety net.

But there are more people using next.js than there are people who will hit that issue.

[connor4312]

Actually, the scenario is narrower than I thought. For data URI sourcemaps, we use the path of the compiled file to see if we should resolve it. I put in a fix to remove the "protocol", so webpack-internal:///./pages/index.tsx will turn into /pages/index.tsx for matching purposes, which the default glob is capable of dealing with. So I put in a targeted fix.

[jasonwilliams]

Interestingly, it looks like next.js builds differently depending on whether I clone and run it (yes, in Docker) on Windows versus OSX. On Windows, "file:///app/.next/server/static/development/pages/index.js" has the sourceMap. On OSX, it uses an eval sourcemap where the sourceURL of the evaluated script is set to webpack-internal:///./pages/index.tsx, which is not mapped by the default source map resolution paths. Setting resolveSourceMapLocations: null resolves the issue.

Yep that sounds about right, they made that change intentionally here.
https://github.com/vercel/next.js/blob/7ce000b328305737099549bc186ddd3a39a2528b/packages/next/build/webpack/config/blocks/base.ts#L25-L36

Apparently eval source maps are flagged as suspicious by Windows Defender and block HMR (Hot Module Reloading)

[jasonwilliams]

Link to Windows Defender issue:
vercel/next.js#14266

Specifically this comment vercel/next.js#12797 (comment)

[jasonwilliams]

Thanks @connor4312 appreciate you looking at this, and hope you had a good vacation!

[connor4312]

Windows is always fun 🙂 Thanks for the info and wishes, spent a week hiking on the Oregon coast.

[jasonwilliams]

Setting resolveSourceMapLocations: null resolves the issue

Hey @connor4312 could you explain why setting this is required in NextJS projects? So hopefully i can add it to their documentation as i don't think this will be obvious to newcomers who want to debug

[roblourens]

vscode-debugadapter-b67ca636.json.gz

I still see an unresolved breakpoint, following the original steps, and adding resolveSourceMapLocations: null to the launch config

[connor4312]

@roblourens make sure to remove the sourceMapPathOverrides section as well -- apologies for not posting easy verification steps in a long thread:

1. Follow these instructions: SourceMaps don't bind on latest next.js version server side (Docker) #854 (comment)
2. But before step 4, remove these lines https://github.com/jasonwilliams/nextjs9-typescript-server-vscode-example/blob/f404275fb07599b4a8e4135e10d2a8d0fc10163d/.vscode/launch.json#L22-L24

Closing for re-verification attempt

[usuallyno]

This isn't fixed for me

My nightly version is 2020.11.1117

I've exactly the same bug but with the client side launcher.

It seems that "webpack://" is somehow mixed with the url..
How did you solve the problem?

my launch.json

   {
      "name": "Next.js: debug client-side",
      "type": "chrome",
      "request": "launch",
      "url": "http://localhost:3000",
      "skipFiles": [
        "<node_internals>/**",
        "${workspaceFolder}/node_modules/**/*.js",
        // "${workspaceFolder}/next"
      ]
    },

[ericdvb]

I'm not able to bind breakpoints for server side debugging in latest next.js (14.0.1 as of this writing, but also 13.5.6) using vs code. Jumping on this thread because it's unclear to me whether this is the same bug or something else.

Here's the relevant part of my launch.json:

    "configurations": [
        {
            "name": "Next.js: debug server-side",
            "type": "node",
            "address": "127.0.0.1",
            "port": 9229,
            "request": "attach",
            "sourceMaps": true,
            "skipFiles": ["<node_internals>/**"]
        },
...

my tsconfig.json includes "sourceMap:" true. I'm running my app using the following command: "NODE_OPTIONS='--inspect=9229' next dev.

I'm able to attach to the debugger, I see a log about it in the terminal window for my next app. If I use --inspect-brk, execution stops a next internals line (node_modules/next/dist/bin/next, I think). But any breakpoint I set in my api route (which is in app/api/.../route.ts) doesn't bind, and the troubleshooter shows some info about including "sourceMap": true in my tsconfig. Here's what it looks like in vs code in my file, and in the troubleshooter:

I've scoured the next.js debug docs, a bunch of github issues, and plenty of people's posts about similar issues (although they're mostly from 2022, so it's unclear to me if they're relevant to newer versions of next or setups that use the app folder. I've tried adding sourceMapPathOverrides with the value "webpack-internal:///./": "${workspaceFolder}/" to my launch.json, and maybe a couple of other solutions, but no luck.

Is it possible to use breakpoint debugging with app folder api routes in next 14.0.1?

Edit: Adding a debugger statement in my route.ts file got the debugger to stop on it. After that I was able to step through the file and subsequently I'm able to bind breakpoints. Why is this? Is it a reliable fix?

[connor4312]

Please file a new issue and collect information using the "Bug" issue template; your problem is not the one this issue pertains to.