I have an app with the asset pipeline set up and ready to go. I do not use require_tree. It looks something like this:
*= require reset
*= require header
*= require footer
Each of those files is a .css, or a .css.scss or maybe even some .css.scss.erb. The problem with Bourbon's recommended (mv application.css to application.css.scss approach) is that you then must use @import directives everywhere. And that means that my files can no longer take advantage of the asset pipeline (goodbye .css.scss.erb files) This makes me sad.
Anyways, I went ahead and added "@import 'bourbon';" to the top of a bunch of my css/scss/erb files, and recompiled, and there's no diff to the resulting application-.css file.
So, instead of using your recommended approach, I can just "@import 'bourbon'" at the top of any css/scss/erb file that I need to use Bourbon. The asset pipeline can still be used (yay, scss.erb files). Sure, maybe precompiling my assets takes a bit longer - but whatever.
Do you see any problems with this approach? Should it be the recommended way of installing bourbon?
If you use the asset pipeline instead of @import, you lose the ability to share things, such as variables, between different scss files.
I echo what @gmflash said.
I am aware that the approach does in fact work, but cannot nail down really strong reasons as to why it is not the preferred method. I will try to do some research to determine if the preferred method should be changed.
I wonder why you depend on scss.erb files for using the asset pipeline in the first place? You could just use the sass-helpers from the sass-rails gem instead (https://github.com/rails/sass-rails#features). You get the additional bonus of glob imports.
In my experience using assets pipeline makes it faster to develop sass vs. import directives, since whenever one of scss files is changed, sprockets only recompile this one file vs. entire application.scss with possibly dozens of imports, so sprockets + livereload makes recompiling of assets in development much faster vs. tons of imports.
I would argue that global scope for imported sass is a good thing. Global state in programming often leads to unwanted side effects or messy code.
You could still share your sass environment by including at top of each sass file
where in shared.scss you import your variables, mixins and functions. That's where you could include bourbon mixins. Any extra stuff is imported only in certain files where it is needed and used. This approach makes you think harder about maintaining your stylesheet structure and making things really modular.
Compile times can be also reduced by cherry-picking only the mixins you really use and not entire bourbon (same with bootstrap, foundation, any framework really).
I wish there was fast reliable sass library, but libsass is definitely not production-ready and lacks many of sass features :(