CODEWITHSUNDEEP
visual-studio-code
nazbot
nazbot

Reputation: 1697

Visual Studio Code - Node debugger breakpoints not being hit

I am trying to use VSCode to debug a node app I am running.

I launch the app in a separate terminal and then use the attach to process configuration to hook into it.

The attaching works correctly and I get a side panel that says 'loaded scripts' with the files in my project. If I click on one of those and set breakpoints there it will work correctly.

If I set a breakpoint on a file I open through the VSCode editor the breakpoint is greyed out and when I hover over it will say 'Breakpoint set but not yet bound'.

How can I make it so that the breakpoints I set on the code are bound?

Upvotes: 83

Views: 145370

Answers (21)

midenok
midenok

Reputation: 1223

So for newbies like me who vaguely understand how Node apps work there is client side and server side. You can run server-side and its breakpoints will work, but if you place breakpoints into client-side code they will not be activated. To catch client-side breakpoints you should:

  1. Ensure your middleware activates source-map:
module.exports = {
    // other configurations...
    devtool: 'inline-source-map', // or 'source-map'
};

That is done in webpack config, in my case it is:

var webpackConfig = merge(baseWebpackConfig, {
    ...
    devtool: config.build.productionSourceMap ? 'source-map' : false,

I'm not sure if it is universal advice for any other middleware than webpack or whether is it required step, please correct me if I'm wrong.

  1. Run your server by any means, ether from VSCode or from separate terminal. If it launches page in browser just ignore, don't close as it will/may stop the server. Your debugging target is not this page.

  2. Add Launch Chrome configuration into your launch.json. Mine looks like this:

        {
            "name": "Launch Chrome",
            "request": "launch",
            "type": "chrome",
            "url": "http://localhost:8080",
            "webRoot": "${workspaceFolder}",
            "sourceMaps": true
        },

The only handmade editing I did is adding last line "sourceMaps": true.

  1. Launch this config. Viola, it works! It opens second page in your browser and stops at breakpoint.

VSCode version is 1.96.3 with some Node and JS Debugger extensions installed. No any special config for these extensions was done. The most important and sole required extension here is JaveScript Debugger, I guess, and I use Nightly version of it.

Upvotes: -1

Edhar Dowbak
Edhar Dowbak

Reputation: 2828


I had a similar problem, I fixed it by appending /src to the "webRoot" path.


Originally my "webRoot" property read:

 "webRoot": "${workspaceFolder}"

Now my webRoot path reads:

"webRoot": "${workspaceFolder}/src",

My ./.vscode/launch.json:


    {
      // Use IntelliSense to learn about possible attributes.
      // Hover to view descriptions of existing attributes.
      // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
      "version": "0.2.0",
      "configurations": [
        {
          "type": "chrome",
          "request": "launch",
          "name": "Launch Chrome",
          "url": "http://localhost:3000",
          "webRoot": "${workspaceFolder}/src",
          "trace": true
        }
      ]
    }

Upvotes: 14

hammadian
hammadian

Reputation: 323

I tried this first after adding few break points:

Debug: toggle auto attach

I choose smart attach.

I ran from the integrated terminal node run web (the script I want to debug), it said debugger attached, but didn't stop at the break point. Then I tried:

debug: javascript debug terminal

and ran node run web from it, now the script stops at the break point.

Upvotes: 0

Anton
Anton

Reputation: 940

I have absolutely no idea why this worked for me but it did. I was running VS Code 1.85.1 with node 18.18.x. I upgraded to the latest LTS 20.10.0 and breakpoints are working again.

Upvotes: 1

TeaDrinker
TeaDrinker

Reputation: 483

Just for record, I use ts-node (esm), I changed "args":["${file}"] to "args":["${workspaceFolder}/IHaveToSpecifyDamnFileName.ts"] in launch.json and boom, it worked. I don't know why, but fvck microsoft!

Upvotes: 0

ansavchenco
ansavchenco

Reputation: 685

For me the problem was that I forgot to set "sourceMap": true in my tsconfig.json file.

Upvotes: 3

SSchmid
SSchmid

Reputation: 441

If all this doesnt work - consider starting your vsCode in the correct folder (the root directory, e.g. C:\Users\user\programming\RandomApp).

This is also why some people need to specify "/src" to their workspace variable (just a wild guess) and others dont.

Start it in the correct Folder and you dont need the /src parts in the launch.json file.

for me this launch.json works with vscode version 1.59.1

{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
    {
        "type": "pwa-chrome",
        "request": "launch",
        "name": "Launch Chrome against localhost",
        "url": "http://localhost:8100",
        "webRoot": "${workspaceFolder}"
    }
]

}

Upvotes: 1

rnoftz
rnoftz

Reputation: 23

@alkasai has the correct answer.

But, it also matters which source code folder was added to your workspace. My repository structure is as such: C:\git\parent_folder\child_folder\src

My breakpoints were not working, so long as 'parent_folder' was the folder added to my workspace and my 'webRoot' entry looked like this:

"webRoot": "${workspaceRoot}",

But, if I added '/child_folder' to 'webRoot' (e.g. "webRoot": "${workspaceRoot}/child_folder"), the breakpoints worked.

However, if I removed 'parent_folder' from my VS Code workspace, and instead added 'child_folder' to the workspace (thus changing the underlying value of the '${workspaceRoot}' variable value), the original entry (without the '/child_folder' subfolder reference) caused the breakpoints to be activated.

Upvotes: 0

java-addict301
java-addict301

Reputation: 4146

I am running Docker Compose with the VSCode debugger and in my case, some of the breakpoints I set show unbounded and some show as bounded, even after trying the solutions above.

It seems the unbounded ones are outside of functions (on require or variable initialization statements for example).

I can only assume this is because the debugger attach runs after the docker containers have started (and hence these breakpoints are unreachable).

Upvotes: 0

Mike
Mike

Reputation: 699

The very first thing you should check is the entry point - the first line of code that gets executed. If that one can bound a breakpoint, then you know your other breakpoints are unbound because something between the time your other breakpoints are met is pre-empted by an error introduced. Your code is not reachable in that case and the IDE can detect that your module is not loaded at all.

Upvotes: 1

John Doherty
John Doherty

Reputation: 4125

I had this issue with VSCode 1.52.1, the fix that worked for me was:

  1. Disable debug.javascript.usePreview via Code > Preferences > Settings

  2. Add "localRoot": "${workspaceFolder}/" to launch.json

  3. Add "remoteRoot": "${workspaceFolder}/" to launch.json

Upvotes: 9

Pavan Joshi
Pavan Joshi

Reputation: 61

I faced this issue as recently as yesterday after upgrading to VSCode 1.52.1. Debugger which was previously working fine suddenly started showing "Unbound Breakpoint". This was happening for all the breakpoints I was trying to set regardless of the place/file/line in code. I then had to add the "localRoot" property and make it point to my source code folder for it to start working again. Hope this helps. My launch.json configuration now looks like this

    {
        "name": "Attach by Process ID",
        "processId": "${command:PickProcess}",
        "request": "attach",
        "skipFiles": [
            "<node_internals>/**"
        ],
        "localRoot": "${workspaceFolder}/Source",
        "type": "pwa-node"
    }

Upvotes: 4

Michael Richter
Michael Richter

Reputation: 3

I'm using this configuration for debugging a TypeScript project:

        {
            "name": "Debug API",
            "request": "attach",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "type": "pwa-node",
            "sourceMaps": true,
            "outFiles": [
                "${workspaceFolder}/**/*.js",
                "!**/node_modules/**"
            ]
        },

outFiles did the trick and bound my breakpoints (VS Code 1.51.1).

Upvotes: 0

alkasai
alkasai

Reputation: 4033

Try this configuration in your launch file:

{
    "name": "Attach to Process",
    "type": "node",
    "protocol": "inspector",
    "request": "attach",
    "stopOnEntry": false,
    "port": 5858,
    "localRoot": "${workspaceRoot}",
    "remoteRoot": "/somepath/myprojectroot",
    "sourceMaps": true
}

Make sure the remoteRoot is correct path, otherwise it won't know where to look for the source files.

Upvotes: 22

LEMUEL ADANE
LEMUEL ADANE

Reputation: 8846

On the VSCode settings search for 'debug javascript use preview', and then disable it. It should now bound all breakpoints.

Upvotes: 14

Jason Anderson
Jason Anderson

Reputation: 309

I'm late to the party but wanted to share what was causing my "Unbound Breakpoint" errors.

I have file A and B. File A called into File B (and was required at the top of File A). File A's breakpoints were working perfectly. File B's sometimes let me hit them but I wasn't getting the full debugging experience if it worked at all.

I finally realized the require statement at the top of File A had different casing than the actual folder structure. It was requireing /path/to/file, where it should have been /Path/To/File.

I fixed the path casing and the breakpoints in File B starting working again.

Upvotes: 1

Leonardo Leal
Leonardo Leal

Reputation: 61

I faced the same issue...
After i try a lot of launch config combinations, i found the correctly.

{
  "type": "node",
  "request": "attach",
  "name": "Attach Program",
  "protocol": "inspector",
  "restart": true,
  "skipFiles": [
    "<node_internals>/**"
  ],
  "localRoot": "${workspaceFolder}",
  "remoteRoot": "/",
}

Ps: I'm launch node script with nodemon using the --inspect parameter (that allow debugger to attach node).

Upvotes: 6

singingsingh
singingsingh

Reputation: 1432

To hit breakpoints you need to compile in debug mode. So when compiling the code using your tasks.json have debug flags enabled in your command attribute. C++ example :

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Compile Test",
      "type": "shell",
      "command": "g++ -g test.cpp",
      "presentation": {
        "echo": true,
        "reveal": "always",
        "focus": false,
        "panel": "shared",
        "showReuseMessage": true,
        "clear": true
      },
      "group": "build",
    }
  ]
}

