microsoft / microsoft/vscode-js-debug

Implement a "dry run" to automatically configure a launch.json

Open
#1,214 1 comment 7 reactions 1 assignee View on GitHub

@connor4312 is already working on this.

Since Feb 24, 2022.

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

Description

There are two main properties of the launch.json that people get tripped up on configuring, the sourceMapPathOverrides and outFiles. Both these could be figured out with a decent degree of fidelity once the program is running, so I suggest adding a "test run" mode.

  • sourceMapPathOverrides can usually involves suffix-matching against paths from the sourcemaps, which can be overlaid and compared with the workspace. For example, ng:///src/index.ts could match src/index.ts automatically. In some cases, there might be multiple prefixes, such as webpack://package-a/src/index.ts and webpack://package-b/src/index.ts. In ambiguous cases like this, we might be able to figure things out automatically if disk sources match exactly, or interactively ask the user otherwise.

    The Chrome devtools can do something like this today, although this feature is not very widely known or used as far as I know, so I'm not sure how thorough their implementation is.

  • the webRoot/cwd follows the same logic as this too, for non-sourcemapped files.

  • outFiles can be done more simply by running the program and then generating a glob or list of globs which match all scripts containing sourcemaps that are loaded by the program, excluding those in the node_modules. In the special case when a file in the runtime has a sourcemap but its version on disk doesn't, it does not need to be included (e.g. ts-node https://github.com/microsoft/vscode/issues/142830#issuecomment-1048240356)

The major question here is discoverability of this "auto configuration" mode. Perhaps it can be suggested if breakpoints don't get bound, similar to the suggester we have today (but maybe more aggressive).

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.