fix: add onDebugResolve activation event to fix debug adapter not found

[noahmehl]

Problem

When starting an erlang debug session without an Erlang file already open in the editor, VS Code reports:

Couldn't find a debug adapter descriptor for debug type 'erlang'
(extension might have failed to activate)

The root cause is that activationEvents currently only contains "onLanguage:erlang". The debug adapter descriptor factory is registered inside activate(), so if no .erl file is open when the debug session starts, the extension has never activated and the erlang debug type is unregistered.

Although VS Code 1.74 introduced implicit activation events for contributed debug types, this does not reliably cover all host environments (e.g. Cursor, older VS Code builds, or remote development contexts).

Affected scenario: relx releases of existing Erlang projects

This issue is most pronounced when debugging an existing OTP project managed with relx. In this workflow the runinterminal command invokes the VM directly rather than opening a source file:

{
  "name": "Start My App",
  "type": "erlang",
  "request": "launch",
  "cwd": "${workspaceRoot}",
  "runinterminal": [
    "/bin/sh",
    "-c",
    "REL=${workspaceFolder}/_build/dev/rel/myapp; VSN=$(awk '{print $2}' $REL/releases/start_erl.data); ERTS_VSN=$(awk '{print $1}' $REL/releases/start_erl.data); cd $REL; ROOTDIR=$REL BINDIR=/path/to/erlang/erts-$ERTS_VSN/bin EMU=beam PROGNAME=myapp /path/to/erlang/erts-$ERTS_VSN/bin/erlexec -boot $REL/releases/$VSN/start -mode embedded -config ${workspaceFolder}/config/sys.config -args_file ${workspaceFolder}/config/vm.args"
  ],
  "projectnode": "myapp@hostname",
  "cookie": "mycookie",
  "preLaunchTask": "Build Release"
}

Because runinterminal launches the BEAM VM directly (replicating what the relx-generated release script does internally), no .erl file is opened in the editor. onLanguage:erlang never fires before the debug adapter is needed. The user must manually open a .erl file first as a workaround — which is non-obvious and breaks the one-click debug experience.

Why call erlexec directly instead of the relx release script?

The relx-generated release binary (_build/dev/rel/myapp/bin/myapp console) is a shell script wrapper that ultimately calls erlexec with the following key environment and arguments:

What	How
ROOTDIR	Set to the release root so $ROOT in the boot script resolves to _build/dev/rel/myapp/lib/*
BINDIR	Set to the system ERTS bin/ dir so erlexec can find beam.smp
EMU=beam, PROGNAME	Required by erlexec
-boot releases/$VSN/start	The relx-generated boot file (falls back to start when appname.boot is absent)
-mode embedded	Standard for releases
-config / -args_file	Application config and VM args

Calling erlexec directly makes this explicit in the launch config, removes the relx shell script from the chain, and gives the editor a clear Erlang-native entry point for the debug session.

Fix

Add "onDebugResolve:erlang" to activationEvents in package.json:

-  "activationEvents": ["onLanguage:erlang"],
+  "activationEvents": [
+    "onLanguage:erlang",
+    "onDebugResolve:erlang"
+  ],

onDebugResolve:erlang is the correct activation event for this case — it fires when VS Code resolves a launch configuration of type erlang, before the debug adapter is requested, guaranteeing the extension is active when createDebugAdapterDescriptor is called.

Testing

1. Open a workspace containing a launch.json with "type": "erlang" and a runinterminal that starts a relx release node
2. Ensure no .erl files are open in the editor
3. Press F5 / Run → Start Debugging

Before: Couldn't find a debug adapter descriptor for debug type 'erlang' (extension might have failed to activate)

After: debug session starts normally, els_dap connects to the running node, and breakpoints can be set in .erl source files

[noahmehl]

Actually, this looks like it's needed on Mac anytime you close or re-open Visual Studio Code and you don't have an .erl file open in an editor, the debugger will not launch.

[robertoaloi]

Hi @noahmehl and thanks for your contribution. The Erlang LS project and the corresponding VS Code extension is currently deprecated/unmaintained and I would strongly encourage you to look at the ELP project instead:

https://marketplace.visualstudio.com/items?itemName=erlang-language-platform.erlang-language-platform

Among other things, the ELP extension provides a much more solid experience than Erlang LS.