Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Break points do not work #14

Open
boris-beginin-lmnd opened this issue Nov 13, 2022 · 13 comments
Open

Break points do not work #14

boris-beginin-lmnd opened this issue Nov 13, 2022 · 13 comments

Comments

@boris-beginin-lmnd
Copy link

boris-beginin-lmnd commented Nov 13, 2022

Hey! First of all thx for your work.

For me for some reasons breakpoints do not work when i use this adapter(they work with node2 adapter but some other stuff do not)

I am able to connect to debugger and see remote process in DAP, but for some reason breakpoints are ignored.

Logs

[ INFO ] 2022-11-13T15:27:37Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/launch"
~                                       │ 18 [ INFO ] 2022-11-13T15:27:50Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/dap/operation"
~                                       │ 17
~                                       │ 16 [ INFO ] 2022-11-13T15:28:03Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/launch"
~                                       │ 15 [ INFO ] 2022-11-13T15:28:03Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/nodeRuntime"
~                                       │ 14 [ INFO ] 2022-11-13T15:28:07Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/dap/operation"
~                                       │ 13 [ INFO ] 2022-11-13T15:28:07Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"
~                                       │ 12 [ INFO ] 2022-11-13T15:28:08Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/dap/operation"
~                                       │ 11 [ INFO ] 2022-11-13T15:28:19Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"
~                                       │ 10 [ INFO ] 2022-11-13T15:28:19Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/dap/operation"
~                                       │  9 [ INFO ] 2022-11-13T15:28:24Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"
~                                       │  8 [ INFO ] 2022-11-13T15:28:30Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"
~                                       │  7 [ INFO ] 2022-11-13T15:28:36Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"
~                                       │  6 [ INFO ] 2022-11-13T15:28:42Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"
~                                       │  5 [ INFO ] 2022-11-13T15:28:49Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"
~                                       │  4 [ INFO ] 2022-11-13T15:28:55Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"
~                                       │  3 [ INFO ] 2022-11-13T15:29:01Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"
~                                       │  2 [ INFO ] 2022-11-13T15:29:08Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"
~                                       │  1 [ INFO ] 2022-11-13T15:29:14Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"
~                                       │517 [ INFO ] 2022-11-13T15:29:20Z+0100 ] ...eginin/.config/nvim/plugged/nvim-dap/lua/dap/session.lua:705 ]  "Telemetry" "js-debug/cdp/operation"

Config

for _, language in ipairs({ "typescript", "javascript" }) do
  require("dap").configurations[language] = {
    {
      type = "pwa-node",
      request = "attach",
      localRoot = "${workspaceFolder}",
      remoteRoot = "/",
      cwd = "${workspaceFolder}",
      name = "dev-env: service debugger",
      resolveSourceMapLocations = { "${workspaceFolder}/dist/**/*.js", "${workspaceFolder}/**", "!**/node_modules/**" },
      sourceMaps = true,
      protocol = "inspector",
      console = "integratedTerminal",
      port = 9229
    },
  }
end

JFYI works with the same config in vscode

@boris-beginin-lmnd
Copy link
Author

Okay thats strange, i am able to debug an entrypoint to app, but i cant debug api controllers 🤔

@mxsdev
Copy link
Owner

mxsdev commented Nov 14, 2022

Hi! Thanks for the nice words :)

Unfortunately I can't help much with the provided info. If you could provide code which creates the problem, ideally a minimum example, that would help me (as well as anyone else who has the bug or wants to contribute) approach the problem.

If you could also set your dap log level to TRACE that would be great, since then I can read through all the requests. There's also logging for this plugin - see the docs for info - which might be helpful (again, log level set to TRACE)

able to debug an entrypoint to app, i cant debug api controllers

Are these both done with attach?

There's a chance that the api backend might run the endpoints in separate threads, or run them in a separate process, which I know that this plugin sometimes has problems with.

@citosid
Copy link

citosid commented Apr 18, 2023

@mxsdev I have the same error. Here is a screenshot of my configuration and how it behaves:

image

As you can see, the debugger gets attached but it ignores the breakpoint.

