[win] Debugging/running on VSCode on Windows doesn't work

[COLAMAroro]

What version of Bun is running?

1.0.26-canary.51+2264bb3d0

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What steps can reproduce the bug?

Install the official Bun VSCode Extension.

Configure the recommended .vscode/launch.json file

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "bun",
      "request": "launch",
      "name": "Debug Bun",

      // The path to a JavaScript or TypeScript file to run.
      "program": "${file}",

      // The arguments to pass to the program, if any.
      "args": [],

      // The working directory of the program.
      "cwd": "${workspaceFolder}",

      // The environment variables to pass to the program.
      "env": {},

      // If the environment variables should not be inherited from the parent process.
      "strictEnv": false,

      // If the program should be run in watch mode.
      // This is equivalent to passing `--watch` to the `bun` executable.
      // You can also set this to "hot" to enable hot reloading using `--hot`.
      "watchMode": false,

      // If the debugger should stop on the first line of the program.
      "stopOnEntry": false,

      // If the debugger should be disabled. (for example, breakpoints will not be hit)
      "noDebug": false,

      // The path to the `bun` executable, defaults to your `PATH` environment variable.
      "runtime": "bun",

      // The arguments to pass to the `bun` executable, if any.
      // Unlike `args`, these are passed to the executable itself, not the program.
      "runtimeArgs": [],
    },
    {
      "type": "bun",
      "request": "attach",
      "name": "Attach to Bun",

      // The URL of the WebSocket inspector to attach to.
      // This value can be retrieved by using `bun --inspect`.
      "url": "ws://localhost:6499/",
    }
  ]
}

Create a JS or TS file, and either run "Run File" or "Debug File"

What is the expected behavior?

It should be possible to run or debug the script inside VSCode

What do you see instead?

The debugging/running immediately stops, with this error appearing in the debug console:

Failed to start inspector:
 40 |     },
