Cannot debug application (VSCode + Chrome) invalid paths in main.js.map
See original GitHub issue- [ X ] I am running the latest version
- [ X ] I checked the documentation (nx.dev) and found no answer
- [ X ] I checked to make sure that this issue has not already been filed
- [ X ] I’m reporting the issue to the correct repository (not related to React, Angular or any dependency)
Expected Behavior
I should be able to set a breakpoint in MSCode and the breakpoint shall be bound to generated main.js.map
Current Behavior
The generated main.js.map file contains relative references that does not properly locate the source code.
The problem started after migrating our project to nx, but can be tested on any new project generated from scratch
Failure Information (for bugs)
This is a bug in the generation of the main.js.map file. (the tcs compiler?) but I don’t now how/when the map is generated from the moment I type: nx build myproject --prod
command
Steps to Reproduce
-
create a new nx workspace (npx create-nx-workspace@latest repro-workspace) select “angular” provide name ‘demo-debug’ select ‘SASS’
-
open project in ms-code “repro-workspace” is the folder to open
locate apps/demo-debug/src/app.component.ts edit app.component.ts file and add a single function
export class AppComponent {
title = 'demo-debug';
getString(): string {
return 'Hola Mundo';
}
}
edit the template file (app.component.html) to access the function
<h1>{{ getString() }}Welcome to {{ title }}!</h1>
Save all files In the terminal, type command:
nx serve
put a break point at line 12 of app.component.ts (return ‘Hola mundo’) the breakpoint turns red. It is set in ms-code but still there is no browser open
Create a launch.json file to launch chrome with debugging enabled under .vscode folder, create a file like this:
{
// Use IntelliSense para saber los atributos posibles.
// Mantenga el puntero para ver las descripciones de los existentes atributos
// Para más información, visite: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Lanzar Chrome contra localhost",
"url": "http://localhost:4200",
"webRoot": "${workspaceFolder}",
"userDataDir": "${workspaceFolder}/.vscode/chrome"
}
]
}
Launch chrome from vscode using the launch configuration.
The breakpoint remains grey and it is not bound to source code.
If you navigate the file main.js in chrome you’ll notice the paths are not correctly pointing to apps/demo-debug directory so there is no chance for the Chrome Debugger extension for VSCODE to locate the source file and bind the breakpoint
Context
ihr@mbp-de-ignacio repro-workspace % nx version
_ _ ____ _ ___
/ \ _ __ __ _ _ _| | __ _ _ __ / ___| | |_ _|
/ △ \ | '_ \ / _` | | | | |/ _` | '__| | | | | | |
/ ___ \| | | | (_| | |_| | | (_| | | | |___| |___ | |
/_/ \_\_| |_|\__, |\__,_|_|\__,_|_| \____|_____|___|
|___/
Angular CLI: 9.0.1
Node: 12.3.1
OS: darwin x64
Angular: 9.0.0
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Ivy Workspace: Yes
Package Version
-----------------------------------------------------------
@angular-devkit/architect 0.900.6
@angular-devkit/build-angular 0.900.1
@angular-devkit/build-optimizer 0.900.1
@angular-devkit/build-webpack 0.900.1
@angular-devkit/core 9.0.6
@angular-devkit/schematics 9.0.6
@angular/cli 9.0.1
@ngtools/webpack 9.0.1
@schematics/angular 9.0.6
@schematics/update 0.900.1
rxjs 6.5.3
typescript 3.7.5
webpack 4.41.2
ihr@mbp-de-ignacio repro-workspace % nx report
> NX Report complete - copy this into the issue template
@nrwl/angular : 9.1.2
@nrwl/cli : 9.1.2
@nrwl/cypress : 9.1.2
@nrwl/eslint-plugin-nx : Not Found
@nrwl/express : Not Found
@nrwl/jest : 9.1.2
@nrwl/linter : Not Found
@nrwl/nest : Not Found
@nrwl/next : Not Found
@nrwl/node : Not Found
@nrwl/react : Not Found
@nrwl/schematics : Not Found
@nrwl/tao : 9.1.2
@nrwl/web : Not Found
@nrwl/workspace : 9.1.2
typescript : 3.7.5
ihr@mbp-de-ignacio repro-workspace %
Please provide any relevant information about your setup:
Debugger for chrome 4.12.6 https://github.com/Microsoft/vscode-chrome-debug
You should be able to test this bug on your own existing project, just put a breakpoint in VSCode, open your app in Chrome and see how the breakpoint set in the app does not bind.
NOTE: breakpoints set in libraries that are serialised early in the .js.map file bind OK. It is just all breakpoints set after
/***/ "./$$_lazy_route_resource lazy recursive":
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:10 (1 by maintainers)
I ended up debugging with Firefox, without changing angular.json. This is from my launch.json, just in case anyone gets interested:
This config is respected by Firefox and its debugger extension, but it isn’t respected by Chrome and Debugger for Chrome (using Chrome’s counterparts pathMappings and/or sourceMapPathOverrides).
I don’t know if I’m missing something. It seems to me that it has to do with Chrome/Debugger Extension or the way webpack is doing its thing. I don’t know if it does behave differently on browsers or if it’s meant to be like this. Maybe I’m saying nonsense. 🤣 I made several tests, changing values, reading documentation and what I found curious (or it’s really strange behavior) is that every time we change webRoot or sourceMapPathOverrides, the debug view on Chrome DevTools seems to add a forward slash to webpack:/// (i.e. webpack:////). Also, Loaded Scripts on Run/Debug panel in VS Code shows different names from Chrome DevTools, but it seems to represent the same tree.
UPDATE This actually was happening using Chrome on Linux (Manjaro actually), on my Mac I got Chrome Debugging working by the following:
UPDATE 2 I found the issue happens on linux because of the new but yet unstable js debugger, set “debug.javascript.usePreview” to false on vscode settings, and it’s good to go.
Hope it helps. Cheers!
Clearing out “root” for me worked as well, but I am concerned. Will there be any side-effects associated with this?
@brandonroberts - I don’t think simply closing this is a good approach. This is an issue right out of the box with nx. Are there any better solutions?