launch-config should allow me reference any command

[jrieken]

I wanna write an extension that is a set of commands for asking for user input, like input text, make selection etc. Then I want to use commands from that extension in our launch.config - my ultimate goal is support mocha -g "test name" from within VS Code.

I have modified our launch.json so

        "args": [
                "--timeout",
                "999999",
                "-g",
                "${command.inputs.text}"
            ]

and an extension that contributes a inputs.text command and that activates on that command

// extension.js
vscode.commands.registerCommand('inputs.text', function () { ... });

// package.json
 "activationEvents": [
     "onCommand:inputs.text"
 ]

This doesn't work and it requires me to also define a debugger which I believe is unnecessary complicated.

[isidorn]

I agree that this step of defining variables inside debuggers feels like an extra step and we could just allow to run an arbitrary command. Doing this debug adapters would not have to specify interactive variables and other extensions could use this feature more easily - Joh's use case.

@weinand let us know what you think. I might be missing something here

[weinand]

@isidorn yes, making commands directly available as variables makes sense and we should support this (and we should continue to support the 'variables' contribution).

What I don't like is the resulting syntax. If the command ID follows the common practice to use '.' as separators then using the 'command.' prefix makes things a bit unwieldy:

  "program": "${command.extension.node-debug.pickProcess}"

For this the 'variables' contribution helped because it allowed to introduce a short (but scoped) alias:

  "program": "${command.pickProcess}"

TL;DR:

The reasoning behind the intermediate 'variables' contribution point was twofold:

• we wanted to decouple a dynamic variable (e.g. 'PickProcess') from its implementation (today a command is defined in an extension; in the future maybe it will become a builtin process picker).
• we wanted to introduce a scope for a dynamic variable: the variable is only available in launch configurations of the debug type for which the variable is defined.

Today the first reason is no longer valid: since dynamic variables use the ${command.variable} syntax, the implementation detail 'command based' is already apparent when using a variable. So replacing a command based implementation by something builtin, would require a major stretch...

[daviwil]

Related question: is it currently supported to use the command variable syntax in the 'args' or 'env' parameters of a launch configuration (at the top-level, not in the configurationAttributes)? I tried it yesterday and it didn't seem to work, the debug adapter got the argument but it was the command syntax string and not the resolved value.

This would be a huge benefit in my case as the alternative is to write a bunch of extra code in my TypeScript-based debug adapter bridge just to read the request that contains the properties defined in my launch config (since the command syntax seems to work there).

[weinand]

@daviwil variable substitution should work everywhere. If it doesn't it is a bug.

/cc @isidorn

[daviwil]

That's great news. Here's what I've done so you can verify whether I've made a mistake somewhere or if it's a bug:

Registering and using the command variable in package.json:

        "debuggers": [
            {
                "type": "PowerShell",
                "enableBreakpointsFor": {
                    "languageIds": [
                        "powershell"
                    ]
                },
                "variables": {
                    "GetSessionPath": "PowerShell.GetSessionPath"
                },
                "program": "./out/debugAdapter.js",
                "args": [
                    "${command.GetSessionPath}"
                ],
                "runtime": "node",
                "configurationAttributes": {

Registering the command:

            vscode.commands.registerCommand('PowerShell.GetSessionPath', () => { return this.getDebugAdapterArgs() })

And here's what I see in the process.argv of my debug adapter:

C:\Program Files (x86)\Microsoft VS Code Insiders\Code - Insiders.exe,c:/dev/vscode-powershell/out/debugAdapter.js,${command.GetSessionPath}

[daviwil]

Also, I never see my command get invoked when I start my debugger. I've got a breakpoint set in my extension code where I register the command and it never gets hit.

Strangely, I don't see the command get invoked even when I use it in a configuration attribute:

                "configurationAttributes": {
                    "launch": {
                        "required": [
                            "program"
                        ],
                        "properties": {
                            "debugAdapterArgs": {
                                "type": "string",
                                "description": "Arguments that are sent by the extension to the debug adapter.  Not a user setting.",
                                "default": "${command.GetSessionPath}"
                            },

[weinand]

@daviwil are you expecting variable substitution to take place in the package.json? That won't work. You can use variables in the configurationAttributes contribution but their substitution is delayed until the user starts the launch config.

[weinand]

@daviwil and make sure that the extension gets activated when the command is executed, so add all commands to the activationEvents section in your package.json like this:

    "activationEvents": [
        "onCommand:extension.pickNodeProcess",
        "onCommand:extension.node-debug.provideInitialConfigurations"
    ],

[weinand]

@daviwil and make sure that all those package.json contributions are only registered if you run your extension. Just editing package.json and then running the debug adapter isn't enough. You'll have to run (or better debug) the extension and from the new VS Code window you can start the launch config.

[daviwil]

I'm expecting the variable substitution to happen for my debug adapter's args field when the user starts the PowerShell debugger. Does this mean that variable substitution doesn't happen outside of the configurationAttributes section for debugger contributions? I'm trying to avoid using configuration attributes for this because it will require me to read the content of messages coming from the debug client before I pass them on via TCP to my real debug adapter which runs in another process.

My extension is already activated at this point (but I am aware that I'll need the activation event in case the user somehow starts the debugger if it's not activated yet).

[daviwil]

Yep, I am debugging my extension using a new instance of VS Code with --extensionDevelopmentPath set.

[weinand]

Variable substitution only takes place for all attribute values of a selected launch configuration when a new debug session is started.

I don't understand what you mean by "doesn't happen outside of the configurationAttributes section" since variable substitution does not even take place "inside" the configurationAttributes section.
Yes, you can use variables inside the "configurationAttributes" contribution but these variables are not substituted when the initial launch configuration is created. There are just literally copied.

Substitution occurs when the launch config is started.

[daviwil]

Yes, I intend for this substitution to occur when the launch config starts, I'm not concerned with launch config creation time because I need the debug adapter's arguments to be populated using a command at the moment when the debugger gets launched.

Maybe it would help to say step-by-step what I expect to happen:

1. User creates a launch config or has an existing launch config for the PowerShell debugger
2. User starts the VS Code debugger with their PowerShell launch configuration
3. VS Code uses the debugger contribution in the PowerShell extension to determine which program it should launch and resolves one of the adapter's command line arguments using an extension command
4. VS Code launches the debug adapter process and passes the specified process arguments including the one that was resolved at launch time using an extension command
5. The PowerShell debug adapter starts up, reads the command line arguments and uses them to configure itself before the debug client starts sending messages

I apologize for the lack of clarity in my questions, thanks a lot for helping me with this!

[weinand]

No variable substitution occurs in your step 3 because "the adapter's command line arguments" are not part of a launch config (and variable substitution only occurs for launch configs).

In your initial question I assumed that you were referring to the 'args' or 'env' parameters of a launch configuration (which are passed to the 'launch' request of the debug adapter). But actually you were asking about 'args' passed to the debug adapter itself (and 'env' is not even supported here).

We do not support variable substitution for arguments that are passed to the debug adapter (and we probably never will). But we are considering to open up the whole process of launching a debug adapter by moving it to the extension (optionally). With this you could write extension code that launches the debug adapter and can pass whatever arguments it needs.

[daviwil]

Thanks for the clarification! I would love it if you allowed extension code to launch the debug adapter process, that would enable a few things I've been hoping to accomplish. For now I'll just find another way to do what I need to do.

[weinand]

@daviwil please see #13833

[isidorn]

This is now supported, created microsoft/vscode-docs#689 to update the docs

[weinand]

I've created #16064 with a proposal for better command variable syntax.

[weinand]

@isidorn since #16064 did not made it into the November milestone, I suggest that we do not announce this feature in the November release.

[atian25]

@weinand I'm writing a extension to provide debug configurations.

as mentioned at docs "initialConfigurations": "extension.eggjs.provideInitialConfigurations"

my question is how to link a command to configurationSnippets?

had try "configurationSnippets": ["${command.extension.eggjs.provideConfigurationSnippets}"] and "configurationSnippets": ["extension.eggjs.provideConfigurationSnippets"] without luck.

the command is not trigger.

[atian25]

@weinand any suggest?