microsoft / microsoft/vscode-js-debug

Possible race condition in source mapping / breakpoint binding within dynamic imports

Open
#1,510 17 comments 1 reaction 1 assignee View on GitHub

@connor4312 is already working on this.

Since Jan 7, 2023.

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

Description

EDIT: I have a simpler way to trigger this behaviour, see following comment

I have a breakpoint inside dynamically import()ed code that sometimes works. I can reliably make it work, or not, by enabling or disabling an entirely different breakpoint.

It does not work if the imported-file-breakpoint is the only breakpoint enabled.
It does work if I also set a breakpoint in the importing code, just before I invoke the imported code with the breakpoint in it.

Complicating matters, the imported code has been generated and contains an inline source map pointing to a project file that at that point, has not been loaded by the runtime.

The code looks something like the following:

const data = { ... }
import('generated.js')
    .then(
        (module) =>
        {
            fs.writeFile('output.html', module.default(data)); // magic breakpoint needs to go on this line
        });

If I place a breakpoint on the fs.writeFile line, then a breakpoint inside the file that was transpiled to 'generated.js' will work, breaking execution within the call to module.default(data). However it does not work if the breakpoint on fs.writeFile is removed or disabled.

I can generate and send trace logs, please let me know you want them.

If this is expected behaviour, is there a programatic way I can force node and the vscode js debugger to get in sync?

Version: 1.74.2 (Universal)
Commit: e8a3071ea4344d9d48ef8a4df2c097372b0c5161
Date: 2022-12-20T10:26:09.430Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Darwin arm64 22.2.0
Sandboxed: No

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.