-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compass-generated CSS files don't trigger reload #105
Comments
What about watching directly the scss file with guard-livereload?
|
Thibaud, that works -- thanks for your help. However, I think of this as a workaround. If I tell livereload to watch a path, it seems like livereload should tell the browser when that file has changed, whether I edit the file in place or delete it and replace it with a new version (which is what compass appears to be doing). To put it another way, if:
then livereload should tell the browser to reload. To me, that behavior is in the spirit of the guard API, too: But as I said, I'm still getting up to speed. If this is a won't-fix, that's OK. I'm working on a Drupal site, and the Guardfile I use was automatically generated by If this is the new way guard-livereload works, I'll open a bug report with them to update the Guardfile they generate. |
OK, cool. I'll use your workaround until then. Thanks again for your help. |
Yes, this should be fixed by the next linux/vim/inotify changes. Here's why you're getting the problem, @deisner:
This happens because until now, the listen gem was unable to detect moving and renaming a file (which is what most editors do) as a 'modified' event, which would call run_on_modifications - which is what updated guard plugins normally expect (e.g. guard-livereload). So after this new patch, everything should work perfectly. |
Any news on this? We can still reproduce this issue on latest
regardless of using vim or gedit or PHPstorm. It doesn't matter. Browser connects successfully. Files get updated with guard and compass successfully and message in terminal confirms that. Only the browser-refresh confirmation message is still missing. Refresh of Browser has to be made manually. All changes are occurring fine, but no auto-refresh from guard-livereload gets fired. One additional info: Only Gedit allows to "re-save" an already saved document. On this second re-save the Browser refresh happens successfully. Funny thou ... |
I can confirm that adding "scss" to the watching "match" in the "livereload do" function is a usable work-around for Drupal Omega subtheme for now, but if I understand this issue thread here correctly, this could be left out after fix mentioned from @thibaudgg again? Is this correct? Otherwise, is there already an issue opened on Drupal.org, @deisner? We should inform the Omega 4 theme maintainer about it (@fubhy). |
@diqidoq - first, make sure you're using the latest versions of After that, we can work out what's going on and where the fix is necessary. |
@e2: thanks for chiming in. We are using guard version 2.6.1 and listen 2.7 with ruby 2.1.2 installed via rvm locally on working root (project/sites/all/themes/THEME). Here is our --debug output without adding scss to the watch (css only, like it was before and intended usually):
No Browser refresh, but changes are made to the scss and css files.
Browser refreshes and changes are made. Here the Guardfile function:
|
Both Guard and Listen gems have been updated since. I believe this is fixed. It's best to use If there are still problems - please open a new issue, thanks! |
I'm using
When I make a change to a sass file (.scss), guard detects the change, runs compass via the guard-compass plugin-in, and updates the.css files. However, those CSS files aren't causing Chrome to actually reload the page. If I manually
touch
the .css file, the reload does happen.After some digging around, I think I know what's going on. Commit e20657 changed guard-livereload so that it uses
run_on_modifications
rather thanrun_on_changes
. When compass is run, the original .css file is apparently deleted and then regenerated. I can tell this is so becausels -i
shows the .css file has a new inode. You can also see it in the guard debugging output -- note that guard is trying to call therun_on_changes
hook:When I
touch
the .css file (i.e.$ touch css/calce-omega.styles.css
), the mtime is updated and then guard-livereload runs (via therun_on_modifications
hook) and Chrome reloads the page. Here's the guard debugging output:I'm not entirely sure why the change was made, but I think this is not the expected behavior. I'm kind of new to this, though, so I may be missing something.
The text was updated successfully, but these errors were encountered: