bower.json not including css file in main

[ezraroi]

Tools like Wiredep stopped working with bootstrap after the change in last version.

[Johann-S]

It's due to this Pull request : #16359

But you have to check the new bower specs bower/spec#43

[ezraroi]

yes I saw this.
But looks like the bootstrap bower.json file should provide a solution for the css file.
I don;t see a reason why not to include it

[kkirsche]

I'm not sure I fully understand, so if I am wrong I apologize. But I think we should not do anything that is not directly from / for the spec. Anything else is up to the author because they chose to depend on third party libraries. We should not, in my opinion, be held responsible for fixing third-party functionality due to a different third party changing their spec. Our only goal is to follow the spec provided by the third party. I would recommend creating an issue with wiredep to adjust their behavior to use the new spec

[mdo]

Should we say fuck the spec and do this? I didn't think about it much when I saw the PR—spec is spec—but this actually might fuck up a lot of folks. Thoughts @cvrebert?

[mlakmal]

since .css reference is removed from main, wiredep is not able to identify if bootstrap has any css files to be injected into automated bower:css section ... this will break angular apps for lot of folks using bootstrap with yeoman scaffolding since yeoman uses this setup by default ...

i reverted bootstrap version to 3.3.1 for our project to build successfully until i identify a solution for this ...

[redysanin]

Even we also face same issue in bootstrap 3.3.5 . at grunt serve it remove
"bower_components/bootstrap/dist/css/bootstrap.css"
It look like they remove "dist/css/bootstrap.css" from bower_components\bootstrap\bower.json

We fix this issue temporary by overrides our project bower.json. for us it work fine. but waiting for some solution from bootstrap.

 "overrides":{
    "bootstrap" : {
         "main": [
            "less/bootstrap.less",
            "dist/css/bootstrap.css",
            "dist/js/bootstrap.js"
          ]
    }
  }

[mlakmal]

I was trying out that override, that seems to do the trick. as long as we can override, this shouldn't be a issue on bootstrap side ...

[kkirsche]

My personal preference is to follow the spec rather than to modify the bower file Bootstrap provides. My belief is that that as new bower projects are made and as other projects migrate to the latest spec this issue will crop up there as well. Us patching it while potentially solving this issue for users of Bootstrap, doesn't prevent the same issue with other repos thus making me believe the issue should be addressed by the package(s) which use this data, not by the package maintainers.

