Typescript breakpoints are not hit by debugger

what is wrong in configuration because breakpoints are not hit by the debugger in .ts files?
Typescript code main.ts and the corresponding main.js files are shown in the below picture.
Breakpoint in main.js works but not in main.ts file (the needed main.js.map exists).

tsconfig.json is the following:
{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es2016",
    "sourceMap": true
  },
  "exclude": [
    "node_modules"
  ]
}

In addition, I have used exactly the same configuration in another project and there typescript debugging works correctly.
And in order to add confusion, I'm quite sure that typescript breakpoints were working correctly when I started this new project but then suddenly they stopped working. I have compared everything with this and with the working project but cannot see any differences.

18 comments
Comment actions Permalink

As far as I can see, original ts file can't be resolved from sourcemaps (no checkmark in breakpoint).

Unfortunately I can hardly help in resolving the issue unless you provide a project that shows it up:(

0
Comment actions Permalink

Dear Elena,

I feel myself privileged because you are helping me on Christmas day, too!

Debugging problem is quite odd. In the other (a very big javascript and spring server project) debugging works quite smoothly. However, there the only odd thing is that when a breakpoint is set in the code that is the code first run when a browser is launched then:
1) breakpoint is not checked before the first run time.
2) breakpoint becomes checked during the first run time.
3) breakpoint is hit on the second run time.
This is also visualized in the below picture:

In order to get debugging work in this new project I have sent a pruned complete webstorm project in the file mikko-webstorm.zip. There the debugging problem is demonstrated with two breakpoints, one in index.html on line 38 and the other in main.ts on line 4 (this is also the main problem, i.e. how to get breakpoints to work in .ts files).

 

0
Comment actions Permalink

It often happens that breakpoints in code executed on page loading are not hit when using sourcemaps - in such cases, you need to refresh the browser page to get them hit (https://youtrack.jetbrains.com/issue/WEB-19372). This doesn't, however, explain the first issue (breakpoint not resolved on first run)...

Downloaded your project, thank you!

0
Comment actions Permalink

what server is your app hosted on? what do the server path mappings look like (when local folder corresponds to web server doc root, does the file structure on server match local file structure, etc.)? If I debug your login.html (the only page main.js is included in) on the built-in webserver, the breakpoint is hit immediately, on the very first start

0
Comment actions Permalink

I sent a new file mikko-config.zip. There are:
1) javaBuildPath.gif where is highlighted linking from webstorm root to spring resources/static directory (so this is a very basic configuration with spring and all files from webstorm should map directly below the root to the spring static resource structure)
2) login-browser-view.gif shows url to the login.html where the main.ts execution is shown by the alert box
3) mikko-tomcat-8.5.24-server.xml = server.xml of tomcat-8.5.24 that is configured to run inside eclipse oxygen ide. Web application is run in https protocol. In the end of server.xml the docBase is defined to be "<Context docBase="D:\tarvat\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\tarvamt" path="/tarvamt" reloadable="true" source="org.eclipse.jst.jee.server:tarvamt"/>" which eclipse ide has set and it is the definition needed to run web application on tomcat directly from eclipse ide (at its server tab). The only difference to the other project (where debugging works) is the https - can we blame on it?

0
Comment actions Permalink

no, unlikely... debugging over https works equally well for me

0
Comment actions Permalink

please try mapping your project root folder to http://localhost:8080/tarvamt/ URL in JavaScript Debug run configuration - does it help?

0
Comment actions Permalink

I sent a new file mikko-deployment-mappings.zip where:

1) deployment_mappings1.gif = the current settings where is seen warning "Deployment path is not specified".

2) deployment_mappings2.gif = Local path is changed as you propose to spring project root (did I understood correctly?) but this doesn't work either, i.e. login.html works exactly the same way

 

 

 

0
Comment actions Permalink

mappings should be specified between your local project root and URL on server. And i asked to specify it right in the run configuration, not in deployment settings. see https://www.jetbrains.com/help/webstorm/2017.3/debugging-javascript-deployed-to-a-remote-server.html#ws_js_debug_on_remote_server_mappings

 

and, btw, all your settings are for http, while your are debugging over https?

0
Comment actions Permalink

sorry about the wrong place to configure. Now the configuration is apparently in correct place as follows:

and finally debugging works both in index.html and in main.ts files. The protocol is now also changed to https everywhere although it is not relevant here because tomcat was configured to redirect http to https.

Thank you so much that it is nearly impossible to thank you enough! Merry Christmas and Happy New Year, too!

 

2
Comment actions Permalink

Great, thank you! Happy Holidays:)

0
Comment actions Permalink

Happens to me as well, both on Mac OSX and PC running Windows,

both intellij latest versions.

In one project everything works, in the other no break point is hit.


Work around might be:

- create a new intellij project (clone you project into a new folder)
- set it up and try running the debugger again.

 

0
Comment actions Permalink

Must be a project configuration issue; I can hardly help unless you share a project that shows it up.

Also, please make sure to create new threads for reporting new issues

0
Comment actions Permalink

>chrome NEEDS to be refreshed manually all over again to get what you did in webstorm into chrome... namely breakpoints

 

Known issue - when using sourcemaps, breakpoints in code that is executed on page loading don't immediately work unless the page is hosted on built-in webserver, see https://youtrack.jetbrains.com/issue/WEB-19372.

0
Comment actions Permalink

No idea. Debugging Angular apps works fine for me.

In 99% cases problems with debugging are configuration-specific, and there is almost no way to track them down unless there is a project the issue can be recreated with. If you can share a project, I could probably advise on setting up the debugger

0
Comment actions Permalink

Recently I have faced with the same issue with Angular 6 and my problem was solved by using --aot=true flag with ng serve. I hope it will help.

0
Comment actions Permalink

I had the same issue, it was because BEFORE debugging I had run a "ng build" on my Angular app, this created a dist folder with the compiled JS.

After deleting this folder and THEN debugging, all the break points hit where they were supposed to.

0
Comment actions Permalink

there is obviously a lack of reliable documentation

setting paths to typescript in the edit configuration

what angular folders should or should or should not be there

how about someone from webstorm documenting what the INSPIRED manner is suppose to take place if you want your breakpoints to be hit rather than have countless threads on this topic spanning over three years and still having users complain with some twisted custom solution for their build.

just saying breakpoints works for a hello world app is not responsible

there are dozens of places that can affect the runtime and hitting of breakpoints

can the problem domain experts at jetbrains list all of these since its their product and they are suppose to KNOW

and document the INSPIRED manner in which an angular app is suppose to be configured and operated ?

that would be nice to see instead of still guessing

or we are suppose to know all the angles and traps up front... 

can we have a tech doc be made to do this ?

i will tell you my breakpoints are not being hit all the time 

 

0

Please sign in to leave a comment.