Webstorm Caching Code????
I'm becoming frustrated with Webstorm. It may be because I'm new to it and so far love it EXCEPT lately where it seems to cache code when I debug.
So here's what is frustrating me, just an example of steps to reproduce my frustration/issue:
1) I setup my debug config to point to http://localhost/whatever.html
2) Set debug points run in chrome
3) Hits my breakpoints fine
5) I notice there's this extra temporary file Webstorm is creating that's a copy of whatever code I'm testing. So for example during debug it creates this whatever.html file in webstorm when I am debugging
When I stop debug, that Http://localhost/whatever.html (which is the path I see if I mouse over this file webstorm is creating dynamically shows)
4) Stop the debug by pressing the stop (Square button) in the debug panel at the bottom of Webstorm
6) So I close out this temporary file or whatever it is that is apparently read-only and is a new tab in my Webstorm (new file during debug)
7) open back up my actual file (whatever.html or another js file, whatever) and make code changes
8) When I debug, for some reason it's debugging OLD code, the code before my changes. So in that http://localhost/whatever file it's creating it's creating a copy of it that does NOT include my latest code changes
9) end up having to completely close out Webstorm every time I make a code modification, close the browser, then re-run debug to be able to debug my LATEST code changes that I just made every freakin time
Lets look at this from a print screen perspective so you can see what's going on:
1) Start debug on an .html file
2) Run it, here you see it's running and the WS Chrome Plugin is connected and knows of this page
3) WS creates some kind of cached or temporary debug file during runtime within WS itself in addition to my actual file that's already open in WS; not sure why or what this is:
so what's happening? why is it creating this?
4) Ok so once I'm done debugging, figure hey I need to make more code changes to this .html file, I naturally stop debug, close the mysterious debugging .html cache file, close my browser (chrome) after removing cache manually just to make sure, and then make code changes and then restart debug
Now once it hits my debug point, it's not showing those new comments I had added, it's showing the code state before I had added those comments. What gives? 
5) It starts back up in the browser and eventually hits my debug point again (the debug piont that lies in the mysterious .html runtime debug file that's created inside WS durign debugging)
only this time it's showing stale code even though I had changed the code! So what is going on?
6) Ultimately to be able to debug my new code changes I end up having to stop the debug process in WS via the stop button, close te mysterious debug html runtime file, close WS completely!, delete browser cache if it hasn't been, reopen WS and BTW, and having to stop the debug again! (see comments below) and then restart and debug...FINALLY I can debug new changes but this is ludacris.
Surely it must be something I do not know about how to work with WS?? lets hope. ( I have looked at your debug docs and as far as I've seen I can't find anything that talks about it creating this temporary debug runtime file within WS when debugging.)
and here's another weird thing to add for # 6
(when I reopen WS after this here's another strange thing, even though I had stopped the debugger prior to completely closing WS, when I reopen WS the debugger shows still running!)
Please sign in to leave a comment.
Hello!
can you elaborate a bit more on your project configuration? Is your WS project located in your web server doc root folder, or in some other place, so that you deploy your source files to server upon changing them? What does your run configuration look like?
The sample project that shows up your issue would be helpful
Best regards,
Lena
Not sure what you mean by "Project Configuration". Are you asking if I created a project in WS? No I didn't nor do any of my friends who use WS in their java shops as I was told WS creates a project automatically for you when you open a directory (meaning WS creates an .idea folder when you open a file directory). We just open whatever root folder inside WS and start working on code (see the blurred left side of my pics).
So the folder where our ".NET solution and projet files" exist is of course local on my PC hence I'm testing over localhost.
.NET shouldn't have anythign to do with this though. WS is hooking into the runtime of the browser via the Chrome Plugin so I want answers to my questions above. Why is WS creating a temp file during debug in runtime? And other questions I have above.
and as far as deploying, I don't do that. I just check in our files to SVN. I run IIS locally and test and that's it.
unrelated feedback for Jetbrains and WS:
you guys really need to update your docs on debugging. IMO they are ok but need a lot more info. When I first read your docs and was trying to set my debug points, I was putting in a filepath to whatever file I wanted to try and test rather than http://localhost (a browser url) and so I was hitting my head thinking wtf. I see people trying to run their code and debug via file url. You just do not do that period! Doesn't make sense.
People should be running over a url. Your docs don't say that enough. So I was hitting my head and asked a friend who knows WS and he simply said oh, there's your problem, you specified a filepath not a url in your.
So here's my recommendation to improve usability, a simple label change which will help for this part of WS:
Where can we submit feature requests or usability improvements to JetBrains for WS?
can someone address this? It's driving me crazy and this is going to determine whether or not I end up buying (and promoting in the future) webstorm from here on out. I want to resolve these concerns and issues in this thread that I've experienced. I'm on a 20+ dev team, fairly good size and can promot this awesome tool only if these issues are not going to be surfacing like this or if they are not issues/bugs, then tell me what I do not understand about WS.
With a tool this awesome, I should not have to be then closing and reopening just to be able to get the tool to recognize code changes when debugging! And I need you guys to talk about what that temporary runtime html tab is relating to the file you are testing is. Again nowhere in your docs do I see anythign about it which I find very odd.
Hi there,
There is a holidays in Russia (1st of May; Easter; Victory Day) .. over 1 week long (with some small break) -- most likely devs will not be available during this time.
Anyway, I do not know what manual you have followed, but have a look at these articles/how-tos in case you have not seen them yet -- they should provide answers (they are helping others, so I see no reason why they should fail this time):
Regarding "requires restart because it seems to be caching the file". I'm not using JavaScript much (some basic jQuery and alike), but AFAIK what you have described should not be happening -- quite possible you have not set it up correctly (possibly, just possibly, you have not setup Deployment entry -- IDE uses info from it when working with URLs).
AFAIK the temporal html file usually gets created if you trying to debug .js file directly -- it just adds html file wrapper which loads that file. Why it's created in your case is unclear for me.
see this is exactly what I'm talking about. I was browsing the Chrome plugin site to reinstall my WS extension. I gave you guys a 5 star review but noticed the latest commenter said this:
Mircea MApr 21, 2013
Very annoying.
So how can nobody understand what I'm talking about when I posted all thsoe screen shots? Why are we having to completely close out WS and reopen it every time we want to debug our changes? If we don't clsoe it, the debugger picks up the old code (before you had saved the new code in whatever .js or .html file).
This has to be a bug... I highly doubt it's how I setup config. I mean really, all I did was setup a js config to talk to my localhost site via WS matched port and run it. Nobody knows what this intermediate copy of the .html file is when you are debugging? And why do we have to close and reopen just to get WS debug to pick up the latest file state? I actually uninstalled and reinstalled WS, same damn issue. Totally stupid that I have to do this every time not to mention it's very embarrassing to JetBrains when people see me using WebStorm and asking why the f are you having to close and reopen it every time you make a code change then start debug again.
common guys! I know I'm not the only one with this show stopping issue.
So nobody has seen any of this? I can't be the only one who sees the extra http window pop up inside WS when debugging nor does it look like in Windows I'm the only one getting the problem where you have to completely shut down WS in order to debug again after every code change.
Also in that first link you sent me for
Debugging JavaScript locally in Firefox with WebStorm and PhpStorm
I think it's very bad that JetBrains is showing in this tutorial to link to a file instead of URL. Nobody in real life does that. You always listen to a url when debugging. And file doesn't even work, there are security issues in the browser that prevents it from running anyway. I don't get why they are showing examples using file instead of referring to urls for pages that you wanna debug.
I'm not JS guy -- just using some rather simple jQuery code from time to time to implement simple functionality ("hide this, show that" kind of things).
I'm using "Remote JavaScript Debug" type of Run/Debug Configuration every time when I need to debug any JS, even if all my code is local -- always works. Try the same -- maybe all these issues you are facing here because of that?
The only extra it requires is to set mapping between URL and actual project files (in most cases (if URL reflects file structure) there will be single mapping: project root <--> root URL), for example:
Hey CoffeeAddict,
Couple of questions...
1) Do you have live edit on or off while all this is going on?
2) After you stop the debug session, make changes and restart, can you confirm that it's loading in the same tab in Chrome, or does it load it in a new tab?
3) Is your application one that would be cached by Chrome if you were hitting it directly without the JB chrome extension? For example an app using requireJS will be cached unless url cachebusters are put in or caching is disabled in Chrome (usually through the setting in dev tools).
I'm new to this product too and just switched over to test it out as my new IDE. Here's what happened for me...if live edit was on (and I made any changes) if I restarted the debugging session either through "rerun" or through a manual stop and restart it opened a new debug session in a new tab in chrome and my changes didn't get picked up.
If live edit was off and I reran the debug session or if I used the "reload in browser" feature or reloaded manually in the browser (and didn't stop the current debugging session), then my changes did get picked up.
There were some caveats...
1) If a new file had been created, I had to either reload manually in the actual browser or go to my project entry point, ie index.html and use the "reload in browser" shortcut from there. Otherwise it seemed the debugger didn't pick up anything in the new file.
2) My app was being cached by the browser because I was testing with a requireJS app. Normally for these apps I set "disable cache" in the chrome developer tools but this only works when the developer tools are active. Since the JB Chrome extension disconnects if you activate the devtools I couldn't use this feature. So I had to resort to putting in a cachebuster in using the requireJS config urlArgs parameter to add a unique timestamp to each call. This is a caching issue in the browser and not necessarily Web Storm. However other IDEs do work around it, because Netbeans 7.3 always brings back a fresh version of the app when rerunning regardless of any cache parameters/settings I have set in my app or in chrome (Netbeans 7.3 has a Chrome extension similar to the JB one).
It took me a while to figure all this out, and I'm not sure I even have it all accounted for properly. I'm guessing it may behave differently with a non-requirejs app.
Either way It's pretty confusing and not very intuitive. I did document some of my problems here: http://devnet.jetbrains.com/thread/442664?tstart=30 but haven't received a response as of yet. I did not get that temporary file that you are talking about so that's weird. I figured I'd share what I had discovered, to see if it helps at all. Maybe your problems are completely unrelated.
I'm kind of frustrated by this too, because I would expect rerun to just work and reload the app in the same Chrome tab and have all my changes shown no matter what. Because of this issue I'm borderline on whether not I'm gonna purchase Webstorm. Netbeans handles this issue great, but it's kind of annoying in WS. I haven't used the IDE on actual project yet, so I'll have to see how it goes during my normal workflow and if it becomes an impedence. Hopefully it's a minor issue and it won't stop me from purchasing a license because I LOVE Webstorm outside of these quirky debugger issues.
I am also very frustrated with WebStrom (2016.2.2). I have spend too many hours figuring out why my code fixes are not working and then I realise that WebStorm is running/debugging old code, even restarting webstorm doesn't help. Just restarted whole computer and uninstalled Webstorm Chrome plugin. Maybe I shouldn't use WebStorm for debugging anymore.
Edit:
Ok I investigated a little bit more. It looks like that browser doesn't update javascript cache with Ctrl+R and so WebStorm is debugging the old code with new code in the editor. It just tries to map old code steps to new code.
I'd suggest creating new forum threads when you like to report an issue/ask question. When adding comment to ancient thread, you have lower chances to get assistance.
Now back to your issue:
I can tell for sure that WebStorm doesn't cache your files, and it's very unlikely that your issue has any relation to the IDE
- what language do you work with - Javascript, Typescript, Dart?
- do you use any bundlers/build tools/etc.?
- what server are your files hosted on?
Hi, I have seen this problem occur on and off with WebStorm with just node.js debugging all on local mac laptop. I have this issue right now as I wrote some new code and Webstorm isn't stopping at the line where I set the breakpoint. Let me know what other data you need to find a workaround or fix. Node 7.7.1.
====
WebStorm 2017.1
Build #WS-171.3780.79, built on March 17, 2017
JRE: 1.8.0_112-release-736-b13 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.12.3
===
below is my JS setup screen.
Let it be known that this post is 4 years old and since then I don't have these problems with the new versions of WebStorm.
Please create a new thread. Your problem with missing breakpoints doesn't seem to have anything in common with the issue reported by @Dave 4 years ago.
I think the main point of the OP is that is wasn't picking up the new code when debugging. I got to here by googling "webstorm clear debug cache". good to hear OP does not think its an issue for him anymore. I have been using WebStorm professionally for close to 2 years and and this issue pops up once in a while especially when 100+ lines of new code has been written. It seems to settle at some point later but I haven't been able to pinpoint what resolves it eventually. The debugger is most needed when the new code is being tested and its a bummer it fails at this critical juncture. Anyways here's the new post. https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000143704-WebStorm-node-js-debugging-not-working- . Hope we can get to the bottom of this in an otherwise good product.
Solution:
On the main menu, choose File | Invalidate Caches/Restart
https://www.jetbrains.com/help/webstorm/cleaning-system-cache.html
I am experiencing same problem in RubyMine 2017.3, both in Run Code and Debug modes. This is really annoying, since you don't expect your IDE to run some old code, which might not event exist..
Product:
RubyMine 2017.3
Build #RM-173.3727.132, built on November 28, 2017
[..]
JRE: 1.8.0_152-release-1024-b6 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.10.0-42-generic
I don't remember I have this problem in WebStorm 2018.1 but in 2018.2 this issue came up. This would be very annoying when doing debugging since to restart the IDE takes time. Currently, my ways to force the update without restarting the IDE is to change the port of the built-in server each time before launching a debug.
Please can you elaborate on your issue? What problems have you faced namely? Note that Chrome extension doesn't work reliably (https://youtrack.jetbrains.com/issue/WEB-37230), but you don't actually need it for debugging. You can safely disable it in Settings | Build, Execution, Deployment | Debugger | Live Edit, Use JetBrains IDE Support extension for debugging and Live Edit
Might be your PC configuration issue (network setup, firewalls, etc.). I don't like breaking my system by playing with routing and ccleaner, sorry.
Also, as I wrote above, Chrome extension doesn't work reliably (doesn't always connect), I'd suggest turning it off
I also had this problem with 2019.1.3 after renaming a .ts file. When debugging, I could see that it was debugging the file with the old name and old contents, though the file did not exist anymore.
It happened for the first time after upgrading from 2019.1.3 rc1
I had the same problem, the browser was picking up cached files from "webpack:\\\", could see that in the sources tab in chrome dev tools.
Finally the problem went away after stopping my dotnet core kestrel server and restarting it using "dotnet run", I'm not really sure why it was cached at that point..