Bower: After installing, not automatically insert link of CSS in index.html

[adrianoresende]

Insert this comment after favicon.ico

<!-- build:css(.) styles/vendor.css -->
<!-- bower:css -->
<!-- endbower -->
<!-- endbuild -->

[Swiip]

In fact, I've willingly removed this code recently.

Indeed, we don't want css insertion in most of the cases because the imports are made through the pre processor.

More, the bower configuration of the frameworks for the css files are frequently incomplete so this feature ended up with more problems than benefits.

The upcoming 0.5 version changes quite the css bundleling I hope for the best. But I still didn't use the bower injection of css links.

[marani]

jQuery plugins like perfect-scrollbar actually has some css dependencies, and I did successfully use wiredep to wire up third party css. I think there will be more cases like these (jQuery plugins & some older libraries which happen to not use sass or less), so I think keeping css injection wouldn't be a bad idea.

Btw, great work so far! I am doing quite a big project based on this generator. Keep it up!

[Swiip]

It's a tough call. It brings confusion in many cases but can still be useful... Don't know what I'll doing right now.

[marani]

Personally I found the main trouble is in wiredep, it assumes many things we don't expect, and the vendor's bower.json files aren't always complete.

Take Angular UI for example, if we just want a subset of the directives, wiredep will make it difficult.

Another time, when I commented out a vendor script, put it out of the build block (even out of html tag), then I forgot about it (as it should be just a comment, and because I was trying with other equivalent libs).
Few days later, I see the script is missing, I check with my bower.json, the library is clearly included, but wiredep doesn't want inject it back for me. Then I realize the script inside that comment block I made earlier is actually preventing wiredep from injecting it 'again' to the build block, remove that comment, things work fine. Now that might be a feature, but it's quite unexpected.

If we just include manually what we want, it would be more flexible, so I actually removed wiredep after scaffolding the project.

[Swiip]

You perfectly sum up the situation. At first, I didn't want of wiredep, I didn't want that something mess up with my index.html. Then, I seen it appear in several generators and I began feeling like the old-school-afraid-of-change guy so I took it.

But it's still complicated and disturbing, even more with the style dependencies which depends on your preprocessors.

I'm pretty sure that whatever the decision I take, there will be complaints. And transform this in an generator option would be really complex.

Perhaps, the best solution is to wait to handle script loader and the question will be very different...

[marani]

Overall, wiredep doesn't seem to affect much on other parts of build system, as what I did is just remove wiredep task & remove it from other tasks that depend on it, then things worked just fine. I did it quite recently, which means even when I changed a lot of everything else, then remove wiredep, nothing broken.

If people are ok with wiredep then that's totally fine, I wouldn't complain. I would just silently remove wiredep after scaffolding, because that's not too difficult. haha..

Adding a generator option might make people who are unfamiliar with wiredep rather confused. just make the decision before the user knows it is good or bad for them (the Apple's way :D).

So actually for now I think keeping wiredep there is a better choice. Just if one day in the future there are more people complaining about wiredep, removing it at that time is not too late, and I could help you on that if needed.

[Swiip]

I end up with the same conclusions. I restored wiredep for css.

I'll reconsider all of it when (and if) I start working on the script loaders.