Does having a component.json file not prevent an entire repo from being downloaded? #45

jcreamer898 opened this Issue Sep 14, 2012 · 30 comments


None yet

Is there proper way to setup a bower install to use it with it's OWN repo?

I was thinking that by merely including a component.json file in a repo that when running bower install, it would only actually install the things listed under main into my project.

But, it downloaded my entire github repository?

Is this the expected behavior, or did I do something wrong?

The package I uploaded is postal.


I also thought it would only download the main files which in my opinion it should. I don't want to have to manage the mere 6Mb of Bootstrap's repos, I just want the final .css and .js files.


fat commented Sep 16, 2012

this is expected behavior. we have to do this because your main file could be importing other files in your repo.

@fat fat closed this Sep 16, 2012

Is the entire repo supposed to be in the components directory?


fat commented Sep 16, 2012


I don't know a lot of repos that don't compile to a final .css/.js file. I don't find it very efficient to have to download Mb and Mb of files for a 50k file. Worse : having to upload that when syncing folders with an FTP.


Note that Bower does maintain a local cache and copies from there, so you will generally take a hit on the first install, and then subsequent hits will be updating the git repo... but still, totally inefficient at the moment. I think the implementation needs to go back to the drawing board on this particular point.

sapegin commented Sep 19, 2012


If some projects have files that can be imported from main files, they should be listed in component.json.


From our perspective in appendTo, this is a major issue that I'd love to see at least some direction and response to. Bower is a fantastic idea, but this presents a jarring experience to the normal developer workflow and presents an awesome opportunity for Bower to improve things.


satazor commented Oct 8, 2012

@Anahkiasen There is a lot of repos that don't compile to a final js file. Some examples are libraries implemented in AMD. In those cases, cloning the whole repo makes sense because it would be painful to maintain the "main" array with all the files of those repos since amd promotes code to be granular.

Though I agree that this could be improved with something similar to npmignore, which adds the ability to ignore files. At least users would have the ability to tell bower which files to ignore (e.g.: tests, etc).

/cc @fat

jhnlsn commented Oct 9, 2012

The oposite of #88 could be suggested such that a consumables directive could be defined. Meaning that I could define which parts of my repo are consumable by others etc. The problem is that right now some repo's in bower don't even have consumable assets such as knockout or twitter bootstrap for that matter. This problem pretty much makes bower about as useful as git and no more since I can just git link other repos into my project exactly the same.

I understand that bower is trying to get out of the way and be low level, but it doesn't need to be as low level as git.. it should at least provide some structure IMO.


satazor commented Oct 10, 2012

@johnymonster You can achieve the same thing with ignore anyway:


Would ignore all files except the ones in the dist folder

The thing I have trouble understanding unless I am missing something is, what is the point of the component.json file if the whole repo is downloaded anyways?


satazor commented Oct 10, 2012

@jcreamer898 Mainly to specify deps

and to specify the main file for build scripts

+1 Agreed I am confused about the idea behind bower is if you just pull down git repos to your project. The only one that is not pulling the entire repo is jquery but that is only because someone made a shim repo for it.

+1 If you are using CI the size of the artifacts can skyrocket on bigger projects (+50MB) and managing becomes a pain (i.e.: keeping in mind to exclude certain parts of a project). Example: in order to zip everything into a small package you have exclude the 'lib' folder and re-run bower install on every target environment you are deploying to. This increases running time where quick feedback is crucial and also prone to networks issues (i.e.: github is slow or down) which can lead to a broken pipeline. It would be so much nicer if you could define the relevant, "exportable" files in your component.js and get rid of the 7MB+ tests in RequireJS for example.


kcm commented Nov 5, 2013


eirikhm commented Dec 12, 2013


+1 .. just for the sake of a file you are downloading entire repo .... just sounds silly ...

The twbs/bootsrap repository is now 43Mb big. It takes an eternity to get on Bower. Still no planned solution for this ?

It is actually now possible to ignore things w/ the bower.json file...

  "name": "bootstrap",
  "version": "3.0.3",
  "main": [
  "ignore": [
  "dependencies": {
    "jquery": ">= 1.9.0"

The ignore property in the bower.json will cause those files to be ignored now. I just did...

bower install bootstrap

And the folder size was only 728KB.

phun-ky commented Jan 28, 2014

Tbh, all bower component providers should provide a shim/minified file(s) of the component, it's overkill and redundant to download an entire repo just for one minified file. And yes, since most of the bower components are open source, you can fork it and create your own shim package, but it's time consuming and counter-productive, since the shim provider have to maintain several repos/components..

So how can we (the developers of frontend applications) persuade the providers to do this without thousands of developers nagging some providers again and again?


benschwarz commented Jan 28, 2014

This is being covered by the new registry, you've just gotta sit tight.
Otherwise, if you've got some spare cycles, we'd love your help over on the bower/registry node_rewrite branch

Been sitting tight for ~1.5 years, now my butt hurts. :) Jk, but I am curious if any progress has been made?

Does help you. I use this to pull in about 20 different projects. I end up with a directory containing only the files I want (.js, .less) and from there, I use grunt to package them all up into a single js and css file. YMMV.

It took a bit to get the config correct, but eventually got bower-installer to work for my case (for the most part).

However, there are parts of bower-installer that feels like a "one size fits all" type of solution which doesn't work for every repo.

For example, you can define certain files go to certain paths "png": "path/to/img"which works for the projects that have statics referencing the same folder structure, but unfortunately not all css files reference an image folder called "img" at the exact same relative path.

I know you can use glob wildcards on folders to maintain folder structure, but mixing and matching glob wildcards with path default directories didn't seem to jive well (hence the one size fits all comment). For that reason I had to still end up taking a few repos in their entirety.

It would still love to see enhancements to native bower to address some of this.

FWIW, I'm using Django and static files management with django-pipeline.

@troygrosfield, I do have an issue with bower-installer, but for the main, it works well. The one-size-fits-all is close, but/and you can/do need to tweak things a bit. Similar to composer.json in some ways.

But neither bower nor composer handles the things that bower-installer does, and I've raised that issue with composer too.

+1 Installing the entire repository instead of what's specified in main seems counter intuitive to me.

sheerun added a commit that referenced this issue Jun 10, 2016

Merge pull request #45 from paulohp/grunt-travis
added grunt travis script to .travis.yml
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment