Debugging - Nx to automatically setup debugging configuration in vsCode on newly generated application

[un33k]

Description

Debugging is a natural part of any development lifecycle, for both distributed, and/or mono repos, alike. Nx users may benefit tremendously should the app-level generators automatically insert the relevant debugging information into the .vscode/{tasks,launch}.json files.

Motivation

Creating an Angular, or a NestJS, or any other app is very easy within the Nx workspace, which is meant to streamline and speed up the development process. That is all good till there is a need to attach to an application and step through some complex code, and that is all to avoid excessive use of console.log(s).

At that point, one can assume, setting up the debugging information turns into a monumental task. This is true since Nx moves things around to accommodates all variety of apps so they co-exist.

The same, let's say Angular app in Nx will give users a very hard time, should they try to set up the debugging information. However, if that application was created through NgCli, the setup would be a simple copy & paste of some configuration, right from the vsCode website.

Suggested Implementation

It would be great to automatically populate the .vscode/launch.json as well as .vcode/tasks.json with the necessary information regarding a newly generated application. Nx console already runs in & supports vsCode and the .vscode directory already exists, so we just need to add those two files.

One recommendation would be to add both launch <app> and attach <app>, so users can either have the launcher to start the app, then attach to it, or simply attached to an already laughed application.

[FrozenPandaz]

@un33k That sounds like a good workflow indeed. Perhaps you could set this up in a workspace-generator and share it with us while we figure out the details.

Personally, I've set up some tasks that were parameterized meaning I didn't need to add more config for each new app.

@Cammisuli @sandikbarr any ideas here? Could Nx Console help?

[Cammisuli]

Yes actually. I was looking into providing debugging configs for Nx through Nx Console 😉

[ciriousjoker]

In the meantime, does anyone have a working launch.json file for Angular where breakpoints are hit and chrome opens properly after nx serve is done?

[github-actions]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
If we missed this issue please reply to keep it active.
Thanks for being a part of the Nx community! 🙏

[ciriousjoker]

Any updates?

[PointSingularity]

In the meantime, does anyone have a working launch.json file for Angular where breakpoints are hit and chrome opens properly after nx serve is done?

@ciriousjoker Have you been able to do this successfully?
I am able to start chrome after nx serve finishes, but the breakpoints are unbound :\

[ciriousjoker]

@PointSingularity

{ 
   "version": "0.2.0", 
   "configurations": [ 
     { 
       "name": "Debug", 
       "type": "pwa-chrome", 
       "request": "launch", 
       "preLaunchTask": "Serve Frontend", 
       "url": "http://localhost:4200/#", 
       "webRoot": "${workspaceFolder}", 
       "sourceMapPathOverrides": { 
         "webpack:/*": "${webRoot}/*", 
         "/./*": "${webRoot}/*", 
         "/src/*": "${webRoot}/src/*", 
         "/*": "*", 
         "/./~/*": "${workspaceFolder}/node_modules/*" 
       } 
     } 
   ] 
 }

tasks.json:

{ 
   "version": "2.0.0", 
   "tasks": [ 
     { 
       "label": "Serve Frontend", 
       "type": "npm", 
       "script": "start", 
       "isBackground": true, 
       "presentation": { 
         "focus": true, 
         "panel": "dedicated" 
       }, 
       "group": { 
         "kind": "build", 
         "isDefault": true 
       }, 
       "problemMatcher": { 
         "owner": "typescript", 
         "source": "ts", 
         "applyTo": "closedDocuments", 
         "fileLocation": ["relative", "${cwd}"], 
         "pattern": "$tsc", 
         "background": { 
           "activeOnStart": true, 
           "beginsPattern": { 
             "regexp": "(.*?)" 
           }, 
           "endsPattern": { 
             "regexp": "Compiled |Failed to compile.", 
           } 
         } 
       } 
     } 
   ] 
 }

[PointSingularity]

@ciriousjoker Thank you for the reply!

This does start the app and opens up chrome, but the debugger doesn't attach, and the breakpoints are still unbound :\

Maybe I need to adjust the "webRoot" and "sourceMapPathOverrides" properties?

Browser Sources tab looks like this:

[ciriousjoker]

@PointSingularity Can't help you sorry.. for me it works perfectly :/

[PointSingularity]

@PointSingularity Can't help you sorry.. for me it works perfectly :/

@ciriousjoker Hey your code actually works!

I was just trying different things, but it turns out that Node version was the problem.
I was on Node 18.4.0 and this doesn't work, but the moment I switched to Node 16 it works as intended 😄
Not sure what got changed between those 2 versions in regard to the debugger though.
Thanks again!

Edit: Made it work on node 18.4.0 by adding '--host=127.0.0.1' to the start script.

...
 "start": "nx serve frontend-app --host=127.0.0.1",
...

[jonathan-barner]

I got debugging working with my node.js service as well, using this launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Debug myservice",
            "cwd": "${workspaceFolder}",
            "runtimeExecutable": "nx",
            "runtimeArgs": [
                "serve",
                "myservice",
                "--inspect"
            ],
            "skipFiles": [
                "<node_internals>/**",
                "${workspaceFolder}/node_modules/*"
            ],
            "outFiles": [
                "${workspaceFolder}/dist/**/*.js"
            ]
        }
        // repeat for each debuggable app
    ]
}

[github-actions]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
If we missed this issue please reply to keep it active.
Thanks for being a part of the Nx community! 🙏

[tonivj5]

Up

[FranciscoKloganB]

I upvote this. Joined the monorepo bandwagon, because of the possible benefits it brings regardidng code sharing, but so far I only hit dev-experience issues. Can't debug, sharing stuff isn't always straight forward... Starting to think that seperate mono repos is just easier and better, with some NPM packages here and there.

Being unable to debug applications, libs and tests out of the box is a massive pain for any developer and having to deep search google results in search of random solutions, which most of the times don't work due to evolving APIs and versions, is miserable.

[zackarydev]

Up :)

[MPFGlaser]

Up from me as well. :)

[arieller]

Any progress with this?

[AsmisAlan]

any progress ?

[surajkrishan]

any progress team ?

[FrozenPandaz]

@MaxKless is there something we can do with this in Nx Console? 👀

[MaxKless]

Hey everyone :) I'm going to add an Nx Console feature to automatically run a target through the debug terminal which should already be good for many cases. See the tracked issue here nrwl/nx-console#938

You're talking about browser-based applications, though, which need a launch configuration as you describe above. That seems like the job for a generator and not something we should do on the Nx Console side imo.

Could you elaborate on the specific issues you're running into trying to use the standard launch configurations specified by the VSCode docs? It seems to me like a bundled Angular + Nx app (for example) with source maps should work just as an Angular CLI app?
I'd be grateful for more in-depth information for what problems this potential generator would solve for everyone.

[MaxKless]

Hey!
I'm closing this in favor of nrwl/nx-console#2095

I'll work on a solution inside Nx Console that should automatically generate source maps when debugging.

Ultimately, there are going to be situations where we can't automatically generate source maps for you and you'll have to configure your specific tooling to include source maps in a dev build/serve.