I'm using a very basic configuration of AstroVim, here are the steps to replicate it:

git clone [email protected]:/AstroNvim/AstroNvim ~/.config/Test
git clone https://github.com/AstroNvim/user_example ~/.config/Test/lua/user
NVIM_APPNAME=Test nvim

And then modify the file ~/.config/Test/lua/user/plugins/dap.lua with this:

local lazy_dir = vim.fn.stdpath("data") .. "/lazy"

return {
  "mfussenegger/nvim-dap",
  enabled = vim.fn.has "win32" == 0,
  dependencies = {
    {
      "mxsdev/nvim-dap-vscode-js",
      opts = {
        debugger_path = string.format("%s/vscode-js-debug/", lazy_dir),
        adapters = { "pwa-node" }
      },
    },
    { "theHamsta/nvim-dap-virtual-text", config = true },
    { "rcarriga/nvim-dap-ui",            config = true },
    {
      "microsoft/vscode-js-debug",
      build = "npm install --legacy-peer-deps && npx gulp vsDebugServerBundle && mv dist out"
    }
  },
  config = function()
    local dap = require "dap"

    dap.configurations.typescript = {
      {
        type = "pwa-node",
        request = "attach",
        name = "Attach",
        processId = require 'dap.utils'.pick_process,
        cwd = "${workspaceFolder}",
      }
    }
  end,
}

One thing that I do different is the code is running in kubernetes, so I need to open a tunnel. However, with VSCode it works fine.

@citosid
Copy link

citosid commented Apr 19, 2023

Found the problem. Will post later today the error and will add a PR to add documentation on it

Thanks for your awesome work with this tool!

@citosid
Copy link

citosid commented Apr 19, 2023

For all those interested, basically the issues I had were two:

  1. dap using js-debug-adapter instead of the one installed in the plugin. In order to fix it, I had to change the debugger_path to the one installed with this plugin
  2. localRoot and remoteRoot are needed. Otherwise, the debugger does not know the request is going through that breakpoint.

I use AstroNvim, with Lazy.nvim so my configuration in the end is like this:

-- file ~/.config/nvim/lua/user/plugins/dap.lua
local lazy_dir = vim.fn.stdpath("data") .. "/lazy"

return {
  "mfussenegger/nvim-dap",
  dependencies = {
    {
      "mxsdev/nvim-dap-vscode-js",
      opts = {
        debugger_path = string.format("%s/vscode-js-debug/", lazy_dir),
        adapters = { "pwa-node" }
      },
    },
    { "theHamsta/nvim-dap-virtual-text", config = true },
    { "rcarriga/nvim-dap-ui",            config = true },
    {
      "microsoft/vscode-js-debug",
      build = "npm install --legacy-peer-deps && npx gulp vsDebugServerBundle && mv dist out"
    }
  },
  config = function()
    local dap = require "dap"

    dap.configurations.typescript = {
      {
        type = "pwa-node",
        request = "attach",
        name = "Attach",
        processId = require 'dap.utils'.pick_process,
        skipFiles = { "<node_internals>/**", "node_modules/**" },
        localRoot = vim.fn.getcwd(),
        remoteRoot = "/usr/src/app"
      }
    }
  end,
}

This has the caveat that it hard-codes the remoteRoot to /usr/src/app, but I'll try and figure out how to improve that later. Right now it works as expected so I'm happy

@skivol
Copy link

skivol commented Apr 28, 2024

@citosid, did you really get it working ? Because I seem to get similar results as MijikHna mentioned in #15 (comment) 🤔 (that is, typescript breakpoint is ignored, while the one in compiled js can be hit)

Maybe the difference lies in that you run it in kubernetes and through a tunnel. (I run app using docker compose with ports mapping, which could have a different behavior 🤔)

@citosid
Copy link

citosid commented Apr 28, 2024

@skivol, I did. But I haven't used typescript in a few months. I'll try and set it up again and report back. Sorry I can't be more helpful

@skivol
Copy link

skivol commented Apr 28, 2024

