Break points do not work #14
Comments
|
Okay thats strange, i am able to debug an entrypoint to app, but i cant debug api controllers 🤔 |
|
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
Are these both done with 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. |
|
@mxsdev I have the same error. Here is a screenshot of my configuration and how it behaves:
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 git@github.com:/AstroNvim/AstroNvim ~/.config/Test
git clone https://github.com/AstroNvim/user_example ~/.config/Test/lua/user
NVIM_APPNAME=Test nvimAnd then modify the file 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. |
|
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! |
|
For all those interested, basically the issues I had were two:
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 |
|
@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 🤔) |
|
@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 |
|
No problems :) |
|
Maybe {
"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
}
]
} |
|
Thank you for the suggestion and your notes on the topic of configuring dap for usage in neovim 👍 |
|
So once again thank you for the notes, went back to the usage of 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 |
|
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 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?... |
|
Note to myself: in order to avoid "Your answer appears to be spam" verdict by SO it's better to use external linking sparingly... |
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
Config
JFYI works with the same config in vscode
The text was updated successfully, but these errors were encountered: