We swapped auto attach to js-debug in the June release with destructive results, and so reverted back to node-debug's auto attach in a recovery.

• Referenced elsewhere, we made auto attach work all the time for all process. This is neat but was highly disruptive to users who were previously used to auto attach only working when they passed --inspect flags manually.
• We also introduced, prior to making the call to disable it, implicit vs explicit auto attach, where in explicit mode we would only attach if --inspect is given.

We'd like to re-enable js-debug auto attach this coming iteration:

• Auto attach mode
  • @kieferrm brought up that auto attaching this way is a super nice way to discover debugging without knowing anything else.
  • One approach we could take is migration to a new auto attach setting, where users that had auto attach on previously default to "explicit" attach mode (only attaching if --inspect is already given) and new users get implicit auto attach.
  • Personally I would prefer to use explicit auto attach, as many Node commands I run in the console, like npm install / builds, I don't want to debug.
  • A third option would be to add Python-esque "run" editor actions. This is not related technically to auto attach, but also serves the purpose in having a clear 'default' way for users to run code with debugging enabled.
• ENOENT issues
  • The introduction of the bootloader previously caused a cascade of issues where the bootloader went missing. Most of the time this was because we observed a Node 10 install and, using logic shared between debugging and auto attach, therefore hoisted the bootloader into a tmpdir.
  • We should instead only enable auto attach if either there are no spaces in the bootloader's path (so hoisting is not needed) or we verify the user is running Node 12 or higher.
  • By default we tried to keep the bootloader in workspaceStorage. However, it seemed that in remote cases this could go missing even when environment variables for the workspace were preserved. This needs to be investigated before we can proceed.
    • Is keeping the file in the extension dir better? But this will break nightly builds where we have a new version and folder each day.
    • Alternately, could the built-in debug auto launch extension copy/store the bootloader for us in a more permanent location?