Roadmap #145

sindresorhus opened this Issue Nov 18, 2012 · 16 comments
Bower member

We need to come up with a roadmap of how we would like Bower 1.0 to be.

What would you like to see?

  • Ignoring unrelated files #88
  • Improve situation for components with many files and optional subfiles. Bootstrap, Modernizer, and others. Its not clear how yeoman and sprockets should be dealing with files outside of those declared in "main".
  • Stricter component registry rules #53 with preregistration checks.
Bower member

Some may be 1.0 and some before. These have come up from discussions amongst Yeoman devs :

  • compatibility with component(1)'s component.json
  • Detailed component.json specification #110: cdn field (#19), description field (#49), devDependencies (#80), main field (#46)
  • Validation
  • Port server to Node
  • Bower ignore file (e.g ignore tests)
  • Registry: validate existing packages / kill off those that don’t pass
  • faster registry (sponsorship for larger heroku plan)
  • postinstall script
  • make community maintenance of maintaing repos easier (accept a PR, bump # in the json, manually add git tag)

Something similar to npm link that makes using local dependencies easier

Bower member
  • authentication
Bower member

make community maintenance of maintaing repos easier (accept a PR, bump # in the json, manually add git tag)

Not sure this something for bower to care about though. Unless I've misunderstood, if you want people to reference fixed, known, stable versions then you need to manually add tags when appropriate. Having this happen automatically sounds like the territory of a GitHub UI feature.

Bower member
  • Component authoring specification or guide. Sounds like we want components to be pre-built, ready to use after bower install. What other stuff do we want or not want in the package?
  • @josh's above items
  • @paulirish's first two items
  • Use bower.json. Remove legacy support for component.json #39. I think this is fair for a 1.0 release.
  • Tutorial video on developing with Bower (would be nice).
  • Branding / possible logo (My bad. I should have rocked this the first time, but I didn't get bower)
Bower member

We should have use cases for anything that doesn't already have some listed, otherwise we just scope out features without a clear reason for their existence or their value.

I'm not sure about having compiled versions of packages in the package repo itself. Since the compiled version can be derived from the repo contents, that could be handled by a post-install script. IMO, we should be careful of anything that places requirements on the contents of packages other than that they contain a valid package config.


Use bower.json. Remove legacy support for component.json #39. I think this is fair for a 1.0 release.


component(1) json files are very nice.

  • bower option to rename component by "name" and "version" if you fetch the latest version e.g. less-1.3.1.js
@davetayls davetayls referenced this issue Nov 23, 2012

Specification #110


Perhaps this is outside the scope of what bower should be, but for beginners I would love to see curated, best-practices "groups" or "packages". So, 'bower install responsive-design' would install the most-used grid system and the most used templating system, etc. Like I said, maybe that's not right for Bower, but my beef with any package manager has always been discovery and how incorporating the industry's best practices into which packages you use to build something works. Maybe this should just be a repo I create to document and encourage people to document on.


A private attribute, similar to npm modules, would be a nice addition. We're using a few bower projects on private repos and don't want folks to accidentally publish.


Declare assets and a path for assets to be copied to.

Eg: when installing select2, there is a default stylesheet, and a png picture. I need to export these files during my build process. So I'd like to have the picture copied to my "/img" folder, and the css to my "/css" folder so that I don't have to worry about them at all.

Would be nice to have an entry in bower config to declare this

    // Normal bower config
    // ...

    assets: {
        css: '/my/css/folder/',
        img: '/my/pictures/folder'

@khepin, take a look at Bower task for Grunt. This grunt task does what you want. The only difference that you declare the mappings (e.g. pictures to '/img', stylesheets to '/css') in components.json of your project.


@khepin I think it's a bad idea to have a packages assets be copied into your project. The ability to debug gets killed completely when every asset from every package is just in one single folder.

I'm betting that the reason for your suggestion is that you want to run a build system on all assets at some point.
If so, isn't the solution to have your build system be able to refer to assets no matter where they are?

@kenearley kenearley referenced this issue in harvesthq/chosen Jul 17, 2013

Include compiled JS in repo for bower #1333

Bower member

Bower 1.0.0 was released and most of the things posted here are already implemented. Others are split over multiple issues. Closing this and will re-open if necessary.

@satazor satazor closed this Aug 4, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment