rokucommunity / vscode-brightscript-language

A Visual Studio Code extension for Roku's BrightScript language
MIT License
110 stars 40 forks source link

Allow using settings.json for launch configs broken in version 1.9.0-beta8 #111

Closed triwav closed 5 years ago

triwav commented 5 years ago

You can provide launch configurations in your settings.json file by wrapping in launch key. This works fine in 1.9.0-beta7 but was broken in 8. An example configuration is below.

"launch": {
        "configurations": [
            {
                "type": "brightscript",
                "request": "launch",
                "name": "BrightScript Debug: Launch 4K",
                "host": "<IP>",
                "password": "<PASS>",
                "files":[
                    "manifest",
                    "source/**/*.*",
                    "components/**/*.*",
                    "fonts/**/*.*",
                    "images/**/*.*",
                    "config.json"
                ],
                "rootDir" : "${workspaceFolder}"
            }
        ]
    }
TwitchBronBron commented 5 years ago

I found the issue. When you run a launch configuration from user settings, vscode doesn't know which workspace you are launching it for, so the folder variable is undefined. That causes this line to fail.

This is fixed, so it should land in the next beta release.

TwitchBronBron commented 5 years ago

With this specific scenario, I had to code a few different ways to try and get at the workspace folder path.

  1. Use folder param if provided (should be present anytime a launch.json debug is started)
  2. If there's only one workspace loaded in vscode, use that workspace (should catch almost everything else)
  3. If there are multiple workspaces open, prompt the user to pick which workspace they wish to use.

If the user gets to number 3 and is annoyed at needing to pick the workspace every time they debug, their only recourse is to create a launch.json, but I think that's a fair tradeoff.

TwitchBronBron commented 5 years ago

This was fixed in languageserver-beta10