Skip to content

Allow debug extensions to provide configurations to display in Select and Start Debugging #88230

@connor4312

Description

@connor4312

Goals

In some scenarios, it's possible for the debug adapters to provide a quality debugging experience without additional user configuration. For example, the new js-debug can debug npm scripts, and languages where entrypoints are easily identifiable. Go, C#, Java... may offer to debug the program without extra configuration.

In a similar way to how build tasks are provided, we'd like the ability to provide default run tasks that show up under the Select and Start Debugging quick-pick.

image

image

Proposal

Launch configurations already have an optional presentation key, with the following properties (this interface is not exposed in vscode.d.ts):

export interface IConfigPresentation {
	hidden?: boolean;
	group?: string;
	order?: number;
}

This proposes adding a new property:

export interface IConfigPresentation {
+	locations: ('debug.start' | 'debug.selectandstart' | 'debugView')[];

When set, this configures the locations in the UI where the returned configuration is displayed. If not provided, the locations returned from DebugConfigurationProvider.provideDebugConfigurations default to ['debug.start']. provideDebugConfigurations would now be called when the select and start quick-pick is opened to retrieve configurations to display.

Questions

  • Why are we proposing this over the existing initial configuration/F5 experience?

    • It's hard (impossible?) to discover if you have any configured launch configurations, you don't get the quick pick again;
    • Start debugging is contextual to the active text editor file, where the these tasks are intended to be project-level.
  • Should we surface all existing provided configurations in select and start?

    • + this would require no change to existing adapters
    • - existing returned tasks are contextual to the active editor, while select and start currently only displays project-level configurations.
    • - the names of most existing tasks are simply "Node.js" or "Go", which don't provide explaination and would confuse users in select and start.
  • Should there be a separate method to return the pick-able configurations?

    • + in this proposal, we start calling provideDebugConfigurations more frequently, which may lead to side-effects or slowdowns; a separate method avoids that.
    • + this proposal is somewhat of an overload to the existing method to potentially return a new (non-contextual) type of task.
    • - this proposal has a smaller API and the property fits in well with the presentation properties
    • - the API here allows configurations to be surfaced in multiple locations easily, including "Run and Debug" if we want to allow that.
  • Should we also be able to provide default configurations for the "Run and Debug" dropdown in the debug view? added

    • + this is most discoverable for users who don't enter through the command palette
    • + allowing this as an option in locations would let consumers in launch.json take advantage of it, rather than hidden: true/false.
    • - in cases where there are many discovered tasks (e.g. lots of npm scripts) this could get noisy
    • - would we need to call provideDefaultLaunchConfigurations every time the debug view is opened? If files change, would we call that again?

cc @isidorn @roblourens @weinand

microsoft/vscode-js-debug#197

Metadata

Metadata

Labels

api-finalizationdebugDebug viewlet, configurations, breakpoints, adapter issuesfeature-requestRequest for new features or functionalityon-testplan

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions