server side nodejs vite debugging problem (vite frozen)

[jymen]

Debug adapter definition and debug configuration

 ---
      ---  nodejs  config
      ---
      dap.adapters["pwa-node"] = {
        type = "server",
        host = "127.0.0.",
        port = "${port}",
        executable = {
          command = "js-debug-adapter",
          args = {
            "${port}",
          },
        },
      }
      dap.configurations["typescript"] = {
        {
          type = "pwa-node",
          request = "launch",
          name = "Node file launch",
          program = "${file}",
          cwd = "${workspaceFolder}",
        },
        {
          type = "pwa-node",
          request = "attach",
          name = "Attach to Node app",
          address = "localhost",
          port = 9229,
          cwd = "${workspaceFolder}",
          restart = true,
        },
      }
    end,

launch.json

	"version": "0.2.0",
	"configurations": [
		{
			"name": "Launch server",
			"request": "launch",
			"runtimeArgs": ["vite", "dev", "--port=4000"],
			"runtimeExecutable": "npx",
			"skipFiles": ["<node_internals>/**"],
			"type": "pwa-node",
			"console": "integratedTerminal"
		}
	]

Debug adapter version

No response

Steps to Reproduce

I am presently migrating my sveltekit app dev from vscode to neovim
I succesfully configured dap for python and go but I found following problem when configuring for node :

Since I am using sveltekit , I use Vite with vscode to setup the node server side debug process without any
problem with vscode using a launch.json configuration

The debug session using vscode goes well ...

I used exactly the same launch.json in neovim
with vscode standard jsdebugadapter installed

when starting the debug session I see a 'debugger attached' expected message and the standard vite startup messages on the console ... as expected
the pause,restart, terminate debugging icons are in place and works normally

but : no stack and no variables displayed (which may be normal since no breakpoints were hitted then)

doing on term to check Vite port status : sudo lsof -i -P | grep LISTEN | grep :4000

returns : node 86294 jymen 39u IPv6 0x6335a95253e6aa71 0t0 TCP localhost:4000 (LISTEN)

which is OK

but : curl --head http://localhost:4000
just freeze and never returns until the debug session is closed

The problem can be reproduce using standard html (no need to install SvelteKit ) as follow

create a directory and switch to it
npm install -D vite
launch vim and create index.html containing :

hello

create a .vscode subdirectory and launch.json with content previously described :

start the debugger and select Launch Server
You should then not beeing able to reach http port using curl

Expected Result

Vite should respond to sollicitors upon http connection

Actual Result

Vite looks frozen under debugger control

[mfussenegger]

If I follow the reproduction steps I do get a response:

↪  curl http://localhost:4000
<script type="module" src="/@vite/client"></script>
hello

One odd thing is that the debug adapter sends output events with ansi color codes in addition to displaying the same information in the integrated terminal so there's garbage like �[32m�[1mVITE�[22m v6.0.3�[39m �[2mready in �[0m�[1m122�[22m�[2m�[0m ms�[22m in the repl. But that relates to #1291 (and imho the debug adapter shouldn't do that if the same info is displayed in the integrated terminal anyway)

Another odd thing is that the debug adapter reports completion support (supportsCompletionsRequest = true) but if typing anything in the repl it can't handle the request:

dap> he
[debug-adapter stderr] Unknown request: completions

That also appears to be an issue with the debug adapter.

[jymen]

The problem looks more complicated that I thought initialy :
the curl --head always returns 404
the curl without --head looks frozen ... but finally is not :
the debugger takes control after around 5 minutes and pops a 'file too big' error inside a picomatch fonction
...
Since I am using a lazyvim config I'll try with a simplified neovim context to see if the problème still happens

[mfussenegger]

Any other input here or reproduction? So far I haven't seen anything that would indicate that there is a client issue here.

[jymen]

Nothing really new here on my side , so I close it since it way be relative to my environment and I am not able to provide a simplified reproduction context