Debt: Support launch.json creation through extension host code

[weinand]

Currently an extension can only contribute an initial launch.json statically, so it cannot adapt the launch.json to the contents or structure of an existing project folder.

For node.js we work around this in VS Code by specific code that understands the package.json.
With this feature we could move this code from VS Code into node-debug.

[isidorn]

August to investigate if we can introduce some vscode api such that the adapter extension could write the launch.json

[isidorn]

For this we are depending on the API for extensions to write to configuration files. Currently in discussion with @bpasero and @jrieken since optimally this would be the same API extensions use to change the user / workspace configuration.
Will probably be pushed out to september.

[weinand]

@isidorn this feature request is about the initial configuration and not about modifying the launch.json at any time. I'm not sure that this feature has to go through the extension API for write to configuration files.

[isidorn]

@weinand somehow github did not notify me about this comment, thus the slow response - sorry.
Yes, but this feature request is a subset of writing to the launch.json at any time - which feels to me like a clean and elegant solution which conforms to our VSCode api.

[DustinCampbell]

Is there any opportunity for #10861 to be included as part of this work?

[isidorn]

Thanks to @bpasero and @jrieken now it is possible to modify the launch.json through extension host code. More details about this can be found #1396
Here's a small snippet where I am adding a new launch configuration through extension host code

        const launchConfig = vscode.workspace.getConfiguration('launch');
        const configurations = launchConfig['configurations'];
        configurations.push({
            "name": "My New Launch Config",
            "type": "extensionHost",
            "request": "launch",
            "runtimeExecutable": "${execPath}",
            "args": ["/Users/isidor/development/vscode", "--extensionDevelopmentPath=${workspaceRoot}" ],
            "stopOnEntry": false,
            "sourceMaps": true,
            "outDir": "${workspaceRoot}/out/src",
            "preLaunchTask": "npm"
        });
        launchConfig.update('configurations', configurations, false).then(() => 
            vscode.window.showInformationMessage('Added new configuration to launch.json!')
        );

[isidorn]

Also note if you want to try this out in your extension right now you need the latest vscode.d.ts:

• open your extensions package.json file
• change the engine.vscode property to *
• run npm run postinstall (assuming you have the vscode module as dev-dependency)
• undo the engine-version change from step 2

[isidorn]

Here's a snippet where I am creating a full new launch.json:

        const configuration = vscode.workspace.getConfiguration();
        const launchConfig =  {
            "version": "0.1.0",
            "configurations": [
                {
                    "name": "Launch Extension",
                    "type": "extensionHost",
                    "request": "launch",
                    "runtimeExecutable": "${execPath}",
                    "args": ["/Users/isidor/development/vscode", "--extensionDevelopmentPath=${workspaceRoot}" ],
                    "stopOnEntry": false,
                    "sourceMaps": true,
                    "outDir": "${workspaceRoot}/out/src",
                    "preLaunchTask": "npm"
                }
            ]
        };
        configuration.update('launch', launchConfig, false).then(() => 
            vscode.window.showInformationMessage('Created my launch.json!')
        );

[weinand]

@isidorn part of this feature request is to eliminate the node-specific code for generating the initial launch configuration from VS Code by moving it to the node-debug extension.
Please try to do this!

[bpasero]

@isidorn @weinand @jrieken @dbaeumer one thing to keep in mind when using the new configuration write API is that there are a bunch of error cases that can all lead to the configuration not being written to the file. you will get the promise returned in error state so you can handle the error but I wonder if we should just always show a message back to the user in case this happens.

The reason being that some of the errors are actually user errors or specific to the environment the user is in:

• the settings file is dirty
• the settings file contains a JSON error (e.g. too much trailing comma)

Instead of asking each and every user of this API to handle the error by showing a message, we could show the message within the configuration editing service and still return the promise in error state so that the extension can also react. I think doing so would allow us to guide the user to do the right thing (e.g. correct a malformed settings file or save the settings file).

The downside of this approach is that it might not be easy for a user to actually repeat the exact same action that was triggering the configuration editing in the first place. Maybe you have suggestions?

[jrieken]

we could show the message within the configuration editing service and still return the promise in error state

Not a big fan of that as it won't allow extension authors to implement custom (maybe better suited) error handling