Breakpoints in Typescript

I'm having some issues debugging client-side TypeScript in WebStorm (9.0.2) and I was wondering whether this is a known issue or if there is a workaround for it.

I can reproduce the issue from scratch as follows:

Set up the project from scratch:
- creating a new Angular JS project
- fix up the project (add the missing angular node.js package)
- npm install
- rename app/view1/view1.js to view1.ts
- enable the file watcher for TypeScript
- verify that view1.ts gets compiled to view1.js

Run and debug:
- to run: debug index.html (default JavaScript Debug configuration, running Chrome)

Now when I set a breakpoint in view1.ts, it is marked as resolved (red dot with check mark), but the breakpoint is _not_ hit when reloading the page in the browser.

If I set a breakpoint in view1.js instead, the breakpoint _is_ hit, but the code of view1.ts OR view1.js is shown (randomly?) In both cases, if I then step-over, the debugger continues to step through view1.ts.

Similar for the debugger; statement. Sometimes it breaks into view1.js, sometimes into view1.ts.

Debugging the same code in Chrome works flawlessly, breakpoints can only be set in view1.ts and it always breaks into view1.ts. Which indicates that the js.map file is set up correctly.

Any idea why breakpoints for TypeScript work so unreliably in WebStorm? It would be really nice to be able to debug TypeScript in WebStorm, using breakpoints and all.

6 comments
Comment actions Permalink

Works for me using provided steps - see attached screenshot



Attachment(s):
debug.png
0
Comment actions Permalink

Thanks for trying it out! Yes, that's exactly what I'm trying to do and what doesn't work for me. If I set a breakpoint at the same line in view1.ts, it is not hit. But it is hit when I add the breakpoint at the corresponding line in view1.js.

I've tried this on three Windows machines and one Ubuntu machine so far. And I'm seeing exactly the same problem on all of them.

Actually I just found that when I restart WebStorm, set a breakpoint in view1.ts, it is NOT hit (as mentioned above). But if I then add a breakpoint in view1.js, hit it, remove it - after doing that, breakpoints in view1.ts DO work. So it almost looks like something isn't initialized properly until a breakpoint in a Javascript file is hit. The behavior is not consistent however. I tried the same thing on a different .ts file, and there it didn't help to place a breakpoint in the corresponding .js first.

Could it be related to the version of Typescript (possibly generating a map file that's not fully understood by WebStorm?) My version of tsc is 1.3.0.0. Chrome 39.0.2171.99 m. JetBrains IDE Support 2.0.7.

0
Comment actions Permalink

tried with the latest TypeScript (1.4.1) - still works for me
Please can you attach a project that shows up the issue? Also, can you check if upgrading to webStorm 9.0.3 makes any difference?

0
Comment actions Permalink

Thanks for your reply.

I've updated to Webstorm  9.0.3 and TypeScript 1.4.1. But it still behaves the same way. Find  attached the project and a screen capture of how the project was  created, also showing the problem.

2:01: first time around, the BP in view1.ts is hit correctly
2:20: BP in view1.ts is NOT hit on reload
2:39: BP in view1.js is hit, but code of view1.ts is shown
2:51: step-over continues to debug view1.ts
3:12: setting the BP in view1.js again, the BP is hit and this time view1.js is shown!
3:34: just to verify, BP in view1.ts still not hit
3:45: re-starting the session, the BP in view1.ts is hit correctly...
3:45: ... but when re-loading the BP in view1.ts is not hit anymore



Attachment(s):
ScreenCapture_20.01.2015 13.46.53.wmv.zip
TSTest.zip
0
Comment actions Permalink

yes, indeed - breakpoints in the code that is executed on page loading are not hit when re-loading page in browser. Logged as https://youtrack.jetbrains.com/issue/WEB-14882, please vote for it

0
Comment actions Permalink

Thanks!

Yes, breakpoints in .ts not working on page reloading might be the core of the problem. I think I've seen other issues as well, but they might all be related to page reloading somehow.

0

Please sign in to leave a comment.