41 |     close: () => {
42 |       writer.close(), pendingMessages.length = 0;
43 |     }
44 |   };
45 | }, parseUrl = function(input) {
                                                 ^
TypeError: "ws+unix://C:\Users\[REDACTED]\AppData\Local\Temp\8e3aij0xu7f.sock?wait=1" cannot be parsed as a URL.
      at internal:debugger:45:45
      at new Debugger (internal:debugger:124:27)
      at internal:debugger:100:25

Additional information

Bun extension version: v0.0.12

VSCode "about" window:

Version : 1.86.1 (system setup)
Validation : 31c37ee8f63491495ac49e43b8544550fbae4533
Date : 2024-02-07T09:08:20.941Z
Electron : 27.2.3
ElectronBuildId : 26495564
Chromium : 118.0.5993.159
Node.js : 18.17.1
V8 : 11.8.172.18-electron.0
Système d’exploitation : Windows_NT x64 10.0.22631

[Electroid]

Yea, Windows doesn't support UNIX sockets. We'll have to fix this in the VSCode extension

[COLAMAroro]

I've tried, Bun has no issues with UNIX sockets on Windows (which have supported them since around 2017).

The following code runs fine on my Windows machine

import * as net from "net"
import { userInfo } from "os";

let responded = false;

var server = net.createServer(function (socket) {
    socket.on("data", function (data) {
        let message = data.toString();
        console.log("Message received from client: " + message);
        socket.write("Hello " + message + " !");
        responded = true;
    })
})
server.listen("./test.sock");

let client = net.connect("./test.sock").
    on('data', (data) => {
        let message = data.toString();
        console.log("Message received from server: " + message);
    })

client.write(userInfo().username);

while (!responded) {
    await Bun.sleep(10);
}

client.destroy();
server.close();

Unless the websocket debugger falls into one of the unsupported type of socket, I think the root cause is elsewhere.

Also of note, Bun supports UNIX Sockets on Windows, while NodeJS doesn't even bother :D

[tonka3000]

This issue still exist with the 1.1 stable version on Windows.

[webdevrr]

Same issue here for 1.1 on Windows

[otavio-silva]

Having the same exact issue on 1.1.0, any news on this?

[YuziO2]

1.1.3 the same

[MusiCode1]

The problem is still here.

1. Maybe you should write that the extension does not work in Windows?
2. Is there any bypass in the meantime?

[haingo87]

Having the same issue. Hope this issue gets priority.

[GuiLin0773]

try half a day,and finally get here.hope to solve the bug

[Forgifted]

Bug reproduced in 1.1.9.

[fesieg]

having this issue in 1.1.9 too

[Jarred-Sumner]

Confirming this does not work. We haven't had time to address this yet.

The strange thing is we do support unix domain sockets on Windows.

So it's something most likely to do with the VSCode extension.

If a contributor wants to investigate this:

VSCode extension code

Debugger is initialized here:

https://github.com/oven-sh/bun/blob/af4e844b621e8c889d2d73c2cd12a7426516ebbf/src/bun.js/javascript.zig#L1217-L1235

The debugger thread's JS is here:

https://github.com/oven-sh/bun/blob/af4e844b621e8c889d2d73c2cd12a7426516ebbf/src/js/internal/debugger.ts#L266-L296

It's expecting an environment variable named BUN_INSPECT:

https://github.com/oven-sh/bun/blob/af4e844b621e8c889d2d73c2cd12a7426516ebbf/src/bun.js/javascript.zig#L1578-L1580

[LightQuanta]

This problem appears to be related to URL parsing on Windows. When tested on Node Cli, new URL() does not parse some URLs with Windows file paths.

For example, ws+unix://C:\\some\\folder is not considered a valid URL:

> new URL('ws+unix://C:\\test\\folder')
Uncaught TypeError: Invalid URL
    at new URL (node:internal/url:797:36) {
  code: 'ERR_INVALID_URL',
  input: 'ws+unix://C:\\test\\folder'
}

Node treats all backslashs in URLs as invalid(except for certain protocols like file:/// and ws://). This can be solved by using slashs instead of backslashes:

> new URL('ws+unix://C:/test/folder')
URL {
  href: 'ws+unix://C/test/folder',
  protocol: 'ws+unix:',
  host: 'C',
  hostname: 'C',
  pathname: '/test/folder',
  ...
}

However this introduces a new problem: the driver letter C: and the pathname are parsed incorrectly. This can be fixed by using ws+unix:/// instead of ws+unix://:

> new URL('ws+unix:///C:/test/folder')
URL {
  href: 'ws+unix:///C:/test/folder',
  protocol: 'ws+unix:',
  pathname: '/C:/test/folder',
  ...
}

There's still an extra slash before the pathname, causing packages/bun-vscode/scripts/test.mjs and packages/bun-vscode/scripts/build.mjs not working on Windows. By removing the extra slash, this can be solved too.

These are the issues I attempted to fix in the PR, but I'm uncertain if the changes in src/js/internal/debugger.ts can work correctly since I cannot build bun for windows successfully. Also I'm not sure if (require("node:os")?.type() ?? "") === "Windows_NT" is the correct way to detect the operating system. Is there a better way to do this?

[Code-Quake]

Any update on a fix for this? I am having the same problem.

[Swarz]

Hurry up, please

[itseramin]

Let's go guys!

[softestpoly]

I'm having the same problem

Failed to start inspector:
40 |       }
41 |     },
42 |     close: () => {
43 |       writer.close(), pendingMessages.length = 0;
44 |     }
45 | }, parseUrl = function(input) {
                           ^
TypeError: "ws+unix://C:\Users\Poly\AppData\Local\Temp\7h38vq7qrji.sock?wait=1" cannot be parsed as a URL.
      at internal:debugger:45:23
      at new Debugger (internal:debugger:124:14)
      at internal:debugger:100:13

[amir141592]

I still have this issue

[dayblox]

Still the case on 1.1.21-canary.1+738947bde

[zs782306174]

Brother, hasn't this problem been solved yet? If it's resolved, you should update the new version immediately

[elemental-mind]

Reposting here from the other issue:

You can attach with the following config in launch.json:

        {
            "name": "Attach to bun",
            "type": "bun",
            "request": "attach",
            "url": "ws://127.0.0.1:5000/test",
            "internalConsoleOptions": "openOnSessionStart"
        }

...and then running bun --inspect-brk=127.0.0.1:5000/test test.ts and then launching the debugger.

But once attached there is no output in the debugger console and breakpoints do not get hit. Stepping through the code with F10 evaluates the code line by line, though, but without giving any visual feedback or variables in the debug panel of VSCode.

So there are a lot more issues to be fixed beyond the initial connection problem.

But maybe it works for someone else?

[nick4814]

Hopefully this gets sorted out soon. I closed a duplicate issue of this today. I did not see this issue when I created the duplicate. Closed duplicate issue #12735.

Node is getting typescript first class as well. Surely Bun supports this before Node JS officially does. Node JS adds experimental TS support

[nick4814]

I've tried, Bun has no issues with UNIX sockets on Windows (which have supported them since around 2017).

The following code runs fine on my Windows machine

import * as net from "net"
import { userInfo } from "os";

let responded = false;

var server = net.createServer(function (socket) {
    socket.on("data", function (data) {
        let message = data.toString();
        console.log("Message received from client: " + message);
        socket.write("Hello " + message + " !");
        responded = true;
    })
})
server.listen("./test.sock");

let client = net.connect("./test.sock").
    on('data', (data) => {
        let message = data.toString();
        console.log("Message received from server: " + message);
    })

client.write(userInfo().username);

while (!responded) {
    await Bun.sleep(10);
}

client.destroy();
server.close();

Unless the websocket debugger falls into one of the unsupported type of socket, I think the root cause is elsewhere.

Also of note, Bun supports UNIX Sockets on Windows, while NodeJS doesn't even bother :D

I assume you are using WSL? Debugging any TS doesn't work for me. Can you provide information on your setup/OS/etc?

[COLAMAroro]

I assume you are using WSL? Debugging any TS doesn't work for me. Can you provide information on your setup/OS/etc?

No I confirm, it was running natively on Windows, not via WSL. Setup is still in the OP 🙂

[tonka3000]

@Jarred-Sumner I replaced the \\ with / (in adapter.ts, debug.ts and signal.ts) and URL parse error is gone e.g. instead of ws+unix://C:\\Users\\myusername it is now ws+unix://C:/Users/myusername.

The only problem which I'm not stuck is no permission error. It seems that the sock files get created, but no write/read permissions.

rejected promise not handled within 1 second: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
extensionHostProcess.js:148
stack trace: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
    at Server.setupListenHandle [as _listen2] (node:net:1855:21)
    at listenInCluster (node:net:1920:12)
    at Server.listen (node:net:2019:5)
    at new UnixSignal (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\signal.ts:41:18)
    at DebugAdapter.#launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:493:20)
    at DebugAdapter.launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:439:18)
    at DebugAdapter.Adapter.request (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:350:21)
    at DebugAdapter.emit (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:297:26)
    at FileDebugSession.handleMessage (c:\sandbox\bun\packages\bun-vscode\src\features\debug.ts:195:20)

