Bower packages

[0x-r4bbit]

Hey @ebidel ! How about putting all these great elements in separate packages so one can install them easy via bower?

I know, this is all in pretty alpha state, but I would also like to build some polymer components and it would be great if I can install dependencies (polymer-ajax/polymehr-xhr e.g.) á la bower install.

What do you think?

[ebidel]

This is something we (all) really want but I think breaking each element up into a repo is unreasonable. I can imagine a day where UI component vendors have their list of components in a single repo. It's unlikely they'll break them up because of testing, maintainability, etc.

IMO, Bower needs get smarter here. One idea I had was to be able to install paths of a repo (e.g bower install polymer-elements/polymer-xhr). That's currently not something it supports, but one could put a wrapper around Bower/grunt that does the trick.

@addyosmani is investigating this very thing as we speak!

[0x-r4bbit]

@ebidel Yea.. maintainability is a good point. At angular-ui, we also split up ui components into separate repositories. I thought it could also be good thing here. However.

I'm totally with you when saying that bower needs to get smarter here. Is there any kind of workaround for this? How do you install specifc polymer-elements?

[ebidel]

You checkout the entire repo. Definitely not ideal, but we don't have anything better today. Like I said, Addy and I are exploring this atm. The current thinking is to create a yeoman/grunt wrapper around bower install. You install the entire polymer-element rep (as usual). The wrapper then filters out the component you specify by path and removes the rest.

WIP tooling: https://github.com/addyosmani/polymer-grunt-example (doesn't include the install part yet)

As for adding such filtering to Bower proper, @addyosmani would know more about their plans.

[0x-r4bbit]

All right, thanks

On Tue, Jul 30, 2013 at 6:47 PM, Eric Bidelman notifications@github.comwrote:

You checkout the entire repo. Definitely not ideal, but we don't have anything better today. Like I said, Addy and I are exploring this atm. The current thinking is to create a yeoman/grunt wrapper around bower install. You install the entire polymer-element rep (as usual). The wrapper then filters out the component you specify by path and removes the rest.

WIP tooling: https://github.com/addyosmani/polymer-grunt-example (doesn't include the install part yet)

As for adding such filtering to Bower proper, @addyosmanihttps://github.com/addyosmaniwould know more about their plans.

— Reply to this email directly or view it on GitHubhttps://github.com/Polymer/polymer-elements/issues/14#issuecomment-21804873 .

/pp

[addyosmani]

As Eric mentioned, we're currently evaluating the best strategy for how to use Bower with Polymer elements. Today, Bower has a good story for UI library authors that want to be able to host all of their elements in individual repositories under an organization. This may not be the best idea. Think of something like Bootstrap, which wants to easily let developers grab all of the components available at once - we want to support both that - e.g:

bower install polymer-ui-elements

but also those that would prefer something more a la carte:

bower install polymer-ui-elements polymer-carousel
bower install polymer-ui-elements polymer-carousel polymer-video-player

We're going to work with the Bower team to evaluate whether the second of these use-cases is something that might be natively supported by it in the near future. If not, we plan to support this use case using other tooling, for example Yeoman + Grunt. In this scenario you could probably imagine creating your new Polymer component or app using a Polymer generator:

yo polyer image-gallery

... answer a few questions..now let's install some components..

grunt install polymer-carousel

Where install is basically just a specialized Grunt build task/profile that fetches you just what you need. How it does this is yet TBD. It could pre-install the entire polymer-ui-elements package and only copy over those components you specifically request or something else.

cc @sindresorhus who may have more insights on bleeding-edge Bower capabilities.

[sindresorhus]

but also those that would prefer something more a la carte:

Bower has always supported multiple arguments with install.

But you still have to have multiple repos with each of those components. That's not going to change. However, this is the main reason we've decided to support a publishing step ala npm publish. Angular has the same need.

Though I still think separating it out into multiple repos is a good thing. You could then have a main repo with everything as submodules and a folder with a built version for the lazy crowd.

[ebidel]

What is the team's opposition to supporting paths as well as repos? I always thought it was odd that bower got me everything rather than what I specify. Maybe I just want the jquery.min.js from their build folder.

The submodule idea would definitely work but it quickly becomes impractical and tedious. UI vendors with hundreds of widgets won't want the headache of individual repos and creating an aggregate. We've already experienced a bit of this repo overload within polymer.

Can you explain the publishing step more? On Aug 3, 2013 10:12 AM, "Sindre Sorhus" notifications@github.com wrote:

but also those that would prefer something more a la carte:

Bower has always supported multiple arguments with install.

But you still have to have multiple repos with each of those components. That's not going to change. However, this is the main reason we've decided to support a publishing step ala npm publish. Angular has the same need.

Though I still think separating it out into multiple repos is a good thing. You could then have a main repo with everything as submodules and a folder with a built version for the lazy crowd.

— Reply to this email directly or view it on GitHubhttps://github.com/Polymer/polymer-elements/issues/14#issuecomment-22057995 .

[sindresorhus]

What is the team's opposition to supporting paths as well as repos? I always thought it was odd that bower got me everything rather than what I specify. Maybe I just want the jquery.min.js from their build folder.

You can install an url directly with bower install http://..., but you can't register it in the registry.

