ts-node: VSCode Debugging not working when cachedir already exists

Hey,

I may found a bug (not sure if it’s only in VSCode).

I checked out this example project on how to debug ts-node without generating .js/map files in vscode: https://github.com/EnterpriseJSTutorial/vscode-ts-node-debugging

After npm install I opened index.ts and started debugging - everything fine so far When I re-run debugging it shows nothing, just a hint:

Breakpoint ignored because generated code not found (source map problem?)

At this point it won’t work again until I manually remove the cachedir in /appdata/local/temp/ts-node-*

After activating “All Expcetions” I found out that mkdirp(cachedir) throws an error that the directory does already exists

I checked out the latest ts-node version and used npm link in the above project

The following code changes made debugging 100% working for me, I’m not sure if this is the fix you are looking for, though:

In src/index.ts Line 185

  // Added lines
  var fs = require('fs');
  var rimraf = require('rimraf');
  if (fs.existsSync(cachedir)) {
    rimraf.sync(cachedir);
  }

  // Original code
  mkdirp.sync(cachedir);

Also, I had to add rimraf as dependency since I use it in compiled code. If you think this is the right fix I can open a pull request with a commit for this.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 3
Comments: 19 (4 by maintainers)

Most upvoted comments

I am also encountering debugging problems where using the cache feature seems to be prevent breakpoints from working in Visual Studio Code. But, probably this is not really a VS Code issue, rather a general problem between ts-node and the Node debugger.

I’ve set up a TypeScript project using ts-node in VS Code. Breakpoints work fine only the first debug session where the .ts files are compiled. In subsequent debug sessions, where cached .js files exist for the .ts files, all breakpoints in .ts files are skipped (and VS Code shows them non-validated).

Like others have noted in other issues here, you can sorta workaround this problem by inserting a “debugger;” statement here and there, and maybe your .ts breakpoints will re-validate in the same file. But, what a hassle.

However, I have discovered that ALL .ts breakpoints will work without fail (and without any “debugger;” nonsense) if I simply erase the ts-node cache folder (or just the content within it).

It also works to permanently pass the “–no-cache” option to ts-node, which is a very simple workaround for these debugging issues, but obviously defeats all benefits of having a cache.

In short… something is wrong with the caching feature of ts-node and debugging in VS Code. I’ve tried looking at verbose trace output from the Node debugger, but I don’t really know how to make sense of it.

Perhaps the ts-node authors might feel inclined to do something similar to determine what ts-node might be doing wrong between non-cached and cached runs?

mattflix on Jun 8, 2017