Note to the stack trace: I hardcoded the prefix C:/Users/myusername/b to make sure that I have write/read permission on disk.

Any idea?

EDIT: Now I saw the #11378 seems to already try to fix it. It seems that unix socket do not really work on Windows (no WSL).

[nick4814]

I assume you are using WSL? Debugging any TS doesn't work for me. Can you provide information on your setup/OS/etc?

No I confirm, it was running natively on Windows, not via WSL. Setup is still in the OP 🙂

I assumed you were talking about debugging, as that's the issue that is actually still present 🙂. TS files run fine on windows already, see this fixed issue

[nick4814]

@Jarred-Sumner I replaced the \\ with / (in adapter.ts, debug.ts and signal.ts) and URL parse error is gone e.g. instead of ws+unix://C:\\Users\\myusername it is now ws+unix://C:/Users/myusername.

The only problem which I'm not stuck is no permission error. It seems that the sock files get created, but no write/read permissions.

rejected promise not handled within 1 second: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
extensionHostProcess.js:148
stack trace: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
    at Server.setupListenHandle [as _listen2] (node:net:1855:21)
    at listenInCluster (node:net:1920:12)
    at Server.listen (node:net:2019:5)
    at new UnixSignal (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\signal.ts:41:18)
    at DebugAdapter.#launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:493:20)
    at DebugAdapter.launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:439:18)
    at DebugAdapter.Adapter.request (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:350:21)
    at DebugAdapter.emit (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:297:26)
    at FileDebugSession.handleMessage (c:\sandbox\bun\packages\bun-vscode\src\features\debug.ts:195:20)

