Vitest support

[zenoli]

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:

    {
        type = "pwa-node",
        request = "launch",
        name = "Debug Current Test File",
        autoAttachChildProcesses = true,
        skipFiles = { "<node_internals>/**", "**/node_modules/**" },
        program = "${workspaceFolder}/node_modules/vitest/vitest.mjs",
        runtimeExecutable = "node",
        rootPath = "${workspaceFolder}",
        cwd = "${workspaceFolder}",
        args = { "run", "${relativeFile}" },
        smartStep = true,
        console = "integratedTerminal",
        internalConsoleOptions = "neverOpen",
    },

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.

[anasrar]

can confirm latest build vscode-js-debug has bugs

• warning wrong source map path
• can not step over/into/out or run_to_cursor

revert build to vscode-js-debug@1.68.0 solve this problem

[zenoli]

@anasrar Thank you for your input. I recon the source map path warnings are of the form: Could not read source map for file:///home/olivier/.local/share/nvim/mason/packages/js-debug-adapter/out/src/targets/out/src/common/cancellation.js: ENOENT: no such file or directory, open '/home/olivier/.local/share/nvim/mason/packages/js-debug-adapter/out/src/targets/out/src/common/cancellation.js.map' (there are more of the same kind)

If yes, then I can confirm that reverting to 1.68 indeed gets rid of them. About the inability to step over/into/out or run_to_cursor: I only ever experienced this issue when debugging vitest tests (for jest tests, debugging chrome or plain node files everything worked fine). And even after reverting back to 1.68 I still get the same issue as mentioned in my original post: DAP ERROR No stopped threads. Cannot move

[anasrar]

@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

[zenoli]

So you experience issues as well with 1.68? Or does this fixes it for you?

[anasrar]

@zenoli got same issue but not so offten.

try this launch.json, I got pretty consistent being able to step over and also using latest build

{
  "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/**' },
    }

[zenoli]

Wow, yes this one (almost) works! I can step through the code if I set a breakpoint inside a vitest js file. The only thing that is missing is that I cannot step into functions defined outside the test file. If I try to do so it says: Source not available, cannot jump to frame.

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. If you have a solution for the new issue I just mentioned, please let me know. I would also be willing to help debug this. What appraoch did you take to find the new args parameters?

[zenoli]

Ok I made slight progress. If I disable source maps (sourceMaps = false) then I can step into function defined elsewhere, but due do not considering source maps, the indicated debug position is off (+/- a few lines above/below the actual statement where it stopped).

[anasrar]

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.

that is my current workflow, not very great tho, I can't think how to solve this issue.

Thank you for sharing your findings. If you have a solution for the new issue I just mentioned, please let me know. I would also be willing to help debug this. What appraoch did you take to find the new args parameters?

vitest recommend using --threads false flag when using on IntelliJ.

[zenoli]

that is my current workflow, not very great tho, I can't think how to solve this issue.

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.

vitest recommend using --threads false flag when using on IntelliJ.

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. There I could fix it by setting enableContentValidation = false.

[harrisoncramer]

@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.

[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.

No, setting to 1.68 was not solving the issue. What made it work (partially) was @anasrar key observation of including --threads false in the args array. However, this unfortunately only makes things partially work, as it is still not possible to step into functions that are defined in files outside the test file.

If I set sourceMaps = false this issue is also resolved, but the visual indication of the currently debugged line is off, which makes debugging almost unusable for me

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:

  {
      type = "pwa-node",
      request = "launch",
      name = "Launch Test Program (pwa-node with vitest) NEW",
      cwd = "${workspaceFolder}/src",
      program = "${workspaceFolder}/node_modules/vitest/vitest.mjs",
      args = {
          "--threads",
          "false",
      },
      autoAttachChildProcesses = false,
      trace = true,
      console = "integratedTerminal",
      sourceMaps = true,
      smartStep = true,
  },

[harrisoncramer]

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.

No, setting to 1.68 was not solving the issue. What made it work (partially) was @anasrar key observation of including --threads false in the args array. However, this unfortunately only makes things partially work, as it is still not possible to step into functions that are defined in files outside the test file.

If I set sourceMaps = false this issue is also resolved, but the visual indication of the currently debugged line is off, which makes debugging almost unusable for me

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:

  {
      type = "pwa-node",
      request = "launch",
      name = "Launch Test Program (pwa-node with vitest) NEW",
      cwd = "${workspaceFolder}/src",
      program = "${workspaceFolder}/node_modules/vitest/vitest.mjs",
      args = {
          "--threads",
          "false",
      },
      autoAttachChildProcesses = false,
      trace = true,
      console = "integratedTerminal",
      sourceMaps = true,
      smartStep = true,
  },

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.

[zenoli]

@harrisoncramer nice! But have you also fixed the other issue I mentioned (being unable to step into functions outside of test files?

[harrisoncramer]

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?

[weilbith]

Sorry if this is a little off-topic but did anyone made it work to use this with neotest-vitest?