Feature request : add in code 'debugger;' to breakpoints panel for .ts and .js files

[Alphapage]

Hello,

Typescript and javascript support debugger; to stop the debugging process when hitting.

It would be great to show those breakpoints in the breakpoints panel for info and even add a checkbox to show/hide such a feature.

Thank you in advance for your feedback.

[weinand]

@Alphapage why are you using debugger; statements instead of real breakpoints?

[Alphapage]

I'm using systemjs to import and transpile my es6 files. The only way I found to debug is to use debugger; because vscode or chrome devtools breakpoints are never hit.
In vscode, I can't put breakpoints in test!transpiled file and when using debugger;, the inline sourcemap is not recognized, only chrome devtools seems to work correctly except for breakpoints.

[weinand]

@Alphapage then we should try to solve the breakpoint issues in VS Code and not add features for workarounds.
In 99% of all cases of breakpoint issues, source maps are just not created correctly.

What exactly do you mean by "In vscode, I can't put breakpoints in test!transpiled file"?
What version of VS Code are you using?
What node version?

[Alphapage]

When you system.import('test.js'), systemjs generates a test.js!transpiled file which contains the transpiled code and the inline sourcemap (from babel in my case). If I put breakpoints in test.js, then nothing happens. I can't put breakpoints in test.js!transpiled (but I can do in chrome devtools even if they are never hit).

node:4.2.4
vscode: 0.10.11

[weinand]

@Alphapage so the name of the file is 'test.js!transpiled'? The reason that you cannot set breakpoints in that file, is that VS Code doesn't recognise it as a JavaScript file. In the latest (insiders) VS Code version (released today), you can add 'js!transpiled' in your workspace settings as another extension for JavaScript files. With this you should be able to set breakpoints in 'test.js!transpiled'.

Can you try to force systemjs to not produce inlined source maps? That would make debugging much easier. If not, could you make one of those 'test.js!transpiled' available so that I can investigate?

[Alphapage]

The test.js!transpiled is:

(function(System, SystemJS) {'use strict';

System.register(['./world.js'], function (_export, _context) {
  var returnworld;
  return {
    setters: [function (_worldJs) {
      returnworld = _worldJs.default;
    }],
    execute: function () {

      console.log('running from source:hello ');
      debugger;
      // try{
      console.log('running from source:hello ' + returnworld());
      // }catch(e){console.log(e)}
    }
  };
});
//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbInRlc3QuanMiXSwibmFtZXMiOltdLCJtYXBwaW5ncyI6Ijs7Ozs7O0FBQU87Ozs7QUFFUCxjQUFRLEdBQVIsQ0FBWSw0QkFBWjtBQUNBOztBQUVBLGNBQVEsR0FBUixDQUFZLCtCQUE2QixhQUE3QixDQUFaIiwiZmlsZSI6InRlc3QuanMiLCJzb3VyY2VzQ29udGVudCI6WyJpbXBvcnQgcmV0dXJud29ybGQgZnJvbSAnLi93b3JsZC5qcydcclxuXHJcbmNvbnNvbGUubG9nKCdydW5uaW5nIGZyb20gc291cmNlOmhlbGxvICcpXHJcbmRlYnVnZ2VyIFxyXG4vLyB0cnl7XHJcbmNvbnNvbGUubG9nKCdydW5uaW5nIGZyb20gc291cmNlOmhlbGxvICcrcmV0dXJud29ybGQoKSlcclxuLy8gfWNhdGNoKGUpe2NvbnNvbGUubG9nKGUpfSJdfQ==
})(System, System);

[Alphapage]

I think the problem arises in vscode because of .js!transpiled extension which is not recognized for now.
I think vscode will behave like chrome devtools after this update, so this is a great news.
The breakpoints are never hit in both vscode and chrome devtools because of nodejs debugger limitations in my opinion which only breaks on debugger;.
That's why I'm asking for a way to list the in code debugger; and even have the ability to insert/delete debugger; when I click on a line in the document (asking me something like: Do you want to insert a breakpoint or a debugger; inside the code ?)

