Exclude previously imported scss

[DrSammyD]

The bug branch is here

If you go into the stylesheets folder, you'll see an app and a vendor folder. The app folder has a settings and a site scss file. Inside the settings for Zurb foundation is a primary color variable that I've changed to red. Importing the settings and then importing foundation is how you're supposed to change the settings. However when the site starts you'll still see the blue primary color.

I believe that is because there is no check to see if any of the file about to be compiled check to see if they has been imported. If you look at the master branch you'll see that I've done a workaround by excluding the foundation.scss file, turning it into a partial in my app folder, and including that in my main.

[dbashford]

I think I see the problem. Or at least a problem.

The file I'd expect to be compiled is being compiled. You change settings and because of that the site.css is being compiled. And whatever is inside _settings isn't taking effect.

But it seems like the reason that it is not taking effect is because the variable assignment gets overwritten.

If your @imports are in this order:

@import "settings";
@import "../vendor/foundation/foundation";

Whatever you set in settings will get overwritten by the things pulled in inside global which is pulled in by all the components. Every component pulls in global at the top. global re-sets that variable.

If I go into global and comment out the primary-color (foundation itself won't compile, but you aren't using that, it can be removed) then the setting in your settings takes effect.

This feels like a simple order of compilation issue and Mimosa can't really solve that for you, its a pure SASS problem. All Mimosa is doing is correct. It recognizes what file needs to be compiled and compiles it. What happens from there is pure SASS.

I may be missing something though?

[DrSammyD]

If you look at my master branch, I'm still importing each component after I import the settings file I created, but the variable isn't being overwritten. This is how zurb's documentation expects it. To test this however, I'd suspect that pulling in global at the top of the site.scss file would fix the issue if you're correct. I'll be able to do this tonight. I'll let you know the outcome.

[DrSammyD]

Importing global at the top did not fix it. However, if you change the name of the folder that site.scss is in from app to zap, it fixes it. This is because it's now compiling after foundation.scss compiles because of the path is now after foundation.scss. Basically it's over writing the styles.css in the output. Perhaps adding an exclude or a main to the sass config would work. Other than that, I'll have to exclude any non partials in my bower overrides.

[dbashford]

Ok, I see now.

(Well, I still don't understand how you can have a variable above another variable and have the first one win)

Because you are using the combine module to merge things together, and you have two instances of foundation being compiled and merged, you have the vanilla foundation with its non-override combined AFTER your foundation with its custom color. And CSS being CSS, the lastest one wins.

Right?

So a quick rundown.

The right thing to be doing is to not be compiling the vanilla foundation at all. Because you don't need it. You are bringing it into your stuff. In this case, I honestly believe your bower config workaround is the right way to handle this. Even if there were a mimosa-sass dont-compile-this setting, I feel like using the bower stuff to leave out the file you don't need is a better solution.

If I'm understanding things correctly, the easiest workaround is to use the combine.folders[].exclude option. This would let you exclude the vanilla foundation from being combined into the merged styles.css.

That said, having some sort of dont-compile-this config isn't the worst idea in the world. I will keep this issue around to track that requirement.

[DrSammyD]

Yeah, that's about right. I don't understand it either, but zurb must have done something to make my settings "win" over theirs. As for a configuration, perhaps we should just specify if we want to include any non partials instead of mimosa finding everything. Then you can have a main scss file @include everything it needs. But if not, then yeah, I'll just keep my bower overrides. If so, perhaps some documentation is in order. I'll make a pull request to add it to the markdown later tonight.

[dbashford]

In this case Mimosa is smartly finding all the main files that need compiling. The extra foundation isn't a partial, its a plain old root file that needs compiling on its own because nothing includes it.

So this isn't a matter of including any non-partials, because it is already coded to do that. It finds everything, but then processes all of it to ensure it is compiling the right thing.

In this case, once Mimosa (and its mimosa core, not mimosa-sass) finds what it considers to be the root files, what you need is for it to check some sort of exclude setting before executing the compile.

[DrSammyD]

The extra foundation is indeed a root, but it's being compiled again regardless of being imported in my site.scss file.

[dbashford]

Ah, ok, cool, its all clicked for me now.

This was by virtue of sass using the _ as its partial syntax. Mimosa's core calls to its CSS compilers, passing the names of all the files of that compiler's type, asking for them to determine what the root files are. For mimosa-sass they are determined very simply as those files that are not partials, which is to say, those files that are not prefixed with _. I felt like that was the right thing to do for SASS support since SASS has the explicit convention for partials.

For mimosa-less it does a lot more work. It essentially processes all the files, reads each in, scans them for imports and makes the determination that something is a main file if nothing else includes it. mimosa-stylus does the same thing.

[DrSammyD]

So do you still feel the partial convention is the way to go? Because basically all sass frameworks will have a root in them, even if they are to be imported into another root, and this would be a problem for anybody trying to modify settings for them. Hover.css is another example that I'm using in my project, importing through bower and as a result would have to have it's root excluded if I wanted to change the settings.

[dbashford]

I think it may be appropriate to take another look at that. It's work thus far, but possibly allowing root determination via either method is the way to go. View partials as one of two options for determining what roots there are.

[DrSammyD]

Ok, well it seems you have most of the code written for it. Maybe add a compileImportedRoots option? By the way !default; is how you make sass variables be over ridden by you users settings.