VSCode Debugging not working when cachedir already exists

[kroeder]

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.

[blakeembrey]

I won't be able to accept that change as is, it's basically rendering the cache directory irrelevant and removing the benefits. If that's what you want, can't you just disable the cache? If you can find the root cause, I am happy to fix it. Feel free to inline the source maps instead of writing them to disk to see if that makes a difference - if that works with VS Code debugging I'd prefer to inline it all anyway.

[kroeder]

I'll try to figure out why the cache prevents vscode from debugging correctly - thought you may know what causes the issue by just looking at the changed code

I could just disable the cache but I'm more a friend of fixing instead of avoiding it.

[blakeembrey]

If I get around to it, I can try refactoring it so the source map and content are part of the same file. When I do that, I can ask you to test it again and see what happens.

[kroeder]

Sure, just let me know and I'll test it.

[mattflix]

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?

[blakeembrey]

@kroeder Finally did it! See https://github.com/TypeStrong/ts-node/releases/tag/v3.1.0.

[jordond]

I'm still having this issue, even with the latest version of ts-node. I've worked around it for now by adding the "--no-cache" flag.

[i-C-o-d-e-r]

What @mattflix described and analyzed is exactly the problem that I still have using VS Code 1.29.1, Node 10.13.0 and ts-node 7.0.1 on Win10 (so pretty much the latest version available today).

Even though the ts-node README explains that the default for the "--no-cache" option is true, it obviously is false by default.

As I was not sure how to pass the "--no-cache" option to ts-node when using the
node -r ts-node/register syntax, I used the environment variable TS_NODE_CACHE=false, which helped debugging with VS-Code reliably. If someone can tell me how to pass the option using that syntax, that would help me.

@blakeembrey, if you are sure that this is not a ts-node issue, I would be happy to help by opening an issue in the vs-code repository.

[fhucko]

@hubbergit thanks for the env variable tip for the VS Code, I added it to launch.json like this:
"env": { "TS_NODE_CACHE": "false" }, and it works.
I also tried passing --no-cache option to various places in args, but that did not work.

[tonyhallett]

Why don't you close this ? You have replaced with MemoryCache

[mattflix]

@tonyhallett, what is the basis for closing? Because the problem is fixed? Are you just assuming because the cache implementation was changed, the problem described here not longer applies. I don't necessarily think that is true.

[tonyhallett]

@mattflix I would have thought that given that every single comment mentions the cache directory, --no-cache option / environment variable and the title of the issue is 'VSCode Debugging not working when cachedir already exists' it should be ok to close given that there is no longer a cache directory and no option for turning off the cache ( obviously ).

I have an issue with vscode debugging that has brought me to download the source and to try and determine if ts-code is the cause of the issue. My issue is with running gulp and the new MemoryCache does not really come into play. On each debug session ts-node register is invoked and then compile. So there is no cache between debug sessions and ts-node works the same each time. The source maps are provided by typescript and inlined in to the transpiled javascript.

Yet the issue I have is that debugging works initially with the transpiled javascript with source maps and then inexplicably does not on the next debug session despite there being no change in my gulp typescript file or any dependencies, or what is returned by ts-node.

[mattflix]

I guess what I'm trying to say is that I don't think the problem is about the particular cache implementation (disk or memory), but rather that a cache (of any kind) is in play.

My personal feeling is the timing of something is changed (that somehow affects the debugger) when the cache (whatever the implementation) is already populated. Things will clearly happen faster when the cache is populated. When things are not cached, things happen more slowly.

When I originally filed this bug, I put the apparently cause ("cache folder already exists") and effect ("debugger does not work") in terms of the current implementation.

It sounds like you're still experiencing the same issue... debugger does not work the second time around (after things have been cached).

So, it seems the same behavior is present. Perhaps we simply change the name of this issue? Or, we can close it and open a new one.

Bottom line: I don't think the underlying bug is fixed at all.

[tonyhallett]

@mattflix But the cache ( MemoryCache ) is empty when I debug the second time. ts-node is loaded/registered afresh. So it cannot be the cause of my issue.

Are you still experiencing your problem or have you abandoned ts-node ?
In what capacity was you using it to get your errors ?

There is something about the LanguageServiceHost/MemoryCache interaction with the LanguageService/Program/HostCache that I am not too sure about that may cause issues under different circumstances to my own - I should be able to look at it in depth over the weekend.

[tonyhallett]

@mattflix I have create a very simple repo that demonstrates my issue ( on my machine at least ) and reported the issue vscode, although it could well be a gulp issue rather than vscode.

[tonyhallett]

@mattflix

The LanguageServiceHost/MemoryCache is working as expected when ts-node is kept alive and compile is called again for a changed file.

I would suggest that this is closed if you are no longer experiencing the same problem when using the new MemoryCache. The example project debugs correctly for me with the MemoryCache.

It is this issue that made me think that ts-node could be responsible for my vscode debugging issue and led me to spend unnecessary time checking the ts-node source code.

[i-C-o-d-e-r]

I am using VS-Code 1.33.1, Node 10.15.3 and ts-node 8.1.0 at the moment and I cannot reproduce the problem anymore. I was using the environment variable workaround, but it seems that it is not necessary anymore.

Can anyone else double check, please?

[levrik]

VSCode 1.34.0, Node 10.15.3 and ts-node 8.1.0
Not breakpoints are hit, also with TS_NODE_CACHE set to false.

[blakeembrey]

Closing as “resolved” now the cache has been removed. Thanks!