[weinand]

@Alphapage "breakpoints are never hit in both vscode ... because of nodejs debugger limitations" is a speculation. I would like to understand whether this is really true.

You are saying that breakpoints don't work for the snippet both in Chrome dev tools and VS Code. For Chrome dev tools the snippet has to run in the browser. For VS Code the snippet has to run in node.js. How are you able to run the snippet in these different setups?

Adding support for manipulating "debugger;" statements is a workaround. I don't see this as a feature of the base product, but more like an extension.

[Alphapage]

I'm using node-inspector for chrome devtools. Do you want a sample project ?

[weinand]

@Alphapage yes, a sample project would be great!

I don't understand "node-inspector for chrome devtools".
"node-inspector" is an alternative to VS Code node debugging.
"Chrome devtools" is for debugging JavaScript in the browser.
How is one related to the other?

[Alphapage]

https://github.com/Alphapage/testsystem is a sample project.
npm install then for vscode use launch in debug.
For node-inspector, npm run debug:test

[weinand]

@Alphapage thanks a lot for the sample project. That was very helpful. After two minutes I found the problem why breakpoints are not hit and a two line fix for it. The following screenshot shows that the debugger now has stopped on the breakpoint and not on the debugger statement. And you can see that VS Code now recognises the dynamically generated code as JavaScript:

Now i'll try to get source maps to work...

[Alphapage]

I hope you will have the same success with source maps. Congrats.

[weinand]

@Alphapage it is not that difficult: VS Code expects source maps in real files. In your case there is no real file, but its contents can be easily streamed from node.js.

[Alphapage]

@weinand Could you tell me when do you plan to release the debugger features you added ?
I'm very interested in virtual file sourcemap support.

[weinand]

@Alphapage it will be in an alpha build in the next couple of days. And the final thing in the April build.

[Alphapage]

@weinand This is a great news, I can't wwait. I'm very excited too on how you will give the ability to open the test.js!transpiled because there is no files tree explorer in debug window as far as I know. If the sourcemap redirects to test.js, we need a way to spy test.js!transpiled as in chrome devtools.

[mtrivolli]

@weinand I've tested this with the release 0.10.13-insider from March 29th and it does not seem to be resolved: If I put a breakpoint in the line before "debugger" it actually stops, but at the call to System.register in the transpiled code:

Sorry if I'm being to impatient!

[weinand]

@mtrivolli as I said: this is in the alpha release, not in the insider release. And I did not say that the issue is resolved.

[weinand]

I've added some experimental support for SystemJS to node-debug. It is now possible to set breakpoints in the source and VS Code will hit the breakpoint after SystemJS has transpiled the source at load time. For this I hook the "afterCompile" event of the node runtime.

But there is still (at least) one problem left: since the node runtime does not stop after the generated (transpiled) JavaScript has been compiled, registering breakpoints in the startup phase of the loaded JavaScript might come too late for actually hitting the breakpoints. Registration of breakpoints in code that is executed later works fine.

So in your initial sample code I'm able to hit a breakpoint on the 'console.log' line when running it delayed with setInterval():

import {returnworld} from './world.js'

setInterval(() => {
    console.log('running from source:hello ')
}, 1000);
debugger
// try{
console.log('running from source:hello '+returnworld())
// }catch(e){console.log(e)}

I have an idea for how to solve the problem of hitting breakpoints in the startup phase of a loaded module but this has to wait until the May milestone (since I'm leaving for vacation).

[Alphapage]

It seems complicated to solve for now, but there is always the debugger workaround.
Did you try in a browser instead of nodejs environment ?

But the main problem is that if you replace the first debugger by throw new Error('an error'), then vscode only stops without throwing anything: you need to catch the error manually like this: System.import('path.js').catch((err)=>throw err). We really need a better way to track any errors.

Anyway, happy holidays @weinand

[vscodebot]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that have been on the backlog for a long time but have not gained traction: We look at the number of votes the issue has received and the number of duplicate issues filed. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!