microsoft / microsoft/vscode-js-debug

Incorrect Breakpoint Mapping When Attaching After Vite Dev Server Starts

Open
#2,301 2 comments 0 reactions 1 assignee View on GitHub

@connor4312 is already working on this.

Since Dec 9, 2025.

bug info-needed
Dominant language
TypeScript
Stars
2k
Forks
373
Avg merge
1d 9m
Merged PRs (30d)
6

Description

Describe the bug
When using VS Code's JavaScript Debugger to attach to a Vite dev server, the breakpoint source maps behave inconsistently depending on the startup sequence.

✅ Works as expected (Case A)

  1. Start the debugger first, connecting.
  2. Then start the Vite dev server (pnpm dev / npm run dev / vite), debugger connected.
  3. Breakpoints map correctly to the expected source locations.
Image

❌ Incorrect mapping (Case B)

  1. Start the Vite dev server first.
  2. Then start the debugger to attach to Chrome.
  3. Breakpoint locations become incorrectly set to the compiled file— VS Code jumps to the wrong lines/files.
  4. To make breakpoints map correctly again, I must manually run:location.reload()
Image

Launch.json

    {
      "name": "Attach Render",
      "type": "chrome",
      "request": "attach",
      "port": 9222,
      "timeout": 60000,
      "urlFilter": "http://localhost/*",
      "webRoot": "${workspaceFolder}/sdk/renderer",
      "resolveSourceMapLocations": ["!**/node_modules/**"],
      "skipFiles": ["**/node_modules/**"],
    }

VS Code Version:

Image

Additional context
I’m currently not able to provide the repository where the issue occurs, but I may try to create a minimal reproducible example when I have time.
The project affected by this bug is an Electron application whose renderer process is a multi-page Vite application.
Interestingly, I do not encounter this issue in another Electron project where the renderer is a single-page Vite application, so I’m not yet sure whether the bug is related to the multi-page setup, the Electron integration, or something else.
Sorry that I can’t share a more concrete reproduction at the moment.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.