Drop outdated launch.json entries on load_launchjs

[MoetaYuko]

Problem Statement

load_launchjs only adds entries to dap.configurations, but it does not drop outdated ones. For instance, if an entry named "foo" is added and renamed to "bar" later, both "foo" and "bar" will appear in dap.continue(), but we expect to have "bar" only.

Possible Solutions

No response

Considered Alternatives

No response

[mfussenegger]

This is because configurations can be added from other sources and therefore load_launchjs doesn't know if a entry disappeared or not.

If you know that you're managing all configurations via launch.json files you could reset them beforehand manually, e.g.:

local dap = require("dap")
dap.configurations = {}
require('dap.ext.vscode').load_launchjs()

---

One other option that has been on my mind for a while now is to have .continue() discover configurations at runtime in addition to looking up entries in the dap.configurations table. Then it would always read the configurations from the file again and show them in addition to any static definitions.

But if I add that I'd also like a extension mechanism for it, to allow plugins to discover additional configurations too. I haven't made up my mind yet how that should look like and currently isn't a priority.

[MoetaYuko]

This is because configurations can be added from other sources and therefore load_launchjs doesn't know if a entry disappeared or not.

For load_launchjs only, I think we may maintain a list of old task names. Every time after scanning launch.json, we can compare the current task list with the old one and remove invalid tasks accordingly. But when combined with other sources, extra care may be needed, e.g., when different sources provide tasks with the same name.

One other option that has been on my mind for a while now is to have .continue() discover configurations at runtime in addition to looking up entries in the dap.configurations table. Then it would always read the configurations from the file again and show them in addition to any static definitions.

But if I add that I'd also like a extension mechanism for it, to allow plugins to discover additional configurations too. I haven't made up my mind yet how that should look like and currently isn't a priority.

Dunno the internals of this plugin so can't comment much. Maybe having different sources maintain their own static task lists, and merge them in .continue() at runtime?