Do I always need to set the remote URLs for Javascript files when debugging locally in Webstorm?

I've been using Webstorm for a month now, and I'm beginning to question whether I'm configuring debug correctly each time when debugging against localhost.

My code seems fairly standard in using a single html file and a collection of javascript files organised in various directories.

When starting to debug, I've already given Webstorm both the URL and the filesystem location of the html file I want to use as the starting point of the debug session. I've also told Webstorm about the url and file location of the web root when setting up the project. But when I go, I immediately get messages about remote URLs not being specified so breakpoints won't be hit. Obviously I can set these up, but all I do each time is append the URL of the web root to the .js file path within the Webstorm project, and Webstorm already has all this information!

It strikes me that Webstorm should easily be able to work out these "remote URLs" based on the information it has. Is there a reason why it can't do this, or have I missed something in the debug setup?   




If your html files are static i.e. they aren't provided by a web server you can use a local JavaScript debug configuration. In that case files will be opened in a browser directly from the disk so there will be no need to specify any mappings at all.
If your html files are generated by a web server you indeed need to specify mappings between local folders and URLs in two places: the project configuration and the JavaScript run configuration. We already have an issue about that (


Thanks, Nikolay,

Yes, mine is a static HTML file.

I had a look at the issue you mentioned and realised I wasn't clear on the four combinations default-local, default-remote, (non-default)-local and (non-default)-remote. I had more than one set from when I was learning the ropes, so I may have been picking up then wrong one when I started debugging. So I deleted/cleared all of my configurations and started again, adding a new local config, named so that I could be sure I was choosing the right one ("Local"). This time it worked as I want, without the need for any remote URL setup. Thanks again.



Please sign in to leave a comment.