(Note: @redysanin use a backtick (`) for inline code, three backticks with a language name or 4 space indentation to begin it be a code block. Documentation on code blocks)

[ezraroi]

From what I understand from the spec, it is one file per type, so I can have one js file and one css file?

[ezraroi]

Issue from the bower project:
bower/spec#43 (comment)

[karthilxg]

Reverting to bootstrap version 3.3.2 also works fine..

The bootstrap bower file differences between the version,

bootstrap 3.3.5

"main": [
    "less/bootstrap.less",
    "dist/js/bootstrap.js"
  ] 

bootstrap 3.3.2

"main": [
    "less/bootstrap.less",
    "dist/css/bootstrap.css",
    "dist/js/bootstrap.js",
    "dist/fonts/glyphicons-halflings-regular.eot",
    "dist/fonts/glyphicons-halflings-regular.svg",
    "dist/fonts/glyphicons-halflings-regular.ttf",
    "dist/fonts/glyphicons-halflings-regular.woff"
  ]

[ezraroi]

Yes, but we want to be able to use the last versions.

[karthilxg]

@ezraroi Try overriding option suggested by @redysanin as a temp fix.

   "overrides":{
      "bootstrap":{
         "main":[
            "less/bootstrap.less",
            "dist/css/bootstrap.css",
            "dist/js/bootstrap.js"
         ]
      }
   }

[cvrebert]

From what I understand from the spec, it is one file per type, so I can have one js file and one css file?

@ezraroi The issue isn't JavaScript and CSS. The issue is CSS and Less/Sass. Per the spec:

Use source files with module exports and imports over pre-built distribution files.

In other words, in the case of stylesheets specifically: main should include the Less/Sass source code, NOT the prebuilt CSS. I specifically sought clarity about this from the Bower devs in bower/spec#43 , and the example in the spec backs this up by including sass/motion.scss and NOT movement.css in its main.

[cvrebert]

@mdo Please god no. After over a year and a half of discussion upstream, and months of prodding the Bower devs into taking action, we finally have a proper spec; let's stick to it now that it exists. The very concept of specs is pointless otherwise. Down the path of deliberately disobeying the written spec in favor of ad-hoc shit folks just make up lies chaos and sadness.
Several other major projects have agreed to go along with the main spec change (foundation/foundation-sites#6525, zurb/foundation-apps#607, Semantic-Org/Semantic-UI#2244, videojs/video.js#2145, select2/select2#3350), and the tooling projects were consulted in bower/spec#43 and didn't raise an objection.
So it's reasonable to expect the tools to change, and there is/will-be pressure on the tools to change since we have major projects onboard, it will just take some time. There will be some pain during the transition period; I personally believe this is worth enduring in order to help bring sanity to Bower long-term.

Is the situation perfect? Of course not. Ideally, Bower ought to offer sufficient metadata to allow its users to use precompiled CSS (or JS for that matter) when packages like Bootstrap offer it. Or else it should explicitly narrow its scope to "Bower assumes that its users will use build tools (including Less/Sass/Stylus/PostCSS/etc. compilers)". But that's squarely a problem for Bower's developers and community to work out; I don't think it's Bootstrap's job to try to tackle that ourselves, other than to comply with future updates to the bower.json spec. We have quite enough work on our plate as it is.
It's high time for wiredep et al. and the Bower project to sit down and hash out how fonts, images, and precompiled CSS ought to work in bower.json now that they're definitively excluded from main. The Bower devs acknowledged the likely need for such additional fields when discussing the new main spec.

To folks interested in improving the situation, I suggest lobbying/discussing/pull-requesting the Bower project for something like bower/spec#21 (as a starting point).

(P.S. I apologize for the vitriol, but Bower's shittiness and lack of progress in addressing its shortcomings on a reasonable timescale has caused me much angst.)

[alber70g]

I'd like to add that here is mentioned that you can also add the css. But that's before the spec changed.: bower/spec#36 (comment)

@mdo +1 fuck the spec

@cvrebert and others:
I believe the bower.json's main should provide the entry point for using it as library, not as source. If you want the source (less/scss/ts/etc), you should git clone the repository and do it all yourself.

As an example: I'm not referencing a .dll or nuget package to get the source of it in my project, and slowing down the compilation and with that the development process. I reference the library to use it, not to compile it or do some implicit charity for it

[mdo]

It sucks that the Bower spec is just now getting some definition, but until the dust settles, I'm good keeping us within what little definition we have thus far. We'll stick with the spec and not add the compiled CSS dist files, nor font files.

Sorry if this fucks up your day as a Bootstrap user, but I suggest taking any feedback to the Bower folks so they can appropriately act on it for the entire Bower community.

[danielstankiewicz]

I agree that we should be able to use it as a library, not as source. My app just got broken because of 3.3.5 version. Falling back to 3.3.4. And I personally think that last number version change shouldn't come with changes that impact users so much.

[kkirsche]

The change itself is a package manager change and subject to their choices not bootstrap. Use and dependence on any package manager comes with risks. The core library has not had any breaking changes in the last release, my recommendation would be to raise your concern with bower as we are simply following their spec.

[s12chung]

any complaints about the spec should go up to bower---web standards are incongruent enough already.

at the same time, could you upgrade the version to a major upgrade? following http://semver.org.

and maybe make an upgrade note. (i still haven't figured out how to upgrade yet)

[ThisGuyCodes]

I understand deciding to conform to the spec right away, but this should still be considered a breaking change, this shouldn't have been a point release, but 4.0 instead.

[kkirsche]

That's fair, and I can understand it, though I don't agree with it. I appreciate the input, and believe conversations like this are the only way to ensure the community as a whole is the best it can be and serves the most people. Simply on this subject I happen to disagree with many others — simply put, I look at this at this point as an agree to disagree situation. I wanted to ensure though that it was and is clear that at this time I speak only for myself and if I was representing the project as a team member I probably would not be vocal on this subject as I wouldn't feel I have the authority to address this issue in the way it would need to be addressed. I feel the owners of the project would need to make the final call, not a general member or contributor due to the controversial nature of this change.

Hope that makes sense and we can agree to disagree with no hard feelings. 😃

[cvrebert]

@s12chung You make a good point; I'll see about adding the bower.json change to the 3.3.5 blog post summary and try to add some upgrade guidance for those unfortunate wiredep users.

[s12chung]

thanks @cvrebert! it would be very helpful :)

[alber70g]

Yea... fuck the developers, the hundreds of thousands of developers who are dependent on generators, package managers, and other third-party tools:

#we have a spec... so we will screw the people who actually need it

Every single webapplication using automatic updates for 'minor' NON API-BREAKING releases will break now due to this 'following the spec'

[desandro]

I've proposed a new bower.json field files to help address this issue: bower/spec#47. Would love to get Bootstrap team's input on what would work best for the BS projects.

[cvrebert]

@desandro Thanks! Gave my 2¢.
CC: @twbs/team: bower/spec#47

[cvrebert]

@s12chung Added more info & a workaround to the v3.3.5 release blog post:

• http://blog.getbootstrap.com/2015/06/15/bootstrap-3-3-5-released/#wiredep-and-bower
• twbs/blog@a77062f...67e0834
• https://twitter.com/getbootstrap/status/613081926157504512

[s12chung]

thanks for the note :)

[calidion]

confirm.
please release this fix asap, this problem is very urgent for those updated.

[cvrebert]

@calidion See #16663 (comment)