Change:
length, messageText: !target ? 'This can only be used in ts files.' <del> : 'This can only be used with ES6. Make sure to have a jsconfig.json-file which sets the target to ES6.', </del> <ins> : 'This can only be used with ES6. Make sure to have a jsconfig.json file which sets the target to ES6.', </ins> category: ts.DiagnosticCategory.Error, code: -1 };

Discussion:
We have today the with this method: interface DebugConfigurationProvider { resolveDebugConfiguration(...) So far is flexible enough except in scenarios where we want our provider to abort the debug launch without having vscode to think that the configuration is wrong or missing something important. In the 'live share' scenario we are launching remote debug sessions by allowing vscode to display them but not necessary to launch a remote debug session that will eventually arrive later. We want the resolveDebugConfiguartion to allow this by return a blessed debug configuartion or probably best by throwing a DebugConfiguartionCancelledException() that vscode would handle nicely.
Just ran into this today. After the PowerShell extension is activated, it takes about 5-8 seconds for the PowerShell Editor Services (lang/debug server) to finish starting up. While that is happening it isn't a good time to start debugging. ATM we have a NullReferenceException that occurs in PSES because it is still initializing. We could certainly fix the NullReferenceEx in PSES but I'm afraid this might be the tip of the iceberg in this case. So I've put code in to check the status of PSES and if it isn't in the state, we pop a warning notification and return out of the function. The notification asks the user to retry after PSES has finished starting but unfortunately, VSCode has switched the active editor to . This makes this approach annoying for the user as now they can't just press again, they have to reselect the PowerShell editor window again and then press . BTW if there's a better way to prevent debugging until the extension is ready, please let me know.
I've fixed this issue by adding the following line to the comment for  and implementing the behaviour on the VS Code side: With this it is now possible to control what happens when aborting :
I like the new behavior, it works well for the workspace with file, but there may be a potential break change for the workspace without It's better to keep the debugger owners for awareness. In current VS Code 1.27.1, when the user clicks F5 in the workspace without file, VS Code will invoke api first, if it's returned value is , or , , then delegate to api to generate file. In the insider with your new change, the debugger extension must return explicitly for api, then VS Code will continue delegating to api to generate file.

For all other return values, it will try to launch or abort debug session, no is generated or opened.
thanks for raising your concern. let's discuss. We might want to flip the "null" and "undefined".
We've concluded that the fix is good and will make debug adapter authors aware of the change.
I know you are depending on this mechanism so please be aware of the change we are making in the new vscode release. This comment covers the change Basically now you should return to explicitly let vscode know to open
Great, thanks! I can remove some crufty code with this (where we return a debug config that has a ). I'll make the changes and do some testing and shout if I hit any problems.
Tested it and it works great for me, closes too. Thanks!
thanks for testing, adding verified label