Can you explain the publishing step more?

It will be pretty much like npm publish. You publish the package to the registry instead of referencing the repo. That way you can have multiple Bower packages in one repo. @danheberden can probably expand more.

[addyosmani]

We recently discussed this topic again. The npm style of publishing model will solve what we're after long-term. It's important to get right as it appears that Mozilla have opted for a multi-repo setup for their components and we ideally want to be able to start using bower for elements eventually.

Short-term, if we want - I can implement a solution for installing individual elements/packages from a single repo as part of a grunt task. This would be an extension of https://github.com/stephenplusplus/grunt-bower-install.

@sjmiles do we have a feel for whether this is a problem Polymer would like a solution to in the next month or two?

[sindresorhus]

Short-term, if we want - I can implement a solution for installing individual elements/packages from a single repo as part of a grunt task.

I don't see why it should be a grunt task. A vanilla node small CLI app or a generator would be a much better fit.

[ebidel]

A new CLI app begs the question: again, why not bake the functionality directly into Bower? You'd essentially be creating a new tool that does 90% of the same thing.

On Thu, Aug 22, 2013 at 10:43 AM, Sindre Sorhus notifications@github.comwrote:

Short-term, if we want - I can implement a solution for installing individual elements/packages from a single repo as part of a grunt task.

I don't see why it should be a grunt task. A vanilla node small CLI app or a generator would be a much better fit.

— Reply to this email directly or view it on GitHubhttps://github.com/Polymer/polymer-elements/issues/14#issuecomment-23110846 .

[0x-r4bbit]

@ebidel agreed On Aug 22, 2013 9:21 PM, "Eric Bidelman" notifications@github.com wrote:

A new CLI app begs the question: again, why not bake the functionality directly into Bower? You'd essentially be creating a new tool that does 90% of the same thing.

On Thu, Aug 22, 2013 at 10:43 AM, Sindre Sorhus notifications@github.comwrote:

Short-term, if we want - I can implement a solution for installing individual elements/packages from a single repo as part of a grunt task.

I don't see why it should be a grunt task. A vanilla node small CLI app or a generator would be a much better fit.

— Reply to this email directly or view it on GitHub< https://github.com/Polymer/polymer-elements/issues/14#issuecomment-23110846>

.

— Reply to this email directly or view it on GitHubhttps://github.com/Polymer/polymer-elements/issues/14#issuecomment-23115644 .

[sindresorhus]

@ebidel because the use case is a bit obscure and it will be solved much more elegantly in the future (with publishing).

Another solution would be using git subtree to push changes from the main repo into meta repos. This can be fairly easily automated.

[ebidel]

The use case is far from obscure. The very first time I used Bower, it was confusing that an entire repository was pulled into my app. If people use Bower to manage a jquery dependency, 99% of the time they don't want/need everything else.

I've never used git subtree, but I don't think that addresses the original concern: avoid extra meta repos in the future place. A typical developer might share 1-2 components, but vendors will be creating dozens of them. IMO, Bower becomes a less appealing (and viable) option for those folks creating the high quality UI widgets :\

Sounds like publishing is the future and a decent compromise. When will that be ready? In the meantime, we may have to develop a Grunt task.

On Thu, Aug 22, 2013 at 2:47 PM, Sindre Sorhus notifications@github.comwrote:

@ebidel https://github.com/ebidel because the use case is a bit obscure and it will be solved much more elegantly in the future (with publishing).

Another solution would be using git subtree to push changes from the main repo into meta repos. This can be fairly easily automated.

— Reply to this email directly or view it on GitHubhttps://github.com/Polymer/polymer-elements/issues/14#issuecomment-23128752 .

[dfreedm]

From my experience with git subtree, I wouldn't recommend it as a viable mechanism. A script like the one you're proposing would have to have all the repo urls hardcoded because git subtree does not store that information. This means any modification to the repo structure needs to be replicated across a couple of scripts, which is not a fun maintainability task.

[sindresorhus]

The use case is far from obscure.

Of all the packages in the registry it is.

Sounds like publishing is the future and a decent compromise.

Yup, it's what i wanted from the start.

When will that be ready?

@danheberden @satazor is there any ETA on the server rewrite?

In the meantime, we may have to develop a Grunt task.

Again, why a grunt task?

[zenorocha]

Good news! Seems like all elements are now hosted on their own repositories.

https://github.com/Polymer

That's a great step and I'm glad you guys listened to us.

One more thing that I think we need to do is: make sure that every bower.json file contains the web-components and polymer tags. That way we can easily track them on @sindresorhus's discovery (http://sindresorhus.com/bower-components/#!/search/polymer) and also list them on webcomponents.org.

[sindresorhus]

I'd prefer if we used web-component (singular).

[0x-r4bbit]

@zenorocha Package ALL THE THINGS \o/

And yea, I'm with @sindresorhus . Singular is better.

[chalbert]

Hi there, my organisation is looking into splitting its apps into a myriad of small modules managed by Bower.

I found this thread and was wondering what was the final solution Polymer came out with to manage a lot of modules easily while still exposing as individual modules. I'm especially concerned by the repo-overhead as many modules will have interdependencies.

[sindresorhus]

Just use npm.