For some strange reason, when I switch tabs in Atom, or open a file in Atom, it’s causing Phoenix to re-compile assets and reload the page, even when there are no changes to those files.
click a .vue file tab in Atom: 17:19:37 - info: compiled myfile.vue and 320 cached files into app.js in 636 ms, and the page reloads.
click a .styl file tab in Atom: 17:20:27 - info: compiled myfile.styl and 4 cached files into app.css in 284 ms, and the page reloads.
This is happening without making any edits to those files. It’s not happening with .js files for some reason.
All I have to do is open the file in Atom, OR, click on one of the opened file’s tabs in Atom.
Can anyone who is using Atom confirm?
Me: MacOS, Atom version: 1.23.3
I’ve been using Atom and this was not happening before, so I’m not sure if an Atom update caused it, or if it’s anything that I’ve done. It’s certainly annoying!
Thanks in advance for any insight or suggestions.
p.s. This behavior is not happening in VS Code, so it does seem to be Atom related. I’m just not sure what the relationship between Atom/Phoenix could be to cause it, and I’m not sure where else to troubleshoot it.
But as soon as I change focus to another tab, then switch focus back to that tab – live-reload recompiles and a new page refresh happens in the browser.
So it does seem like Atom is automatically touching or triggering a recompile when I focus the tab, but it’s not saving the file because otherwise I’d see those unsaved changes when the page reloads.
I just tried this all again in VS Code, opened files, switched tabs, etc., and I do not see any re-compiles.
Does this mean that this is some kind of a bug in Atom? Should I report it as such?
I hate to switch to using VS Code if I can help it (only because I’m comfortable and have all my plugins set up in Atom, so you know…change). But if I can’t get this figured out I may have to switch because I can’t work like this.
Yeah, I have about everything they have and I don’t get the problem, so testing them via binary search might reveal what’s not working well on Mac’s. For note, grab the Atom Extension 'package-cop`, it allows you to bisect the extensions (it disables half, has you test, either swaps or repeats based on whether you said the issue happened or not, and keep repeating until you find the package with the issue).
Ok, so the Atom package, “status-bar” is related to the tab-focus recompiling of static assets.
However, there is still some relationship between Git (in general, not editor-related) and the watch/recompile process that I don’t understand. If I stage files (using ANY editor, OR command line git), it causes a perpetual, indefinite recompile until I stop the phoenix server or unstage the files.
Is there supposed to be a relationship between Git and the watch/recompile process in that way? Is that an expected behavior?
Also, if I re-enable the status-bar package, it only causes the recompile when I focus on the tab of a file with unstaged changes. For any other file, there is no recompile.
That’s, uh, weird… o.O
Did you find it out using package-cop?
Well git doesn’t write to the file system except on very few calls… Maybe watch what PID’s are opening up on the files? Can always test with another filewatcher and see the specific events that are coming through too?
Hmm, I wonder if the reload is happening on ‘read’ requests too, not just write, that would be odd… Unless… does the Mac OS update the (access) timestamp of a file when it is read?
EDIT: Oh, I bet the status bar is showing git information yes?
I didn’t find it with package-cop (although I did install that, so thanks for the recommendation).
So, it seems that Atom is the culprit after all, in all cases.
If I close Atom entirely, then staging files does not trigger the recompile when staging is initiated in any fashion. If Atom is open, and I use VS Code, or command line to stage, then recompile happens. Also, if I have Atom open and disable github package, then staging files does not trigger a recompile.
So, it appears to be something funky with github and status-bar packages in Atom. I still don’t necessarily understand it, but at least I know what’s causing it!
I was pulling my hair out thinking it might have been something in my recent code edits. I think I’ll spend some time with VS Code over the weekend to see if switching seems doable for me.
Next I’d definitely be running something like inotifywait (while atom is running) and have it print out every-single action it records happen to those files to see just what it looks like, then return that info here.