I am talking about the -g flag in the "command": "g++ -g test.cpp",

Upvotes: -2

Linus
Linus

Reputation: 4783

I have a TypeScript project, which suddenly didn't hit breakpoints anymore. In my case I had to move the project folder out of my iCloud Drive folder. There were other indicators that this path wasn’t ok, like missing git gutter indicators, as well. Here is my debug launch config. Breakpoints placed in app.ts are being hit.

  {
    "type": "node",
    "request": "launch",
    "name": "Debug",
    "program": "${workspaceFolder}/src/app.ts",
    "sourceMaps": true,
    "protocol": "inspector",
    "cwd": "${workspaceFolder}",
    "outFiles": [
      "${workspaceFolder}/dist/**/*.js"
    ]
  }

Upvotes: 0

Quentin
Quentin

Reputation: 134

For me, just adding "localRoot": "${workspaceFolder}" to my default launch.json Configuration did the trick.

{
    "type": "node",
    "request": "launch",
    "name": "Launch Program",
    "program": "${workspaceFolder}/bin/www",
    "localRoot": "${workspaceFolder}"
}

Upvotes: 3

ICan
ICan

Reputation: 67

The plain truth is that VSCode 1.20 does not allow you to hit breakpoints.

I tried 1.21 too, it also does not let you do it.

I went back to 1.18 and it works just as expected, no problem.

Upvotes: 5

Related Questions