Allow configuration of the tool used to run programs/tests

Is your feature request related to a problem? Please describe. For web programs, the launch is hard-coded to run using build_runner (I think, it’s hard to tell) and tests are hard-coded to run using test. This causes various problems. For example tests that use builders would like to be run using build_runner test. It would be better to use webdev, and then options like --enable-expression-evaluation could be used. Many organizations have other tools they use. For example, we normally use dart_dev, which provides extra options and can be configured to be aware of organization or project-specific extra options, e.g. webdev_proxy. These issues could be fixed individually, but it can be hard to detect the right options, e.g. this PR. This could all be addressed by letting users indicate the tool. Configuration could be made easier by adding pre-defined configurations for the most common options.

Describe the solution you’d like Add a launch.json option like “tool” to indicate the tool to be used. This would probably need to provide some kind of printf-style or $args-style substitution for arguments, because there’s not much consistency between how tools that wrap others pass down arguments. e.g. build_runner test uses -- to indicate the end of build_runner args and the start of test args. dart_dev uses --build-args= and --test-args=. I’m sure there are other fun variations.

Describe alternatives you’ve considered The obvious alternative is to handle the normal Dart ecosystem options directly, but this puts more burden on the extension to get the configuration right, and doesn’t support custom tools. But it does make the configuration simpler for users.

Additional context Add any other context or screenshots about the feature request here.

[alanknight-wk]

Sweet. I got it working. The launch.json is pretty messy. I ended up with the below. And it works if I launch it from the source code actions, but if I try to run a test from within the test runner UI it fails, seems like it’s not getting this. Maybe there’s a different way to intercept that?

       {
            "name": "Run tests",
            "request": "launch",
            "type": "dart",
            "customTool": "dart",
            "customToolReplacesArgs": 2,
            "codeLens": {
              "for": [
               "run-test",
               "run-test-file",
               "run-file",
              ],
            "title": "Run", 
            },
             "toolArgs": ["run", "build_runner", "test", "--", "-pchrome"],
            },
            {
                "name": "Debug Tests",
                "request": "launch",
                "type": "dart",
                "customTool": "dart",
                "customToolReplacesArgs": 4,
                "codeLens": {
                  "for": [
                   "debug-test",
                   "debug-test-file",
                   "debug-file",
                  ],
                "title": "Debug",  
                },
                // The '-pchrome' part is required, otherwise it will try to run on the VM.
                // The --pause-after-load is useful for tests in that it will open a visible Chrome that we can use to debug.
                "toolArgs": ["run", "build_runner", "test", "--", "-pchrome", "--pause-after-load"],
                },

[DanTup]

Looks like I stoped this from working in bac9c3d5fa35a6879fb96acaf2bf25d0ec8eb45b, but I’m not sure if the reasons are sound.

One complication is that we run multiple test suites within a single invocation of the tool (for better performance) and configs could overlap/mismatch… however, since templateFor now takes a path (it was originally planned as just a boolean) we already have that confusion.

I’ve opened #3854 to revisit this.