config not sufficient for compiled css frameworks #5

rdickert opened this Issue Mar 12, 2014 · 2 comments


None yet

2 participants


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.

  1. The main array from the bower.json file doesn't list all the files you need to run the framework. The bootstrap-sass one lists only two files, bootstrap.scss and bootstrap.js, which doesn't include the many partials you need, nor the js for the widgets, nor the fonts (curiously, the bower.json.main for the Less version does include the fonts). I wonder if other packages will likewise fail to list essential components needed for build. For bootstrap-sass, you need pretty much all the files in the fonts, javascripts, and stylesheets directories
  2. You may, in fact, want to exclude files in the main list. In this case, bootstrap.scss will compile the partials to a css file which Meteor will dutifully add to the build, but to use Sass, you would want to avoid that and @import this file from a master file so you can change Sass variables (or skip it and just @import the partials yourself). Also, this file is included in two places. Meteor's automatic behaviors are working against us here.

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):

"bower": {
  "twbs-bootstrap-sass": {
    "version": "3.1.1", 
    "include": ["stylesheets/*", "javascripts/*", "fonts/*"],
    "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.

@mquandalle mquandalle added the design label Mar 12, 2014

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:

Manager Client Server

Why not create an atmosphere package that will:

  • rely on the NPM sass package for the compilation
  • include the bootstrap-sass repository as a git submodule
  • manually add js and assets with the package.js API

BTW it's not possible (yet?) to include in the bundle a scss, a coffee or even a html file. The current API allows only: addJavascript, addStylesheet and addAsset see here.

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. :-)

@mquandalle mquandalle added the wontfix label Mar 13, 2014
@mquandalle mquandalle closed this Mar 13, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment