I'm not sure how specific this problem is to what I'm attempting, but it may pertain to other packages as well. I have tried to use Bower with the official Bootstrap-sass. I think in principle I prefer to manage these frameworks with something like Bower, because it seems redundant and wasteful to have separate smart packages for each (Bootstrap has css, less, and scss variants, and there are many forks and themes out there) as well as lacking a way to control the version of the framework.
However, there are some problems.
I don't think Bower gives us the config we need to figure this out, unfortunately. One possible solution would be to allow additional config in the smart.json file. Something like (paths simplified):
"exclude": ["bootstrap.js", "bootstrap.scss"]
include, if used, would replace the main array, and exclude would override those. I'm not positive this is the right solution, but it would probably work for my use case. Of course, in this case, we are now adding non-Bower config, which is adding complexity. It might still be better than individual smart packages for all the combinations, though.
I wonder how many bower packages are in this situation. Bower is supposed to be a client side package manager, so files listed in the "main" field should be compiled in html/js/css/assets because other file extensions such as .coffee or .scss aren't supported on the browser.
In this case I guess we don't want to compile all scss files in one big css, but instead we want to include mixins in our own scss files and then compile it in css on the server side. So bower doesn't appear as a good client for this job:
Why not create an atmosphere package that will:
So automatic bundling of this package doesn't seem feasible in the current state of both meteor and bower APIs.
Thanks for the thoughtful response. This may just be a "won't fix" issue, and I won't be offended if you just close with no action.
It's the build step that is the killer. I guess I would agree that including bootstrap.scss in main is a mistake on Twitter's part - it has to be compiled to use it even though it is a client side library, whereas it seems like main is for files that should be loaded directly by the browser. If we are going to add config, perhaps it makes more sense to let a smart package be the recipient of that since it can manage build, client, and server. Anyway, thanks for taking the time to think about this. :-)