Note to the stack trace: I hardcoded the prefix C:/Users/myusername/b to make sure that I have write/read permission on disk.

Any idea?

EDIT: Now I saw the #11378 seems to already try to fix it. It seems that unix socket do not really work on Windows (no WSL).

Why not use standard ws:// for windows instead of ws+unix://?

Then update signal.ts to match this change? And possibly rename UnixSignal to SocketSignal or other to indicate it supports other systems, not just Unix.

I am not familiar with all the project code so this is may not be possible, but thought to mention. I mentioned this on the broken PR.

I also mentioned something similar when I accidentally duplicated this issue.

Update

Looks like this implementation is currently being tried thanks to @mikeseese

[maxime-aubry]

I Have the same issue. Unable to start debugger with Bun and NestJS.

[mikeseese]

Yall can 👍 the original post of this issue to show your desire to get this fixed/add that you are experiencing the issue. Not to be that guy, but if you're trying to use Bun on Windows without WSL given any combination of JS frameworks/etc, the VSCode extension debugger will not work for you (and won't work until this issue gets closed or otherwise mentioned). Let's keep people's inboxes reserved for productive discussion on the issue. Thanks!

[LightQuanta]

@Jarred-Sumner I replaced the \\ with / (in adapter.ts, debug.ts and signal.ts) and URL parse error is gone e.g. instead of ws+unix://C:\\Users\\myusername it is now ws+unix://C:/Users/myusername.

The only problem which I'm not stuck is no permission error. It seems that the sock files get created, but no write/read permissions.

rejected promise not handled within 1 second: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
extensionHostProcess.js:148
stack trace: Error: listen EACCES: permission denied C:/Users/myusername/b/mysock_dyswppiw3gt.sock
    at Server.setupListenHandle [as _listen2] (node:net:1855:21)
    at listenInCluster (node:net:1920:12)
    at Server.listen (node:net:2019:5)
    at new UnixSignal (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\signal.ts:41:18)
    at DebugAdapter.#launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:493:20)
    at DebugAdapter.launch (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:439:18)
    at DebugAdapter.Adapter.request (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:350:21)
    at DebugAdapter.emit (c:\sandbox\bun\packages\bun-debug-adapter-protocol\src\debugger\adapter.ts:297:26)
    at FileDebugSession.handleMessage (c:\sandbox\bun\packages\bun-vscode\src\features\debug.ts:195:20)

Note to the stack trace: I hardcoded the prefix C:/Users/myusername/b to make sure that I have write/read permission on disk.

Any idea?

EDIT: Now I saw the #11378 seems to already try to fix it. It seems that unix socket do not really work on Windows (no WSL).

I've tried ws://127.0.0.1:22222, and it still says EACCES: permission denied

stack trace: Error: listen EACCES: permission denied 127.0.0.1:22222
	at Server.setupListenHandle [as _listen2] (node:net:1855:21)
	at listenInCluster (node:net:1920:12)
	at Server.listen (node:net:2019:5)
	at new UnixSignal (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:7328:18)
	at #launch (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:7700:20)
	at DebugAdapter.launch (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:7652:25)
	at Adapter.request (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:7579:22)
	at DebugAdapter.emit (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:7534:27)
	at FileDebugSession.handleMessage (f:\bunvscextfix\bun\packages\bun-vscode\dist\extension.js:9458:20)
	at D.sendMessage (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:163:706)
	at o.$sendDAMessage (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:162:12042)
	at S (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:151:5986)
	at S.Q (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:151:5752)
	at S.M (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:151:4778)
	at S.L (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:151:3605)
	at n.value (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:151:2297)
	at r.B (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:83:737)
	at r.fire (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:83:954)
	at o.fire (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:108:14502)
	at n.value (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:177:8639)
	at r.B (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:83:737)
	at r.fire (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:83:954)
	at o.fire (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:108:14502)
	at MessagePortMain.<anonymous> (d:\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:177:6765)
	at MessagePortMain.emit (node:events:514:28)
	at MessagePortMain.emit (node:domain:488:12)
	at MessagePortMain._internalPort.emit (node:electron/js2c/utility_init:2:2285)
	at Object.topLevelDomainCallback (node:domain:160:15)
	at Object.callbackTrampoline (node:internal/async_hooks:128:24)