Neotest integration (neotest-jest)

[mxsdev]

Will require a PR on neotest-jest. Posted here for issue tracking purposes.

[entropitor]

When I use https://github.com/haydenmeade/neotest-jest/compare/main...entropitor:neotest-jest:support-debugging?expand=1 I can get it to run but it doesn't seem to recognize breakpoints AFAICT. Is it possible some of your hackery around break-points is not working properly while using jest this way?

[mxsdev]

@entropitor

Hmm, I was able to get jest working with breakpoints, but I was using this configuration. Maybe it's important to keep runtime executable as node?

I'm taking a look at your fork right now, will let you know what I find!

[mxsdev]

output.webm

Hmm, very strange - your fork seems to work fine on my system? I am running on OSX, and I have a test running on ubuntu that passes which tests for breakpoints.

Can I get more details on your system? Also, do the tests pass for you?

[entropitor]

I see there was an end missing in my branch linked above. Fixed now.

The lua tests of this repo pass when I run it. And when I run a node program, I'm able to get it stopped properly on breakpoints. But not when using the neotest thing following my branch. It just "hangs" and weirdly enough, I can tell it to continue (through DAP) and that works but it never tells me it stopped on a breakpoint and I cannot see scopes / expressions / ... (Maybe somehow I'm not getting the right "subsession" and it's showing my different session?)

I didn't test it using the node version though (the different launch config), did you use that or did you use more or less my branch?

I'm on OSX as well. Maybe there is some weird stuff going on with typescript / monorepo? Or maybe because of a different jest version? Or different configuration? I didn't pass anything to neotest-jest and I just configure your plugin as

require("dap-vscode-js").setup({
  adapters = {
    "pwa-node",
    "pwa-chrome",
    "pwa-msedge",
    "node-terminal",
    "pwa-extensionHost",
  }, -- which adapters to register in nvim-dap
})

[entropitor]

It seems to know the breakpoints and I receive an event_stopped in which case nvim-dap asks for the threads and stackTrace, it receives a response for the threads but non for the stackTrace (even though there are 2 requests for it). So it never gets in this callback: https://github.com/mfussenegger/nvim-dap/blob/master/lua/dap/session.lua#L565-L582. Not sure why... And so that's why I never get like it actually stopped

Did you configure your adapter differently? Are you using latest version of nvim-dap?

(the node vs jest starting doesn't seem to matter because starting through jest ends up running node through the shebang of jest)

[mxsdev]

@entropitor

I took a closer look at this and was able to reproduce a very similar bug. The fix was to include the cwd option in the dap configuration. So, for instance, cwd = "${workspaceFolder}". Please try that and let me know if it works.

If that does not work, if you could send me your full request/response log that would be very helpful.

I also have created a fix-neotest branch, which contains a test ./scripts/test -l ./tests/integration/jest_spec.lua. That will test to see if the DapStopped breakpoint gets set in a jest test (using the dap config from your neotest-jest fork), and will also create a logfile at ./lib/dap-vscode-js.log which tracks all session requests/responses. That information could be useful to determine if this is a jest configuration-specific issue. (Note that when running that test, there will be a Invalid channel id error in stdout, this is expected). Please let me know if this test passes for you.

You can also pass a log_file_level = vim.log.levels.TRACE to the dap-js setup (again on the fix-neotest fork), which creates a logfile at (stdpath cache)/dap_vscode_js.log. This log information would be extremely helpful, since it not only prints all dap messages, but it also outputs which child sessions each message is coming from and which of those sessions are the main sessions, as well as internal info from dap-vscode-js. If you could run that on your current neotest setup and send the logs, there's a good chance I can figure out why the stackTrace callback isn't firing.

[mxsdev]

@entropitor

Oh, and to respond to your question:

Did you configure your adapter differently? Are you using latest version of nvim-dap?

Yes to the second question, and technically I used the same config from your fork (I fixed that end issue manually). However, I have discovered that whether you use absolute or relative paths can affect the behavior of the debugger in pathological ways. So that could be a potential difference between out configurations.

It was precisely this difference in configuration which I was able to rectify by passing a cwd option, by the way. I think this might be causing your issue, however without the full json logs I really couldn't say for sure.

[entropitor]

The cwd doesn't seem to fix it unfortunately.

./scripts/test -l ./tests/integration/jest_spec.lua doesn't work but ./scripts/test does pass (including that subtest)

~/.local/share/nvim/site/pack/packer/start/nvim-dap-vscode-js fix-neotest 25s
❯ ./scripts/test -l ./tests/integration/jest_spec.lua

========================================
Testing:        ./tests/integration/jest_spec.lua
Fail    ||      pwa-node jest typescript receives stdout from terminal
            ./lib/plenary.nvim/lua/plenary/async/util.lua:48: bad argument #1 to 'block_on' (table expected, got nil)

            stack traceback:
                ./lib/plenary.nvim/lua/plenary/async/util.lua:48: in function <./lib/plenary.nvim/lua/plenary/async/util.lua:47>

Fail    ||      pwa-node jest typescript with neotest config can acknowledge and continue from breakpoints
            ./lib/plenary.nvim/lua/plenary/async/util.lua:48: bad argument #1 to 'block_on' (table expected, got nil)

            stack traceback:
                ./lib/plenary.nvim/lua/plenary/async/util.lua:48: in function <./lib/plenary.nvim/lua/plenary/async/util.lua:47>


Success:        0
Failed :        2
Errors :        0
========================================
Tests Failed. Exit: 1
Tests failed

When I run it with my own project, I get these logs:
dap_vscode_js.log
dap.log

Notice how the stackTrace doesn't get any response (not even present in dap_vscode_js.log), no matter how long I wait. It seems to send it on the same session/channel as the threads request though (guessing from the sequence numbers)

[entropitor]

I think my branch on neotest-jest should be okay. It seems like it just doesn't work well together with an old version of jest or something. It seems to work well in the integration.spec.ts directory on this repo.

[entropitor]

I've created nvim-neotest/neotest-jest#26 to add this support into neotest-jest

[entropitor]

I guess this ticket can be closed. Not sure if my issues above are really due to this adapter but maybe more a bug in jest or something. Sometimes it works...

[mxsdev]

I've created haydenmeade/neotest-jest#26 to add this support into neotest-jest

Thank you so much for this! Sorry for my sudden inactivity, I got a bit sidetracked with some other matters :)

I've made a separate PR for this issue, see #4. If you could report your jest version that would be very helpful. I did take a look into your log and did not find anything obvious (I was hoping it might be an issue with child processes, but it doesn't seem so, at least not obviously). I haven't done a very thorough investigation into your logfile though.

Really, until I have a reproduction (e.g. a minimal setup with package.json + package-lock.json) I can only speculate. If you can provide that then I'll certainly look further into it! If not, hopefully others will encounter this issue and give some more perspective.