-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
It would be nice to explain why you recommend this? #79
Comments
Sprockets compiles each file individually, so mixins or variables to set in one file do not work in another; hence, all the mixins and variables available via Bootstrap are not within the scope of your own files, so you can't use them. Import basically imports the files together and then they are compiled, allowing you to override and use Bootstrap. |
Fixed in 2.0.2. Links to that rather excellent explanation, in fact. |
Sorry if this is misinformed; but then doesn't this mean that you lose the performance improvements of only having to recompile the single SASS file that's been changed, when in a development environment? I suspect that not using sprockets (in order to use mixins) is the reason I have to wait ~2-3 seconds each time I want to recompile my CSS. EDIT: Aha! Think I found a really nice solution; instead of having to @import "bootstrap/variables";
@import "bootstrap/mixins"; whenever I need mixins in scope. I've got < 100ms compile times again :) |
@tombh That's a nice solution! But after that why we still using |
@namiheike It's so long ago now, I'm not sure I remember! I think it's because if you use |
Is there an |
@jabr Glob imports ( |
So on the home page you have mentioned that:
Why are Sprocket's
//= require
directives horrible? Why do you prefer@import
? That sentence is not any helpful at all. It is just confusing.The text was updated successfully, but these errors were encountered: