The debugger does not work in a monorepo when bundle size and sourcemaps go over a certain size

[ShravanSunder]

Describe the bug

The debugger does not work in a monorepo when bundle size and sourcemaps go over a certain size.

The locals (variable view on hover) stops working. And the line number of sourcemaps changes and is mismatched.

To Reproduce

I've create a reproduction repo with a gutted version of my project

https://github.com/ShravanSunder/vscode-debug-reproduction
@connor4312 i've invited you to it the project, please let me know if you can see it

I've tried many launch configurations with sourcemap settings for attching to the worker debugging.
In cloudflare's chrome debugger the line numbers and local variables values show up and are perfect. It seems to only be an issue with vscode debugger.

Log File

here is the trace:

vscode-debugadapter-04909eb4.json.gz

VS Code Version: 1.86.2

Additional context
Add any other context about the problem here.

[connor4312]

Thanks for the good repro. This is likely because you're debugging minified code. Minified code will rename variables and have control flow changes so that lines and stepping may not work in the same way you expect them to with a 1:1 compilation. Your minifier also does not appear to making a rename entry for coffeeRes, so trying to access it fails.

For a better developer experience, I recommend configuring your tools to not minify your code in dev mode.

[ShravanSunder]

@connor4312 I don't believe its due to magnification.

The code is always minified.

• However, when the bundle size is below a threshold it works fine i can see the runtime data in vscode.
• In the chrome debugger, with minification, i can always see the runtime data
• If the sourcemaps and other code exceed a certain size (also minified) i don't see it.

[connor4312]

What do you mean when you say "see runtime data"? Is the Variables view not populating?

For example, in coffeeRes, the intermediate variable is not emitted in generated code at all.

	const coffeeRes = await fetch('https://api.sampleapis.com/coffee/hot');
	const coffee = await coffeeRes.json();

gets minified as

let r=await(await fetch("https://api.sampleapis.com/coffee/hot")).json();

So there is no coffeeRes to inspect.

I recommend changing your wranger config to only minify your code in production.

[ShravanSunder]

Problem with not minifying

The problem with not minifying is that the sourmaps are too large and vs code just spins forever. It does this for more than 60s (i have a mac m1 with 32gb ram. I also tried with and without extra memory allocate to the typescript server in vscode).

@connor4312

Minification

i created this extra modules function. It has a bunch of large imports. If i enable it this is what i have for the locals and sourcemaps. The local variable names don't look scrambed, but they are not the same.

If i disable this function this is what i have

---

Notice that locals and variables are completly different. Both runtimes are minified. The variables in the scrambled example above are actually different.

the module that's disabled is just loading bundles. i've disabled that line in the hono router.

async function extraModules(c: Context) {
	try {
		const { Inngest } = await import('inngest');
		const inn = new Inngest({
			id: '123',
		});
		const { Inngest: I2 } = await import('inngest-revised');
		const inn2 = new I2({
			id: '123',
		});

		const SuperJSON = (await import('superjson')).default;
		const b = SuperJSON.parse('{"hello":"world"}');

		try {
			const b = toDurableObjectTrpcRouter(null as never, c.req.raw);
		} catch (e) {
			console.log(e);
		}

		const { pipe } = await import('rxjs');
		const p = pipe();

		const t = tRouter;

		//import { parse as large } from '@reallyland/esm';
		const large = (await import('@reallyland/esm')).parse;
		const m = large('fsdfds');
	} catch (e) {
		console.log(e);
	}
}

As mentioned with both with/without minfication, everything works with the wrangler chrome debugger.

• The vscode debugger freezes for locals without minifcations
• the vscode debugger does strange things when bundles go over a certain size and changes the locals and line items. There's a size in witch it seems to work with minification. And then it suddenly breaks in vs code as shown in reproduction
• It doesn't make sense that variable c becomes request in the second reproduction with large bundle size. I don't think that's due to minification

[connor4312]

The locals work for me without commenting things out -- could you share a trace log for a debug session where you get into the "stuck" state? It looks like the logs in the original issue were okay.

i created this extra modules function. It has a bunch of large imports. If i enable it this is what i have for the locals and sourcemaps. The local variable names don't look scrambed, but they are not the same.

Can you push the code with that function to a branch in your repo?

[ShravanSunder]

@connor4312
i just pushed the new commits

here is the trace with the module disabled
vscode-debugadapter-f99a6c1c.json.gz

here is the trace with modules enabled
vscode-debugadapter-fd379961.json.gz

[connor4312]

Thanks, I was able to reproduce the errors, seems like we had an off-by-one error which was pretty hard to see in unminified code, but in minified code where everything is one line it's more apparent.

I still didn't repro the case of the Variables view loading and never showing data -- do either of the log files you shared represent that?

[ShravanSunder]

@connor4312 The loading spinner was just with minify = false in wrangler.toml . i'll created a tracelog below. However, there is a issue while releasing a breakpoint unimified:

• if i put a breakpoint and it pauses while locals are spinning.
• if i release the breakpoint and try to get it running nothing happens and locals are still spinning
• I think the debugger is frozen? i'lve uploaded the trace log below

size minified vs unminified

• the size of js is 1.4mb and sourcemap 2.8mb.
• minified they are: 640kb js and 2.9mb sourcemap
• it doesn't seem like the sizes are so unreasonable to have the debugger lock like this?

vscode-debugadapter-d4cd0037.json.gz

---

[connor4312]

Thanks, I can reproduce with that. This is actually the runtime freezing when we ask for the source of worker.js, which is needed in order to compute renames. I was able to reproduce the issue in Chrome and have opened an issue for the folks who work on V8: https://issues.chromium.org/issues/326554286

You can set "sourceMapRenames": false, in your configuration to disable the debugger's handling of renames, which would avoid the issue. Or continue to debug minified code.

I will close this issue again as I fixed the problem that was on our side in the linked PR.

[ShravanSunder]

thanks a lot for your help! @connor4312

[amunger]

@connor4312 can you provide verification steps for the part that you fixed?

[connor4312]

1. Open this zip Archive.zip
2. Set a breakpoint somewhere in the quicksort function in index.js
3. In the JavaScript Debug Terminal, run node min.js
4. When the breakpoint is hit verify the names of variables in the Variables view are their original unminified versions