No problems :)
Would be really grateful if you could check on it, but cannot ask you to do it, because playing with it takes quiet some time 😅

@serranomorante
Copy link

Maybe stopOnEntry can help?

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch node cli app",
      "type": "pwa-node",
      "request": "launch",
      "preLaunchTask": "tsc: build - tsconfig.json",
      "cwd": "${workspaceFolder}",
      "args": ["${workspaceFolder}/dist/index.js"],
      "stopOnEntry": true
    }
  ]
}

source

@skivol
Copy link

skivol commented Apr 30, 2024

Thank you for the suggestion and your notes on the topic of configuring dap for usage in neovim 👍
Will need to take a closer look on it (completely forgot that one could check logs as well :) ).
At the moment reshuffled things a bit though to check if it (using "attach" variant atm) would work for debugging an app running on the host machine (instead of container) and it seems to play well for such setup.
vscode can manage to debug containerized typescript app on the other hand... so technically it should be possible.

@skivol
Copy link

skivol commented May 5, 2024

So once again thank you for the notes, went back to the usage of dapDebugServer as you mentioned (and as also shown in https://github.com/mfussenegger/nvim-dap/wiki/Debug-Adapter-installation#javascript) and with the following configuration it works for the debugging of node typescript application running in docker container (that is, breakpoints are hit):

      dap.configurations.typescript = {
        {
          type = 'pwa-node',
          request = 'attach',
          name = 'Docker: Attach',
          localRoot = '${workspaceFolder}',
          remoteRoot = '/usr/src/app',
          cwd = '${workspaceFolder}',
        },
      }

provided that debug ports (9229) are mapped to the host machine and the app is launched with debug "on". Note though, that in my experience all localRoot, remoteRoot and cwd properties are required.

@Blackvz
Copy link

Blackvz commented May 12, 2024

I have currently the same problem but in my case i run a Nextjs application directly on my host machine.

I tried the lazyvim extra settings for nvim-dap.

{
  "mfussenegger/nvim-dap",
  optional = true,
  dependencies = {
    {
      "williamboman/mason.nvim",
      opts = function(_, opts)
        opts.ensure_installed = opts.ensure_installed or {}
        table.insert(opts.ensure_installed, "js-debug-adapter")
      end,
    },
  },
  opts = function()
    local dap = require("dap")
    if not dap.adapters["pwa-node"] then
      require("dap").adapters["pwa-node"] = {
        type = "server",
        host = "localhost",
        port = "${port}",
        executable = {
          command = "node",
          -- 💀 Make sure to update this path to point to your installation
          args = {
            require("mason-registry").get_package("js-debug-adapter"):get_install_path()
              .. "/js-debug/src/dapDebugServer.js",
            "${port}",
          },
        },
      }
    end
    for _, language in ipairs({ "typescript", "javascript", "typescriptreact", "javascriptreact" }) do
      if not dap.configurations[language] then
        dap.configurations[language] = {
          {
            type = "pwa-node",
            request = "launch",
            name = "Launch file",
            program = "${file}",
            cwd = "${workspaceFolder}",
          },
          {
            type = "pwa-node",
            request = "attach",
            name = "Attach",
            processId = require("dap.utils").pick_process,
            cwd = "${workspaceFolder}",
          },
        }
      end
    end
  end,
}

So once i start the app with NODE_OPTIONS='--inspect' next dev and start dap inside of nvim, i can see that the debugger gets attached. But it wont hit any server side breakpoint. In VScode it works fine with this launch.json code:

 {
      "name": "Next.js: debug server-side",
      "type": "node-terminal",
      "request": "launch",
      "command": "npm run dev"
 },

I even tried to start the server with vscode and connect my dap debugger in nvim to it. "Debugger attached" but it still won't hit any breakpoint.

Maybe somebody have some clue whats going on here?...

@skivol
Copy link

skivol commented May 23, 2024

Note to myself: in order to avoid "Your answer appears to be spam" verdict by SO it's better to use external linking sparingly...
As for your question, I think you could find some clues in Peculiarity here is that despite mentioning part of this SO answer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants