-
Notifications
You must be signed in to change notification settings - Fork 104
getDependencies does not respect sass load paths #47
Comments
Im having similar issue, a change to ANY @import (file has leading underscore) does not trigger a rebuild of app.css. I ran brunch as follows:
I get the following output if I touch app.scss:
However if I touch an ``_variables.scss` which is imported by app.sccs, all I see is this:
That just looks wrong to me, it seems the imported file is not being registered as a dependency of app.scss, it shouldn't be compiling _variables.scss all but instead triggering a compile of app.scss |
@ahacking I don't think this is the same as the original issue. The message says that it is compiling the dependency's parent(s), which would appear correct. If nothing happens after those two log lines then there may be a different problem than missing the alternate load paths. |
Well I figured there could be a common defect because I can't get dependencies to trigger compilation of the parent in any situation. I just don't have time to investigate further but thought the trace may lead to some insight as brunch is currently not really performing as advertised with respect to Sass. |
For example, given this folder structure:
, have this in the
bundle.sass
:and this in the
brunch-config.coffee
:the
app.css
doesn't get recompiled on_component.sass
change. It also doesn't get recompiled if I add some load path to sass and make import path inbundle.sass
relative to it. But everything is ok if import path is"../components/component"
.I add some debugging to
getDependencies
function insass-brunch
and it's third argument (callback) is being called with:Not sure is it
sass-brunch
usage ofprogeny
issue orprogeny
issue itself, but it would be nice to have this working properly.The text was updated successfully, but these errors were encountered: