-
Notifications
You must be signed in to change notification settings - Fork 24
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
Vitest support #19
Comments
can confirm latest build vscode-js-debug has bugs
revert build to [email protected] solve this problem |
@anasrar Thank you for your input. I recon the source map path warnings are of the form: If yes, then I can confirm that reverting to 1.68 indeed gets rid of them. |
@zenoli after so many test, I don't know which side is between DAP or vitest but it's not stable and unreliable, some time you can step over, some time you can't |
So you experience issues as well with 1.68? Or does this fixes it for you? |
@zenoli got same issue but not so offten. try this {
"version": "0.2.0",
"configurations": [
{
"type": "pwa-node",
"request": "launch",
"name": "Debug Current Test File",
"autoAttachChildProcesses": true,
"skipFiles": ["<node_internals>/**", "**/node_modules/**"],
"program": "node_modules/vitest/vitest.mjs",
"args": ["--inspect-brk", "--threads", "false", "run", "${relativeFile}"],
"smartStep": true,
"console": "integratedTerminal"
}
]
} lua version {
type = 'pwa-node',
request = 'launch',
name = 'Launch Test Program (pwa-node with vitest)',
cwd = vim.fn.getcwd(),
program = '${workspaceFolder}/node_modules/vitest/vitest.mjs',
args = { '--inspect-brk', '--threads', 'false', 'run', '${file}' },
autoAttachChildProcesses = true,
smartStep = true,
console = 'integratedTerminal',
skipFiles = { '<node_internals>/**', 'node_modules/**' },
} |
Wow, yes this one (almost) works! I can step through the code if I set a breakpoint inside a vitest js file. There is a workaround though: If I set another breakpoint in the function outside of the test file which I want to inspect, and continue the debugger after it initially stopped at the breakpoint inside the vitest file, it jumps to the other file. Thank you for sharing your findings. |
Ok I made slight progress. If I disable source maps ( |
that is my current workflow, not very great tho, I can't think how to solve this issue.
vitest recommend using |
Yeah, I think I will have to stick with this for now too. It's not too bad. Kinda hoping the problem will fix itself in future updates.
Nice catch! I might be doing some more experimenting on the weekend. But it is really trial and error at this point. I'm just resisting giving up yet because I had the same issue when I set up the chrome debugger (not being able to jump to frames in different files. |
@zenoli if I'm understanding correctly, reverting to 1.68 with the above configuration lets you set breakpoints in the Vitest files? I'm encountering the error you first mentioned, but even after setting the version of the debugger to 1.68 I'm unable to set breakpoints at all. I'm using the configuration mentioned above by @anasrar but I still get the same error that you do, relating to "no stopped threads" even on v1.68. My configuration works and is capable of setting breakpoints in the minimal vite example here but isn't able to do so in my own repository. I'm able to set breakpoints with VSCode's debugger, however. I'd originally asked a question about this same issue on Reddit and wasn't able to figure out a resolution. |
No, setting to 1.68 was not solving the issue. What made it work (partially) was @anasrar key observation of including If I set Since I hoped the issues are related to sourceMaps, I tried tweaking several options of nvim-dap-js with no success. I'm using this config at the moment:
|
This ended up working for me!! In the repository that I was working in I was using this plugin, which was breaking source maps and making debugging impossible. |
@harrisoncramer nice! |
I'm using this in a VueJS codebase, but haven't had issues setting breakpoints in other files (such as the computed properties in Vue single-file components or methods in those components). My Neovim configuration is online here. Does this help? |
Sorry if this is a little off-topic but did anyone made it work to use this with |
Hi,
Thank you for this plugin!
Is debugging vite-tests supported? I tried to make it run with the following config, and the debugger attaches but from there on, things are broken:
The "DAP Scopes" buffer (I use dap-ui) holds the state of the objects at the first breakpoint, and dap-ui indicates that it stopped at the first breakpoint. However, as soon as I try to step forward, a notification appears
DAP ERROR No stopped threads. Cannot move
The configuration I used is:
The plugin works well when debugging a simple node application so I think I set it up correctly.
The configuration is based on the official instruction from vite to setup debugging in vs code so I hoped that it would work for nvim dap as well.
The text was updated successfully, but these errors were encountered: