Shared properties in launch.json

[czhower]

Search Terms

launch.json, configuration, url

Suggestion

The ability to specify shared properties among launch configurations.

Allowing properties to be inherited or specified in some common way while allowing overrides in individual entries would ease this situation greatly.

Use Cases

For example, I have many launch configurations that are identical except the URL. Management of changes then has to be propagated to each and every entry. Often a single launch.json can contain dozens of entries, and changing something simple but common like browser or other option must be done by search and replace. SNR itself is easy, but the repeated entries clutter up the launch.json and make spotting the actual differences when they exist other than URL more difficult.

I fully understand this is a corner case and not relevant to a large audience, however it would be extremely helpful for those who do need it, and the implementation is small in scope.

Examples

Not too picky about actual implementation, but a possible idea is below. Multiple shared configs accessed by name would be even better to allow multiple default settings.

{
    "version": "0.2.0",
    "defaultConfiguration": [
            "preLaunchTask": "build",
            "request": "launch",
            "sourceMaps": true,
            "port": 9222,
            "smartStep": true,
            "breakOnLoad": true,
            "webRoot": "${workspaceRoot}"
     ],
    "configurations": [
        {
            "name": "Demo1 (Chrome)",
            "type": "chrome",
            "url": "http://127.0.0.1:8888/demo1/",
        },
        {
            "name": "Demo1 (Firefox)",
            "type": "firefox",
            "url": "http://127.0.0.1:8888/demo1/",
        },
        {
            "name": "Demo2 (Chrome)",
            "type": "chrome",
            "url": "http://127.0.0.1:8888/demo2/",
        },
    ]

[vscodebot[bot]]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[MNorgren]

This would be a great feature to add to reduce the amount of duplicated configuration variables that are set in each of my launch configurations

[Trass3r]

I disagree with this being a corner case. Any non-trivial development effort will sooner or later create the need for more than 1 configuration.

[oakstair]

Fighting redundancy is every programmers main task. I just entered my first .NET project and it have 5 configurations each ca 65 lines long. So this would be a great feature. Note: In each of our configurations we have an env property ca 40 lines long. So we would need some kind of defaultConfiguration.env as well :-)

[zxxc]

There multiply implementations possible, i personally don't like having only one defaultConfiguration, instead would be very useful to refer parent config by name, something like:

{
 "name": "BaseDebugConfig",
 " type": "chrome",
  "url": "http://127.0.0.1:8888/demo1/",
  "env": { 'NODE_ENV" : "TEST" }
},
        {
            "name": "Demo1 (Chrome)",
            "$parent": "BaseDebugConfig",
              "url": "http://127.0.0.1:8888/demo2/",
        },

I understand that it requires some rules to merge json object, json arrays

But it's definitely very useful feature, even some simplest implementation would help

[Spongman]

please reopen this. 90% of my launch.json file is duplicate.

[fofoni]

This is definitely important. Not being able to share properties between configurations makes it look like launch.json is not an important feature of vs code.

I belive CMake Presets are a nice place to look for inspiration/directions about what kind of flexibility in the configuration specification would be reasonable do add, and what is expected of this functionality.

[lwestfall]

Count me in as another interested person. I'm about to make multiple configurations that are identical apart from a single environment variable which makes me sad panda.

[evyaco]

Very interested too.

[stephenonethree]

I'm also interested. I recently switched to VS Code from Pycharm and it's a huge improvement, but this is one of the few things that I'm surprised hasn't been implemented unless I'm missing an obvious workaround.

I think this would probably help with most people's workflows. In my case I have a single program but a different launch configuration for each of many flags that my program supports. My env is 10 lines per configuration and pretty much always the same. My cwd, program, console, type, and request are also always the same for this workspace.

Some sort of inheritance from the workspace level (ideally with the ability to override) would probably reduce the complexity of my launch.json by over 80%.

[stephenonethree]

I also like the OP's idea to just have a default section in the launch.json, would probably keep things simple and reduce confusion.

[Spongman]

how about adding a boolean property visible that hides the configuration from the UI when set to false, and another string property basedOn that constructs the configuration from another, copying all the properties (except visible).

[weinand]

Launch configs already support a presentation section that allows to hide entries:

[Spongman]

great, so all that's missing is the basedOn functionality.

[weinand]

@Spongman please feel free to come up with a spec and implementation for the basedOn functionality (taking into account the JSON schemes contributed by debug extensions).

[Spongman]

I'm going to leave that to the people that get paid to do such things.

I half expect the "it's open-source, fix it yourself" mantra to come from the Linux crowd, but from Microsoft? Not so much...

[MNorgren]

I see this is closed? It would be a very nice feature to add. I have about 25 environmental variables I specify for each of my launch configuration (x4). It would be nice to inherit a lot of these environmental variables from a base configuration.

[twpedersen]

can we reopen this issue?

[xhd2015]

I strongly recommend you guys consider reopen this. I even wrote a script to generate launch.json. Wouldn't it be nice to solve the duplication within vscode? Why could duplication be a problem with launch.json? When you have lots of environments for your single launch, and then you want to test your program with different arguments or something , you duplicate that launch, and modify it, with the big set of environments remained duplication.

[mttjcksn]

I agree this feature would be extremely useful. It would reduce the size of my launch.json file in one project by about 80% and make it faster and cleaner to add new targets.

[softopti]

It will be nice to have the same kind of inheritance that we have in the CMakePresets.json That support multi inheritance

[undrash]

Just give every config an optional id property and let any subsequent config refer to it to inherit from it and override with its own props. It would be extremely helpful.

i.e.

[
    {
      "id": "foo",
      "type": "node",
      "request": "launch",
      "name": "Parent",
      "skipFiles": ["<node_internals>/**"],
      "program": "${workspaceFolder}/node_modules/.bin/index",
      "env": {
        "REGION": "...",
        "ENVIRONMENT_NAME": "...",
        "PROFILE_TABLE_NAME": "..."
      },
      "runtimeExecutable": "node",
    },
    {
      "extends": "foo",
      "env": {
        "VALUE": "..."
      }
    }
]

[APengue1]

This would be a great feature, adding my support.

[starball5]

Related on Stack Overflow: How can I reuse configuration parts VS Code launch configurations?.

This also calls to mind CMake presets

[JustinGrote]

@TylerLeonhardt sorry for the ping but since @weinand is retired, who is the best contact to re-evaluate this issue for the backlog now that it has quite a few upvotes?

[TylerLeonhardt]

For debug stuff it's either @connor4312 or @roblourens

[icec102]

Why is this closed? While perhaps not top-priority, it's a simple enough optional feature to add, which would help reduce duplication in larger projects. The classic "don't duplicate code" rule holds true also for things like configs.

[libTorrentUser]

I agree with pretty much every body else here. It would be an awesome feature to have. Here is my vote to re-open this issue.

[JustinGrote]

@connor4312 is this a candidate for reopening then? Sorry for the ping.

[connor4312]

Yea, this seems popular.

[bumbar1]

any eta on this? i'm working a legacy c++ project and configurations mostly differ by arguments (it's actually DSL file) passed to application. since this was opened 6 years ago, i'm wondering if i'm doing something wrong (with many configurations specified) or yall just work on fixed codebases?

[Dude29]

This would be a tremendous addition to VS Code's debugger

[j1elo]

I got here from web searching how to reuse parts of configurations in launch.json, so I guess one more comment counts to give this issue a bit more weight.

I also happened to be working with some reusable GitHub Actions workflow and I thought that if the core idea of reusing workflows is working well for CI actions, it ought to be good enough for launch configs too.

I.e. a launch.json that contains uses: entries, each one pointing to another configuration (possibly by id in the same json file, or to a different json file altogether), including some input parameters that should be applied to each.

This is how a made up sample launch.json file could look by using a mechanism similar to the reusable Actions:

{
  "templates": [
    {
      "id": "run_with_mode",
      "inputs": {
        "run_mode": {
          "description": "Whether to run fast or slow",
          "required": false,
          "type": "string",
          "default": "fast"
        }
      },
      "type": "go",
      "request": "launch",
      "mode": "exec",
      "program": "${workspaceFolder}/bin/program",
      "env": {
        "MY_RUN_MODE": "${{ inputs.run_mode }}"
      },
      "args": ["--verbose"],
      "preLaunchTask": "mage build",
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen",
      "hideSystemGoroutines": true
    }
  ],
  "configurations": [
    {
      "name": "Run (Fast)",
      "uses": "run_with_mode",
      "with": {
        "run_mode": "fast"
      }
    },
    {
      "name": "Run (Slow)",
      "uses": "run_with_mode",
      "with": {
        "run_mode": "slow"
      }
    },
    {
      "name": "Run (Default)",
      "uses": "run_with_mode"
    }
  ]
}

EDIT: Or maybe this is a bit overkill, and the idea of just letting a config refer to a previously defined config (as in https://github.com/microsoft/vscode/issues/53557#issuecomment-1683885226) would be good enough. I'm just brainstorming some proposal ideas here.

[iamsergio]

Some weeks ago I wrote vscode-workspace-gen, which basically takes a template as input and generates the *.code-workspace (or launch.json) files. The template itself is JSON, but allows for sharing objects instead of duplicating them. Only the generated files have the duplication.

[dimateos]

Just wanted to mention that most of this logic also applies to tasks in many cases: launch a process with slightly different params.

So maybe tasks could be considered for this feature too.

[budaestew]

It's surprising that this simple feature is still open.

[JustinGrote]

@budaestew if it's so simple then you should PR it, otherwise those kind of comments are not helpful :)

[icec102]

Just writing a line here to add some yearly activity, since I'm still wishing for this feature to make the cut. Maybe 2025...?