Change:
in visual studio (not vscode) you can start debugging and stop at the first line of code by pressing the or keys. this is distinct from hitting the key which doesn't stop at (or wherever). it's incredibly useful to easily choose whether or not to stop at the first line of code, especially for console apps. can we get similar functionality to vscode? it's a pain to have to switch debug configurations, or edit the setting just to do this.
I support the request: enable starting a debugging session with F10, that positions the "instruction cursor" at the first instruction of the script
do I get this right? you removed this from the backlog?
I like this idea and we plan to add this soon thus I am assigning this to On-Deck fyi
"stopAtEntry" is a private attribute of some debug extensions. It will be difficult to support that generically (if we want to avoid ugly heuristics). Alternatively we'll have to find a way (based on extension API) so that debug extensions that support "stopAtEntry" can register actions in their extension.
good point, I forgot that "stopAtEntry" is not generic. Well I think this can already be done, here's how: A debug extension registers a new command and has a keybinding for it when not in debug mode The command simply calls start debugging and patches the stopAtEntry in the resolveConfiguration call Am I missing something?
Sounds good. A prototype would be a good proof of concept.
I have introduce a new context key in vscode which has the vlaue of the selected configuration type. Only when that type is node the node extension now contributes Start Debugging and Stop on Entry commands which can be run via F10 and F11. fyi
I'm a little worried about this global variable in the config provider: You could have debugging fail to start on vscode's end for some reason so the next call to is not actually associated with that , or a race between multiple session starts, or something else that could cause confusing issues... Is there any way to get rid of that? Like if we could pass some override config props to executeCommand? Or props that get passed through to resolveDebugConfiguration?
anything that passes through vscode does not really make sense since vscode is unaware of attribute. Though I agree with your concerns, but the worst case is that something will stopOnEntry when it should not in a weird corner case. I personally do not see this as a big issue.
I accidentally stumbled over the that mentioned above and I have to agree: we need to fix this in a better way. First: the hack only works for node-debug (and probably not even for js-debug). And second: this hack might result in the strange behavior that Rob identified.
Also assigning to since stopAtEntry is contributed by the node debug
I think the nicest way to approach this would be to allow to take an object to be shallow-merged with the currently selected debug configuration. Currently there are no arguments given to the command. The downside is that it is a 'blind merge' right now that would only be useful in limited circumstances (such as this) since there's no API on the extension host to get the currently selected configuration. However since commands are not as formalized as the extension host API, maybe this is okay.
It looks like the current Action implementation doesn't support taking arguments, to fix this we should convert off the deprecated to , which takes an . I don't want to do this a couple hours before the end of the iteration, so pushing it to next milestone.
These are just not working for me. I have the latest JS Debug nightly extension. F10 doesn't appear to do anything. F11 toggles full screen. My keyboard shortcuts look correct: ! Is there something I'm missing?
Make sure you have a configuration currently selected in the "run and debug" menu
I realized I forgot to bump the builtin version of the old node-debug when I changed the setting, which is why you see a duplicate keybinding there. For me it still works, but that might cause issues
Ah forgot to include by debug config: That config is selected in the debug viewlet.
Hm, okay. This works for me on both OSX and Windows. If this doesn't work in tomorrow's Insiders for you, please let me know and we can debug together when you have time
Steps: a launch config, and select it in the debug view F10 program should run and pause on the first line of the script
Tyler tried to verify and hit the same issue. The in the debug service was missing its method. It looks like can actually be called with which 'resets' the selected config, even when there's still a selected configuration shown in the dropdown. This easiest way to trigger this is to make a change to your , then the command will break. I think my previous fix was not really correct -- newer, better, one coming.
Works great!

Discussion:
let type = config?.type; if (name && names.indexOf(name) >= 0) { this.setSelectedLaunchName(name); <del> if (!config && name && launch) { config = launch.getConfiguration(name); type = config?.type; } </del> } else if (dynamicConfig && dynamicConfig.type) { // We could not find the previously used name and config is not passed. We should get all dynamic configurations from providers // And potentially auto select the previously used dynamic configuration #96293

this.setSelectedLaunchName(nameToSet); } <ins> if (!config && launch && this.selectedName) { config = launch.getConfiguration(this.selectedName); type = config?.type; } </ins> this.selectedType = dynamicConfig?.type || config?.type; this.storageService.store(DEBUG_SELECTED_TYPE, this.selectedType, StorageScope.WORKSPACE, StorageTarget.MACHINE); if (type) {