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.
请先登录再写评论。
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:(
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).
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!
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
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?
no, unlikely... debugging over https works equally well for me
please try mapping your project root folder to http://localhost:8080/tarvamt/ URL in JavaScript Debug run configuration - does it help?
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
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?
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!
Great, thank you! Happy Holidays:)
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.
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
>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.
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
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.
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.
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
I found out strangely enough effect: breakpoint does not hit in nested src folders of linked(npm link) packages.
to reproduce follow these exact commands:
now go and place a breakpoint in a typescript file inside a nested folder inside src folder, like utils. place breakpoint in ./src/utils/index.ts you will see it is not caught. if you will move ./src/utils/index.ts to ./src/utils.ts breakpoint would be caught.
I'm using the default javascript debug session configuration
can't get the project up and running using your instructions - linking fails:
E:\downloads\react-xarrows\examples>yarn run link-xarrows
yarn run v1.22.0
$ cd .. && yarn link && cd examples\ && yarn link react-xarrows
success Registered "react-xarrows".
info You can now run `yarn link "react-xarrows"` in the projects where you want to use this package and it will be used instead.
success Using linked package for "react-xarrows".
Done in 0.52s.
E:\downloads\react-xarrows\examples>yarn run fix-invalid-hooks
yarn run v1.22.0
$ npm link ../node_modules/react
npm ERR! code EINVALIDTYPE
npm ERR! typeerror Error: Argument #2: Expected array but got string
npm ERR! typeerror at EventEmitter.install (C:\nvm\v14.15.2\node_modules\npm\lib\install.js:195:3)
npm ERR! typeerror at Object.commandCache.<computed> (C:\nvm\v14.15.2\node_modules\npm\lib\npm.js:156:13)
npm ERR! typeerror at C:\nvm\v14.15.2\node_modules\npm\lib\link.js:93:24
npm ERR! typeerror at callback (C:\nvm\v14.15.2\node_modules\npm\node_modules\graceful-fs\polyfills.js:295:20)
npm ERR! typeerror at FSReqCallback.oncomplete (fs.js:183:21)
npm ERR! typeerror This is an error with npm itself. Please report this error at:
npm ERR! typeerror <https://npm.community>
npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\Elena.Pogorelova\AppData\Roaming\npm-cache\_logs\2021-07-19T16_21_37_481Z-debug.log
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
and then running fails:
Starting the development server...
Failed to compile.
./src/examplesFiles/FewArrows.jsx
Module not found: Can't resolve 'react-xarrows' in 'E:\downloads\react-xarrows\examples\src\examplesFiles'
Compiling...
this is probably because react is not installed in the root folder.
go to ./ and run
and then you can do
Ok, it starts now... But I can't see ./src/utils/index.ts in the repo. Do I miss anything?
it does not matter. any file in src/* (for example src/Xwrapper.tsx) would catch breakpoint and any breakpoint in file in src/**/* (like src/Xarrow/Xarrow.tsx) would not be caught.
Hmm... Breakpoints in src/Xwrapper.tsx are not resolved for me either. And, if I check the files being loaded in VM by inspecting a page in Chrome Dev Tools, I can see that none of .ts files from src folder the there:
well, on my machine i see src folder but not nested folder inside src. breakpoint hit on any of the files.
see gif
![jetbrains-debiugger](https://user-images.githubusercontent.com/47307889/126508391-6e5d3cbd-2563-44c4-9e2b-ec33f74ccb59.gif)
actually, you can see the other nested folder in src exists but in another locations so webstorm debugger can't find them. how can I configure webstorm to locate these files?
figured it out: see https://stackoverflow.com/questions/68336645/javascript-debugger-typescript-catches-breakpoint-on-src-but-not-on-src
but now I know the problem is with typescript which generates wrong source-map and it is not related to webstorm, however, is there a way I could make Webstorm use the correct source files?
>on my machine i see src folder but not nested folder inside src
But, as far as I can see from your screenshot, the file in Dev Tools is not the original .tsx but the compiled version, this means that breakpoints in original files won't work as source maps are not there/broken
> is there a way I could make Webstorm use the correct source files?
No way; the IDE uses sourcemaps to map original sources to code in VM. If sourcemaps are missing/broken, there is no way for the IDE to find original files
I am having the same issue trying t connect the Debugger tfor TyppeScript. From Chrome, I can Debug and set Breakpoints to the TS files, but not from the IntelliJ IDE.
In the IntelliJ IDE, I would setup the JavaScript Debugger, set the mappings to the folder in local directory, click Debug and what I receive in return is "No scripts loaded by Chrome". The Debug leaves the new Chroe Browser open and the Debug stops.
How can I get this solved?
Please share screenshots illustrating the issue (what the script look like in chrome dev tools, screenshots of your run configuration and error message)