ts-node debugger not working properly in v1.64

[inevolin]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.64
• OS Version: Windows 10 & Macbook pro M1

Steps to Reproduce:

We have a code repo consisting of submodules.
The debugger works fine on the entry point package, but it's no longer hitting breakpoints on any other submodule.

Structure:

import { Something } from "@repo/dao"

async function main() {
  let x  = 5;
  x = Something.use(x); // debugger no longer stepping inside properly (not hitting bkps)
  console.log(x);
}

main();

.vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch Program",
      "runtimeExecutable": "ts-node",
      "cwd": "${workspaceFolder}/packages/api",
      "request": "launch",
      "skipFiles": ["<node_internals>/**"],
      "type": "pwa-node",
      "args": ["build/index.js"],
      "runtimeArgs": [ "-r", "ts-node/register" ],
      "outputCapture": "std"
    }
  ]
 }

[connor4312]

/jsDebugLogs

[dw1284]

vscode-debugadapter-0e914697.json.gz

[inevolin]

vscode-debugadapter-0e914697.json.gz

@connor4312 let us know if this contains enough info or not :)

[inevolin]

Another annoying issue (likely related) is changes across modules are not picked up as before.
If I change a function declaration (or interface), it's not reflected in the other modules in vscode.
Meaning, unless I open the file where the error should occur, it's not showing me the problem(s) proactively.

Sometimes I even have to re-build a module until vscode picks up the change.

[inevolin]

@connor4312 I was able to fix our issue (temporarily) by specifying outFiles in the launch.json -- apparently it's highly recommended/required to debug TypeScript, funny that it was working before the latest update without this property.

[connor4312]

Yea, since cwd was set to "cwd": "${workspaceFolder}/packages/api",, the debugger narrowed the outFiles to that directory, but a breakpoint was set in ${workspaceFolder}/packages/trustframework. This was actually added in microsoft/vscode-js-debug#326 to improve performance in large monorepos, but it was only done if a program was present in the launch.json, whereas now it's also supported based off the cwd.

However, this has caused some issues, here and when it was initially added. Now, we have a warning that shows up if scanning outFiles is taking too long. I think it would be reasonable to adjust the logic to avoid narrowing and only allow widening. We can easily warn if the outFiles are too wide, but not too narrow. Consumers in monorepos will usually be more advanced users anyway, and if they need to narrow their outFiles for performance (a subset of monorepo users to start with) then they see the warning message and can do so.

[connor4312]

This will be in the next nightly build

[inevolin]

amazing, thank you @connor4312

[rzhao271]

Hi @inevolin, has the issue been fixed with the nightly build?

[vscodenpa]

This bug has been fixed in the latest release of VS Code Insiders!

@inevolin, you can help us out by commenting /verified if things are now working as expected.

If things still don't seem right, please ensure you're on version 078f8e9 of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.

Happy Coding!