Closed recipher closed 10 years ago
There's an unofficial port at https://github.com/jlong/sass-bootstrap which has a working install, apart from one detail, which I guess is a separate bug.
All partials and bootstrap.scss are in the lib folder. So, broccoli can find the files without any extra work.
However, the one issue with that port is the bower.json file has a wildcard in the main property which broccoli chokes on:
"main": ["./dist/js/bootstrap.js", "./dist/css/bootstrap.css", "./dist/fonts/*"]
Error: ENOENT, no such file or directory 'bower_components/sass-bootstrap/dist/fonts/*'
https://github.com/jlong/sass-bootstrap/blob/master/bower.json
This is the bootstrap-sass / libsass incompatibility issue:
https://github.com/hcatlin/libsass/issues/231
Which seems to be fixed in libsass#master but node-sass is using the last released version (I think).
So both (1) and (2) above are libsass issues, correct?
Is there anything that should be fixed on this repo?
However, the one issue with that port is the bower.json file has a wildcard in the main property which broccoli chokes on
Wildcards aren't mentioned in the bower.json spec. I'm not sure that it should be supported at all.
In general, Broccoli's bower support is relying on some nasty heuristics at the moment, including the "main" property. It's assuming semantics that are not specced at all. This will have to go away and/or be reworked, and we'll have to coordinate with the bower folks as well.
Hi. Is it worth catching the * wildcard and ignoring it, or logging a warning for the timebeing? If the wildcard was specced, then I guess it'd have to be supported, but if it's not, I guess it can be ignored for now?
So, I think (part of) 1) and 2) and related to the general bower support issues.
So, bower.json "main" references a file which then references a bunch of other files which aren't also referenced by "main". So, how does broccoli-sass/libsass know about them (automatically). In this instance, I'm working around it by just adding the tree directly. I guess that's the only way, right?
Otherwise, yes, the compile issues are libsass (or bootstrap-sass) specific. Unfortunately, I think they are fixed but node-sass isn't pointing at the latest libsass, which doesn't appear to have a solid versioning strategy yet.
So, bower.json "main" references a file which then references a bunch of other files which aren't also referenced by "main". So, how does broccoli-sass/libsass know about them (automatically).
At the moment, it doesn't. The containing directory would be the natural place to look, but it seems to me that adding the entire containing directory hierarchy isn't always desirable.
The proper way I guess would be something along the lines of mainDir: "lib"
in bower.json. At the moment there's no way to infer the lib
dir. We'll have to have a conversation about adding something like mainDir
to the spec, eventually.
Unfortunately, I think they are fixed but node-sass isn't pointing at the latest libsass, which doesn't appear to have a solid versioning strategy yet.
Maybe ping Aaron about cutting more frequent releases?
Reading the libsass issues log, I think they are working on a versioning strategy. I think node-sass just needs to update the commit it is pointing to to pick up the latest fixes. I'll ping the node-sass maintainer.
I'm travelling down from Scotland for Ember London tomorrow, I'll say hello.
Oh cool, looking forward to meeting you in person tomorrow!
Semantic UI also has wildcards in its bower.json main.
https://github.com/Semantic-Org/Semantic-UI/blob/master/bower.json
I've had to fork it to get it to build on my server. I had a look at ignoring wildcards in the code (in kitchen-sink-helpers), but it broke some other code.
Just adding a +1 here because I'm experiencing a similar issue.
Re wildcards in bower.json
, the newly-extracted broccoli-bower is now throwing more descriptive errors when it encounters wildcards, as of broccoli-bower 0.2.0. We can revisit this once we actually make a proper spec for these kinds of things. The main
thing is woefully deficient for our purposes and needs to be replaced with something more expressive anyway.
Also see this warning for broccoli-bower.
I believe this can be closed. If there is anything else I'm missing that we should track, let me know and I'll reopen.
I'm having this issue too, after upgrading ember-cli from 0.23 to 0.25. Used Bower to install 'bootstrap-sass-official', and now getting this error:
tmp/tree_merger-tmp_dest_dir-WQFPpFpA.tmp/bootstrap:2: error: file to import not found or unreadable: "bootstrap/variables"
...when I:
@import "bootstrap";
...from app.scss:
Is there a way to fix this? Thanks!
I'm not sure; I'd recommend avoiding broccoli-bower for now. It really is pre-alpha.
Ok, will do. Thank you!
I managed to get this working and wrote it up on my blog : http://www.octolabs.com/blogs/octoblog/2014/05/08/ember-cli-broccoli-bootstrap-sass/
Just figured I should leave a link for anybody else who lands here.
:) thanks.— Johnny H 07971 880871
On Fri, May 9, 2014 at 2:09 AM, Jeremy Green notifications@github.com wrote:
I managed to get this working and wrote it up on my blog : http://www.octolabs.com/blogs/octoblog/2014/05/08/ember-cli-broccoli-bootstrap-sass/
Just figured I should leave a link for anybody else who lands here.
Reply to this email directly or view it on GitHub: https://github.com/joliss/broccoli-sass/issues/3#issuecomment-42624509
There are 2 scenarios which can be used when @import-ing bootstrap-sass files:
1)
@import 'bootstrap';
Will @import the main scss file (which is listed in bower.main). This, in turn @import-s all the partials contained in the
bootstrap/
directory. This is done like thisWhere the file is in
./bootstrap/_normalize.scss
.At the moment, broccoli-sass finds the main bootstrap.scss file, but can't find the partials, resulting in:
2) Allow @import-ing of the bootstrap partials directly from sass files. Again, the same error is produced.
I have a workaround which is to directly include the tree into the sourceTrees when compiling:
However, interestingly, that seems to throw up some compile errors in some of the partials.
Which is either an issue with bootstrap-sass or libsass, I haven't worked out yet. And obviously, unrelated to this.