adrigzr / neotest-mocha

Neotest runner for Mocha test framework
10 stars 9 forks source link

Debug adapter complains about missing path #18

Closed Jack-Barry closed 3 months ago

Jack-Barry commented 3 months ago

Am I missing something or should I be able to set debugger breakpoints with nvim-dap and hit them when running tests with neotest-mocha? I am unable to debug Mocha tests, I get the following error:

[debug-adapter stderr] TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined
    at new NodeError (node:internal/errors:405:5)
    at validateString (node:internal/validators:162:11)
    at Object.join (node:path:1171:7)
    at /Users/jbarry/.local/share/nvim/mason/packages/js-debug-adapter/js-debug/src/dapDebugServer.js:61:876
    at Vy (/Users/jbarry/.local/share/nvim/mason/packages/js-debug-adapter/js-debug/src/dapDebugServer.js:61:762)
    at vf (/Users/jbarry/.local/share/nvim/mason/packages/js-debug-adapter/js-debug/src/dapDebugServer.js:61:844)
    at /Users/jbarry/.local/share/nvim/mason/packages/js-debug-adapter/js-debug/src/dapDebugServer.js:110:22838
    at Hu.t [as getPath] (/Users/jbarry/.local/share/nvim/mason/packages/js-debug-adapter/js-debug/src/dapDebugServer.js:39:5103)
    at gu.resolveAndValidateInner (/Users/jbarry/.local/share/nvim/mason/packages/js-debug-adapter/js-debug/src/dapDebugServer.js:110:25699)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  code: 'ERR_INVALID_ARG_TYPE'
}

I see that the dap strategy is supported by neotest-mocha, so it's very likely I'm just missing something in my config... do I need to override that strategy somehow since I'm using node instead of pwa-node for the configuration type maybe?

MisanthropicBit commented 3 months ago

Thanks for submitting an issue and providing detailed information 🙂

Everything looks fine to me although I've only used mocha for debugging an entire application and not individual tests but I don't see any reason for it not working off the top of my head.

Some things to consider:

I'm able to debug fine in Jest and Vitest tests

Unrelated but I've always had issues with sourcemaps being mapped incorrectly from js to ts which means I can debug but the line is sometimes incorrect. Seems like you somehow solved this. Perhaps node --inspect + ts-node gives better results.

Jack-Barry commented 3 months ago

I'm not sure how to examine the path the debug adapter complains about being missing, I haven't worked on Neovim plugins before so not sure where to start. Happy to learn, and open a PR for this, just need some pointers.

My hunch is that because the nvim-vitest adapter works OK, that this boils down to the differences in strategy getters:

local function get_strategy_config(strategy, command, cwd)
  local config = {
    dap = function()
      return {
        name = "Debug Vitest Tests",
        type = "pwa-node",
        request = "launch",
        args = { unpack(command, 2) },
        runtimeExecutable = command[1],
        console = "integratedTerminal",
        internalConsoleOptions = "neverOpen",
        cwd = cwd or "${workspaceFolder}",
      }
    end,
  }
  if config[strategy] then
    return config[strategy]()
  end

vs.

function M.get_strategy_config(strategy, command)
  local config = {
    dap = function()
      return {
        name = "Debug Mocha Tests",
        type = "pwa-node",
        request = "launch",
        args = { unpack(command, 2) },
        runtimeExecutable = command[1],
        console = "integratedTerminal",
        internalConsoleOptions = "neverOpen",
      }
    end,
  }

  if config[strategy] then
    return config[strategy]()
  end

  return nil
end

The only difference I see is setting a cwd value. Would make sense that if that's missing, Node complains about an undefined "path" argument, since it's likely doing path.join(cwd, other, args). I'm not 100% sure, but I think it's coming from this line: https://github.com/microsoft/vscode-js-debug/blob/14b430024ccadd5e573228214a39fac7781bd759/src/targets/node/processLauncher.ts#L35

I'd like to try and test it... just need to know how. Is there a quick and dirty way to get this plugin cloned on my machine, then load it up using lazy.nvim to test this stuff out? Happy to RTFD and contribute, just not sure where to look/start

MisanthropicBit commented 3 months ago

I'm not sure how to examine the path the debug adapter complains about being missing, I haven't worked on Neovim plugins before so not sure where to start.

That's totally fair. What I meant was if you had tried to look at the debug adapter code, specifically this line: at /Users/jbarry/.local/share/nvim/mason/packages/js-debug-adapter/js-debug/src/dapDebugServer.js:61:876 to see what the path indicates by simply opening the path in neovim. Looking at the ts file, I can only see one join.

I agree with your hunch. Unless the debug adapter defaults to some sensible cwd, not providing it could be problematic.

I'd like to try and test it... just need to know how. Is there a quick and dirty way to get this plugin cloned on my machine, then load it up using lazy.nvim to test this stuff out? Happy to RTFD and contribute, just not sure where to look/start

I would replace the strategy config here with the one from neotest-vitest or your custom one and see if that works, or just add the cwd argument. When you ask neotest to debug a test using strategy = "dap", this is the config it will use so you probably don't need to do anything else to test it out. For what it's worth, neotest-jest also passes a cwd argument.

As for patching the code, you would need to find the install location for plugins that lazy.nvim is using, i.e. where it cloned the repo, and just open the file and modify it directly. It defaults to vim.fn.stdpath("data") .. "/lazy" as per the docs. That should be enough to test it out locally. You could print the config using vim.print(vim.inspect(...)) to verify that the modification was done correctly.

I hope that makes sense, otherwise, feel free to ask.

Jack-Barry commented 3 months ago

@MisanthropicBit thanks for the pointers, I was able to give it a run through.

Indeed, adding cwd allowed me to be able to set/hit breakpoints in Mocha tests.

To your previous point - I do get warnings about sourcemaps being unavailable when running tests with the debugger, but at least I can still inspect values to more easily debug tests.

MisanthropicBit commented 3 months ago

Glad you got it to work!

To your previous point - I do get warnings about sourcemaps being unavailable when running tests with the debugger, but at least I can still inspect values to more easily debug tests.

I was hoping this would be resolved, but alas 😭