Try this configuration in your launch file:

{
    "name": "Attach to Process",
    "type": "node",
    "protocol": "inspector",
    "request": "attach",
    "stopOnEntry": false,
    "port": 5858,
    "localRoot": "${workspaceRoot}",
    "remoteRoot": "/somepath/myprojectroot",
    "sourceMaps": true
}

Make sure the remoteRoot is correct path, otherwise it won't know where to look for the source files.

The following configuration works on my machine. The source code is in this GitHub repository. Running the Launch via NPM configuration from the debugger hits the breakpoint on assert.

There are more details about debugging with node-ts and VS Code in this node-ts issue. Let me know if you need more help mapping this setup to your requirements.

package.json

{
  "scripts": {
    "test": "mocha -r ts-node/register --inspect --debug-brk index.test.ts"
  },
  "devDependencies": {
    "@types/mocha": "^5.2.7",
    "@types/node": "^12.0.12",
    "mocha": "^6.1.4",
    "ts-node": "^8.3.0",
    "typescript": "^3.5.2"
  }
}

launch.json

{
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch via NPM",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["run-script", "test"],
      "port": 9229
    }
  ]
}

tsconfig.json

{
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true
  }
}

index.test.ts

import assert from 'assert';

describe('index', function () {
    it('should pass', function () {
        assert.equal(true, true);
    });
});

Disclaimer: This is not a solution, this is just me trying to answer the question the best I can because it tickled my curiosity and I found it very interesting. The following are facts, and the reasons why it is not working are just my assumptions.

What are breakpoints, and how do they work?

I'm sure you know about debuggers since you already use one, or at least, how they work globally, on the surface.

I won't go into details about software and hardware breakpoints, how do they work in details etc. since others already have and in a way better manner that I could ever achieve.

However, in short, breakpoints (debuggers, in fact, breakpoints are just a functionality of a debugger) rely on code injection in order to work.

The INT 3 instruction, as its name implies, interrupts the execution of the program where it has been injected.

We now know that breakpoints, in our case, will be injected in our code so that Node, our interpreter, will transform that to an INT 3 instruction that can be caught by our debugger.

Aliases on shells

Aliases are usually just strings to, well, alias, a long command line.

Normally, according to Bash manual (and I believe that's the case for other shells), all aliases are replaced before executing any of the compound command-line:

Bash always reads at least one complete line of input, and all lines that make up a compound command, before executing any of the commands on that line or the compound command. Aliases are expanded when a command is read, not when it is executed. Therefore, an alias definition appearing on the same line as another command does not take effect until the next line of input is read

I cannot guarantee that this is the case with zsh though, since they are not as extensive regarding how it works in the background.

So, under normal circumstances, nothing should impair the injection.

VSCode and its terminal

Now, you mentioned launching these under the VSCode terminal. I can't tell for sure because I use JetBrains IDEs, but you must be using this feature to automatically attach the debugger to any node-related project, right?

If that's the case, my assumption is that the VSCode terminal supersedes, or enhances, the shell it is using in the background, in the sense that it is acting before zsh parses your command-line.

VSCode terminal handler parses your command-line first, acknowledges that there is no node in your command-line and so, delegates the execution to the shell its using, zsh in this case. If you work with JavaScript, think of this instance of the VSCode terminal as a middleware.

The sentence that made me think this way is the following:

If the Auto Attach feature is enabled, the Node debugger automatically attaches to certain Node.js processes that have been launched from VS Code's Integrated Terminal

... implying only NodeJS processes would be affected.

But that's only my assumption and I could be completely wrong.

Now, is there a way to solve this, keeping the same features (auto-attach, aliases)? If it works like I think it does, I'm afraid not..

I had the same issue: the VS Code debugger hitting some breakpoint, but not that of my handler. I traced it down to the running directory not being what VS Code expected.

In my launch.json, I had to change

"localRoot": "${workspaceRoot}",

to

"localRoot": "${workspaceRoot}/hello_world", // or whatever folder your handler lives in

I also noticed that the edit-debug cycle is:

• edit file
• sam local invoke -d 5858
• F5 in VS Code
• debug
• continue. This stops the debugging and the cycle repeats.

sam local start-api was a bit better in the sense that I didn't have to reinvoke the cli again, but I still had to reattach after starting another HTTP request, which I thought was weird.