Roadmap #145

Closed
sindresorhus opened this Issue Nov 18, 2012 · 16 comments

Comments

Projects
None yet
@sindresorhus
Member

sindresorhus commented Nov 18, 2012

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

What would you like to see?

@josh

This comment has been minimized.

Show comment Hide comment
@josh

josh Nov 19, 2012

Contributor
  • 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".
Contributor

josh commented Nov 19, 2012

  • 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".
@blittle

This comment has been minimized.

Show comment Hide comment
@blittle

blittle Nov 19, 2012

  • Stricter component registry rules #53 with preregistration checks.

blittle commented Nov 19, 2012

  • Stricter component registry rules #53 with preregistration checks.
@paulirish

This comment has been minimized.

Show comment Hide comment
@paulirish

paulirish Nov 19, 2012

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)
Member

paulirish commented Nov 19, 2012

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)
@matthewrobb

This comment has been minimized.

Show comment Hide comment
@matthewrobb

matthewrobb Nov 19, 2012

Something similar to npm link that makes using local dependencies easier
Done

Something similar to npm link that makes using local dependencies easier
Done

@sindresorhus

This comment has been minimized.

Show comment Hide comment
@sindresorhus

sindresorhus Nov 19, 2012

Member
  • authentication
Member

sindresorhus commented Nov 19, 2012

  • authentication
@necolas

This comment has been minimized.

Show comment Hide comment
@necolas

necolas Nov 19, 2012

Contributor

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.

Contributor

necolas commented Nov 19, 2012

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.

@desandro

This comment has been minimized.

Show comment Hide comment
@desandro

desandro Nov 20, 2012

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)
Member

desandro commented Nov 20, 2012

  • 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)
@necolas

This comment has been minimized.

Show comment Hide comment
@necolas

necolas Nov 20, 2012

Contributor

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.

Contributor

necolas commented Nov 20, 2012

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.

@paulmillr

This comment has been minimized.

Show comment Hide comment
@paulmillr

paulmillr Nov 20, 2012

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.

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.

@frontdevde

This comment has been minimized.

Show comment Hide comment
@frontdevde

frontdevde Nov 22, 2012

  • bower option to rename component by "name" and "version" if you fetch the latest version e.g. less-1.3.1.js
  • 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

Closed

Specification #110

@milesmatthias

This comment has been minimized.

Show comment Hide comment
@milesmatthias

milesmatthias Nov 24, 2012

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.

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.

@robdodson

This comment has been minimized.

Show comment Hide comment
@robdodson

robdodson Nov 26, 2012

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.

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.

@khepin

This comment has been minimized.

Show comment Hide comment
@khepin

khepin Jan 12, 2013

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 commented Jan 12, 2013

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'
    }
}
@yatskevich

This comment has been minimized.

Show comment Hide comment
@yatskevich

yatskevich Jan 12, 2013

@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, 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.

@Munter

This comment has been minimized.

Show comment Hide comment
@Munter

Munter Jan 13, 2013

@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?

Munter commented Jan 13, 2013

@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

Closed

Include compiled JS in repo for bower #1333

@satazor

This comment has been minimized.

Show comment Hide comment
@satazor

satazor Aug 4, 2013

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.

Member

satazor commented Aug 4, 2013

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