ng serve with esbuild source maps causing chrome, vscode to be extremely slow

[jpike88]

Command

serve

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

n/a, it's new with 16-rc0

Description

I have this configured in my angular.json

"sourceMap": {
								"scripts": true,
								"styles": true,
								"vendor": false,
								"hidden": false
							},

Yet it seems that all source maps, even from all my node_modules files are being loaded. this makes firing up a launch from vscode super slow as it tries to parse all the source maps. Chrome and VSCode locks up and CPU spikes for almost 10 seconds, and I'm on an M1 chip. Seems like there's just too much traffic than normal going between them.

Seems like vendorChunks option isn't supported, which may be a contributing factor to the problem.

When I hit a breakpoint in my code, just hitting 'step over' is very slow for it to happen.

Minimal Reproduction

ng serve with sourcemaps, im guessing problem may be worse with more vendor files but not sure

Exception or Error

No response

Your Environment

Angular CLI: 16.0.0-rc.0
Node: 16.14.2
Package Manager: npm 9.6.3
OS: darwin arm64

Angular: 16.0.0-rc.0
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.1600.0-rc.0
@angular-devkit/build-angular      16.0.0-rc.0
@angular-devkit/core               16.0.0-rc.0
@angular-devkit/schematics         16.0.0-rc.0
@angular/cdk                       16.0.0-next.5
@angular/flex-layout               15.0.0-beta.42
@angular/material                  16.0.0-next.5
@angular/material-moment-adapter   16.0.0-next.5
@schematics/angular                16.0.0-rc.0
rxjs                               7.8.0

### Anything else relevant?

my own notes... `sourceMapPathOverrides` was changed from 
`"webpack:///./src/*": "${workspaceFolder}/client/src/*"`
to `"http://localhost:4200/*": "${workspaceFolder}/client/*"`
`webroot` was changed from `"webRoot": "${workspaceFolder}",` to `"webRoot": "${workspaceFolder}/client",`

[clydin]

@jpike88 Thank for you testing out the new functionality. The vendor source map issues should be corrected in the latest prerelease (16.0.0-rc.1).
If you have some time, can you try out the latest prerelease to see if it resolves your issue?

[jpike88]

The initial long slow load is now fixed. However, there are still big delays when:

• setting a breakpoint and having that breakpoint come up 'red' to indicate its locked to the correct line of source
• stepping though code is unusable, delay takes too long
• trying to terminate chrome from vscode takes like 10 seconds instead of being instant

[jpike88]

It also seems like outputPath not being used as the staging folder anymore when doing ng serve with esbuild enabled? That makes it hard to locate and debug stuff on disk.

[alan-agius4]

Hi @jpike88,

I did a problem related to the debugging experience and these are caused because vscode debugger keeps waiting for the terminal output to contain Application bundle generation complete but this never happens with esbuild builder. I have a PR to address this: #25063.

I also noticed that you mentioned that you have sourceMapPathOverrides configured, this option is not needed when using the Angular CLI. I suggest you use the default vscode config provided when generating a new Angular workspace.

• https://github.com/angular/angular-cli/blob/main/packages/schematics/angular/workspace/files/__dot__vscode/launch.json.template
• https://github.com/angular/angular-cli/blob/main/packages/schematics/angular/workspace/files/__dot__vscode/tasks.json.template

I do not follow what you mean outputPath is not being used for staging, during development files are never emitted on disk both with webpack and esbuild.

If you are still experiencing performance issues while debugging it would be great if you can provide a minimal reproduction that we can take a look at.

[jpike88]

Disregard the outputpath comment...

I've removed the sourceMapPathOverrides comment, but needed to change the webRoot to ${workspaceFolder}/client which makes sense as I have a monorepo, client folder contains angular libs etc

I'll wait for next release with the above PR, and continue to look.

[jpike88]

So I can collect as much relevant debugging info as possible, can you give me tips and what you'd want me to enable/profile to help you?

[alan-agius4]

While testing I did a mono repo and I did need to set the webRoot.

Anyhow, if the problem persists after todays release you can try to enable vscode launcher trancing by adding trace: true in the launcher config. Potentially you could also try https://github.com/microsoft/vscode/wiki/Performance-Issues#visual-studio-code-is-sluggish

[jpike88]

Just updated to 16.0.0-rc.2, same problem still exists. I should repeat that this problem does NOT exist if I don't use esbuild, things work just fine (very snappy). On Macbook M1 Max, so any slowdowns would have to be catastrophic for me to notice a problem.

Trace attached.
vscode-debugadapter-442f5607.json.gz

In the below traces, the Chrome window opened and just froze while loading the PWA, it became unresponsive. There is a fundamentally different way the esbuild output is working here...
vscode-debugadapter-5661ac32.json.gz
vscode-debugadapter-2dbde9ea.json.gz
vscode-debugadapter-6c19755f.json.gz

[jpike88]

I think I found the issue.

The esbuild output seems to be outputting all source maps (including vendor source maps) into an inline base64, appending a huge string to the end of the main.js file. The webpack version provides the source maps as a seperate .js.map file.

It's a massive string (55mb). Just trying to deserialize it is breaking almost all the tools I have... I had to use unix commands to decode it successfully.

I have sourceMap.vendor as false in the configuration.

Solutions:

• respect the sourceMap.vendor configuration setting (don't emit vendor if sourceMap.vendor is set to false)
• don't append the string to the main.js file, seperate it into a .js.map.

[alan-agius4]

Hi @jpike88,

Thanks for getting to the bottom of this.

• Inline sourcemaps
  This is actually caused by Vite, as it will always inline sourcemaps. However, I do have a workaround for this. see perf(@angular-devkit/build-angular): do not inline sourcemap when using vite dev-server #25082

• Vendor sourcmaps
  This option is respected, and vendor sourcemaps are not processed. What you are seeing in the sourcemap is the actual JS content which is the same behavior with the webpack builder.

[jpike88]

@alan-agius4 I think you may be incorrect about the Vendor source maps point.

I've updated to latest version (16.0.0-rc.3).

I see that the main.js.map is now served as a seperate file.

With esbuild enabled... main.js.map is 41.6MB.
Without it enabled... main.js.map is 9.5MB.

See screenshot below... dump.map.js is esbuild, dump2.map.js is webpack. All I did was just remove the -esbuild bit in angular.json, so it's definitely same configuration.

Searching for a vendor related function shows it's being included in the esbuild main.js.map

Whereas in the webpack main.js.map, it's not found.

[alan-agius4]

That is expected since with webpack that module is not in main.js but in vendor.js. With esbuild there is not possible to do vendor chunking.

[jpike88]

This makes esbuild server a no-go for any projects except for ones using a small amount of vendor libraries, anything bigger causes the source map file to bloat and create performance issues for debugging. So I'm basically stuck with the webpack builder...

I guess I'll just subscribe to evanw/esbuild#207 and wait.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}