Restore "with args" to the launch.json options for PowerShell

[yobyot]

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues to ensure it has not already been reported.

Summary

Sometime after ec53532, PowerShell Launch Current File w/Args Prompt was removed from launch.json.

That useful way of specifying args to a script being tested hasn't been replaced or updated since. Running the script and getting a prompt for Mandatory = $true parms just isn't the same. And who wants to specify args in launch.json itself?

It's a pain to keep coming back to the repo to find the syntax for w/Args Prompt because I have too much else to remember.

Can we please put this back into launch.json?

I miss it.

Proposed Design

Put back a few lines of JSON code into launch.json that were summarily removed for some reason that's probably lost to history.

[andyleejordan]

You can add this to your individual projects' launch.json on an as-needed and personal-preference basis. Do you mean that you want it in this repo for the purposes of developing the extension itself? Perhaps I'm not sure what you're asking, feel free to open a PR!

[yobyot]

I'm saying this was in the default launch.json until at some point in the past it was removed for no apparent reason. I'd like it put back into the defaults that are available when adding a new PowerShell debug profile.

As seen in the screenshot below, it's not there. That means one has to remember it, save it somewhere else and cut-n-paste it and/or find it in the repo.

It was much more convenient when it was in the product -- and I don't understand why it was removed.

[andyleejordan]

Ok, cool! Feel free to open a PR, I'll mark this up-for-grabs 😁

[andyleejordan]

@yobyot any luck finding the prior code that we could restore?

[yobyot]

        {
            "type": "PowerShell",
            "request": "launch",
            "name": "PowerShell Launch Current File w/Args Prompt",
            "script": "${file}",
            "args": [ "${command:SpecifyScriptArgs}" ],
            "cwd": "${file}"
        }

From examples/.vscode/launch.json at ec53532.

This is from 2017 -- and was removed sometime later in the defaults. IOW, it doesn't belong in the examples; it belongs in the default launch.json.

[rkeithhill]

Back in the day, I implemented this feature #707. The configurationSnippet in question is:

          {
            "label": "PowerShell: Launch - Current File w/Args Prompt",
            "description": "Launch current file (in active editor window) under debugger, prompting first for script arguments",
            "body": {
              "type": "PowerShell",
              "request": "launch",
              "name": "PowerShell Launch Current File w/Args Prompt",
              "script": "^\"\\${file}\"",
              "args": [],
              "cwd": "^\"\\${file}\""
            }
          },

Originally we put this in the configurationSnippets & initialConfigurations fields under debuggers in the package.json. But the VSCode team complained that the PowerShell extension offered too many debug configurations by default - see #1611. So they asked us to whittle down the defaults in package.json and provide additional debug configuration via the provideDebugConfigurations provider, which I did in #2084.

When we determined what would be in the dynamic debug config list we decided to whittle the list down a bit realizing that all w/args Prompt required was the user modifying the "args" property like so:

"args": [ "${command:SpecifyScriptArgs}" ],

It's even in the tooltip for args:

That said, I have no objections to adding this launch config back in.

[andyleejordan]

Thank you for the historical context!

[andyleejordan]

Given the historical context provided by @rkeithhill and the fact that the tooltip and provided debug configurations all work as expected, we're going to stick with VS Code's ask and keep this as currently designed. Thank you though!

[yobyot]

So, let me see if I get this right. It was in, then another product group disliked the cosmetics of it (“too many entries”) and so something an unknown number users (including me) came to rely on was summarily removed.

But it’s gonna stay that way because the historical context Microsoft chooses to honor is the one that allows it to remain consistent in its own bubble.

Why even bother taking input here? It was better when users didn’t have to actually see this dysfunction in addition to being inconvenienced by it.

[andyleejordan]

So, let me see if I get this right. It was in, then another product group disliked the cosmetics of it (“too many entries”) and so something an unknown number users (including me) came to rely on was summarily removed.

But it’s gonna stay that way because the historical context Microsoft chooses to honor is the one that allows it to remain consistent in its own bubble.

Why even bother taking input here? It was better when users didn’t have to actually see this dysfunction in addition to being inconvenienced by it.

Except that "unknown product group" are the Visual Studio Code maintainers, and as Keith pointed out, no functionality was removed. A VS Code extension's priority is to follow the extension guidelines the API writers (VS Code) give us, hence this decision. It would be more helpful for you to send this feedback to VS Code itself at this point.

[ghost]

This issue has been marked as answered and has not had any activity in a day. It has been automatically closed for housekeeping purposes.