If you are a front-end developer, then the time will come when you want or need to debug a file on some remote website and you want to do so by editing that file on your local hard-drive. In this article I discuss several options that I tried using, what worked and didn’t for each, and reveal which one finally worked for me.

Shut-up and get on with it, already!

The basic scenario

• There is a website, such as http://www.example.com/.
• This website has some external resource, such as script.js.
• You need to debug something that is happening inside of script.js.
• You want to debug using a copy of script.js that is on your local hard-drive.

The reason why you might want to debug this way is irrelevant, though there are several common possibilities. Perhaps the process of getting your debug changes to the remote server is such a pain in the butt that it makes the edit/save/deploy/repeat process frustrating and/or too time-consuming. Or perhaps there is something that makes debugging the entire site via a local server impractical, like it runs on an OS that you cannot run locally; or you do not have access to all of the files needed to create a local instance; or the site or feature that you need to debug uses Ajax and it cannot run cross-domain; or you need to sign-in using some specific database settings that only exists on the remote server. Suffice to say there are many reasons why you might need to do this, and these are just a few.

Whatever the reason, you are going to find yourself needing to do this one day, and when I needed to do this, I didn’t understand of a few of the techniques as well as I thought I did, and so it was quite frustrating; hopefully these notes will make life easier for some developer(s) out there… :-)

Note: I use Chrome, so I use DevTools, so I will be focusing on that browser. It is possible that other browsers have similar options, so if anyone knows of one, please share that info in the comments and I will try to update the article where it is appropriate.

Getting on with it already…

These are the three options I tried using:

• DevTools’ Workspaces,
• a DevTools Extension called Redirect, and
• Fiddler.

Each has a unique scenario where I think it makes more sense than the others, and I will describe those scenarios below.

DevTools’ Workspaces

For anyone familiar with this option, you will likely already know my mistake, and may want to skip to the next section. The rest can read on.

Chrome DevTools has a feature called Workspaces. I had played with it a few times in the past, and I thought I understood what it could do and in what situations it would be helpful. But when I tried to do what I thought it did, I found out that it didn’t do what I thought it did…

I kept getting this annoying error message in my Sources panel telling me that “the contents of this file on the local system… does not match the loaded script…” Well, duh, I thought, that’s exactly what I want to happen… And no matter what I tried I couldn’t get my saved files to replace the remote version!

Well, it turns out that Workspaces works really well if you are working with 100% local files that are being served via a localhost server (notice I don’t use the word “remote” anywhere in that sentence…).

DevTools lets you designate a local directory as a Workspace, then make edits to the files in that Workspace from within the DevTools console, and save those changes from within the DevTools console, and have them save right back to your local directory files! So basically, DevTools functions as your IDE. Which is awesome! (And even more so if you couple this set-up with something like Grunt Reload, then this gets really powerful!)

But, sadly, for me, this is not at all what I needed…

Redirect

Next up was Redirect, a Chrome Extension that lets you replace remote server files with local server files. Ah ha, I thought, here we go! You can set-up multiple domains, and under each domain you can list multiple remote file URLs that you want to replace, and then add the local file URLs that should replace them.

This sounded like just what I needed, and it was really close, except that Redirect needs to be able to fetch those local files via a localhost URL, such as http://localhost/example/script.js, and not via a directory path, such as C:\xampp\htdocs\example\scripts.js…

So, this was definitely a lot closer, but I work on several projects that require several different local servers, which is simply a hassle, trying to remember which project needs which server, and then starting each of those servers every time I needed to debug a different file…

Fiddler

Then I went back to an old standard that I had used a long time ago: Fiddler. I was hoping to not have to download yet another application, and run yet another application, and that I could just do all of this from within my comfortable Chrome DevTools environment, but for what I needed, and wanted, Fiddler ended up making sense for me: I could specify the remote file URL, then specify the local file directory location, and Fiddler would simply swap the files on each reload.

Note: Fiddler can do a lot more than simply replace resources, but that is the only feature within this article scope. Also note that it is PC-only. For Mac users, aside from using a VM to run Fiddler, you could also look into Charles Proxy, which offers similar functionality, but is also not a free application.

Update March 25, 2015: Fiddler Chrome Extension

I happened upon a Chrome Extension that calls itself Fiddler, but I am not linking to it because I cannot recommend using it. First of all, there is the comment “This is a fake extension which is violating Telerik’s trademark on Fiddler.” Second, since this Extension is not created by the good folks at Telerik, I have no idea if it is a trustworthy Extension, and do not know exactly what it is doing behind the scenes. And third, is the fact that I couldn’t get the Auto Respond feature to actually work… So, there’s that.

Conclusion

For better or worse, we are no longer in a situation where simply having Notepad and an FTP application can solve all your development needs, and this is just another example of that. Each of the recommended options above have their place in a web developer’s arsenal, so all of them are worth knowing and being prepared to use if the appropriate situation arises. I also look forward to this list growing to fill in any gaps that I have left.

I hope the above info helps you avoid a struggle one day.

Happy debugging,
Atg

Top⇪