Summary
A JavaScript launch now forwards the adapterLaunchConfig keys the transform does not derive (#703, PR #706), but unlike attach it gives the caller no feedback about them. Attach records which keys the transform dropped and which it forwarded without recognising (recordAttachKeyDiff, src/session/launch/proxy-launcher.ts, issues #450/#466) and puts both — with a did-you-mean — in the attach_to_process response warning. Launch returns early from that diff, so:
- a typo such as
adapterLaunchConfig: { sourceMapPathOverides: … } is forwarded to js-debug and the MCP result is a clean success;
- the pinned keys (
type, request, name, console, outputCapture), the keys dropped as not applicable to a launch (__pendingTargetId, attachSimplePort, a null trace) and a wrong-typed resolveSourceMapLocations are only mentioned in the per-session log;
- the log line cannot tell
dapLaunchArgs keys (additionalProperties: true) from adapterLaunchConfig keys, since proxy-launcher.ts merges both into one bag before the transform;
- consumed generic inputs given the wrong type (
outFiles: 'dist/**', runtimeArgs: '--inspect', skipFiles: 'x') are silently replaced by the defaults;
envFile is forwarded but inert, because env is a full copy of the server environment layered above it (js-debug merges envFile first, then env, right wins), so a PORT from the file never reaches the debuggee.
Found by the review of PR #706.
What would help
Reuse the attach plumbing for launch: adapterExtraKeys is already computed for launches, and debug-launcher.ts already joins adapterNotices into the start_debugging warning. It needs a supportedLaunchKeys list on the JavaScript adapter (the attach one exists), the diff to run for launches, and the note recorded after the per-launch reset in session-manager-core.ts (which runs after the transform today, so a note pushed there would be wiped). While there, make the log attribute keys to the bag they came from, or drop the attribution.
Refs #450, #466, #703, #706.
Summary
A JavaScript launch now forwards the
adapterLaunchConfigkeys the transform does not derive (#703, PR #706), but unlike attach it gives the caller no feedback about them. Attach records which keys the transform dropped and which it forwarded without recognising (recordAttachKeyDiff,src/session/launch/proxy-launcher.ts, issues #450/#466) and puts both — with a did-you-mean — in theattach_to_processresponsewarning. Launch returns early from that diff, so:adapterLaunchConfig: { sourceMapPathOverides: … }is forwarded to js-debug and the MCP result is a clean success;type,request,name,console,outputCapture), the keys dropped as not applicable to a launch (__pendingTargetId,attachSimplePort, a nulltrace) and a wrong-typedresolveSourceMapLocationsare only mentioned in the per-session log;dapLaunchArgskeys (additionalProperties: true) fromadapterLaunchConfigkeys, sinceproxy-launcher.tsmerges both into one bag before the transform;outFiles: 'dist/**',runtimeArgs: '--inspect',skipFiles: 'x') are silently replaced by the defaults;envFileis forwarded but inert, becauseenvis a full copy of the server environment layered above it (js-debug mergesenvFilefirst, thenenv, right wins), so aPORTfrom the file never reaches the debuggee.Found by the review of PR #706.
What would help
Reuse the attach plumbing for launch:
adapterExtraKeysis already computed for launches, anddebug-launcher.tsalready joinsadapterNoticesinto thestart_debuggingwarning. It needs asupportedLaunchKeyslist on the JavaScript adapter (the attach one exists), the diff to run for launches, and the note recorded after the per-launch reset insession-manager-core.ts(which runs after the transform today, so a note pushed there would be wiped). While there, make the log attribute keys to the bag they came from, or drop the attribution.Refs #450, #466, #703, #706.