A Bower Option #2264

pfiller · 2015-03-11T05:41:13Z

I don't know about you, but I'm tired of people opening bower issues. I definitely do not want want to add generated js back into our repo, but I figured there had to be some way to do this that would make most people happy.

I thought we could maybe point bower at the generated assets in our gh-pages branch, but was disappointed to learn that bower relies on git tags. It seems the only good option is to create a separate repo (as @zurb has done with Foundation).

So, I've given it a shot. I've created a separate bower-chosen repo in my personal account. I didn't want to start it in Harvest's account in case we decide not to go this route. People might actually see it here, but there's little chance of that in my personal account.

This adds two new task:

grunt publish-bower: writes a bower.json file and shoves it (along with the necessary jquery assets) out to the bower-chosen repo
grunt publish-release: runs gh-pages:gh-pages as well as the bower-release task

That means our new deploy process would look like this:

Update version number in package.json
run grunt prep_release (builds our assets and generates a new zip)
Add generated .zip file to the Github release (and delete it from your local)
New version commit!
Publish the release (using the Github interface)
Run grunt publish-release

What do you think? Is this crazy? The only question I have is how this would work with other package managers (some people asked for NPM in #1433). Should we change the name of the other repo and call it chosen-published?

Please share your thoughts!

Addresses #2261, #1845, #1556, #1908, #1641, #1333, #1698, etc. etc. etc.

Targets a repo in my personal account which would be used as the *official* chosen bower package.

`grunt bower_publish` publishes to the bower-chosen repo (currently on my personal account, but may change to Harves) https://github.com/pfiller/bower-chosen `grunt publish_release` publishes to Harvest's gh-pages and runs the bower task

pfiller · 2015-03-11T05:42:44Z

BTW, you can see what the generated output looks like here:
https://github.com/pfiller/bower-chosen

koenpunt · 2015-03-11T07:47:54Z

What is the reason that we can't push the release packages to the main repo? Because like I see it, the contents of the release package in your bower repo is fine to use as a release package on the main repo.. Or was it that bower depends on the automatically generated tag-package..? Can't remember..

adunkman · 2015-03-11T13:41:56Z

Have you looked into bower/registry#78? I haven’t, but having another repo seems really… gross. I agree it’s less gross than build files in a source repo, but I think this is very clearly a problem with Bower, and seems like something we wouldn’t want to address in Chosen.

I believe that issue suggests that you can publish versions with something a-like:

bower register chosen http://harvesthq.github.io/chosen/1.4.0/

… but I’m not 100% sure.

adunkman · 2015-03-11T13:45:37Z

Oh, nevermind — seems like that issue supports loading git repositories over http and https, but they’re still required to be git repositories (as per discussion on bower/registry#23).

stof · 2015-03-11T13:53:02Z

@koenpunt the issue with having the compiled files in the main repo is that it leaves us with 2 options:

updating the dist file in the repo only for releases. Drawback is that all other commits are in an inconsistent state, which is bad (and breaks things for people expecting to get a dev version with bower)
updating the dist file all the time. this is what we did previously, and it means that all PRs will conflict all the time, making the maintenance a huge nightmare.

@pfiller npm should not be an issue, given that it does not get the code from github (you publish the dist code to the npm registry AFAIK). So npm would not need this special repo.
Note that you should add the Chosen team as collaborators on your repo too, so that other people than you can create releases as well. Having it in the same organization would make it easier by reusing the same Github team instead of duplicating the collaborator management

stof · 2015-03-11T13:57:29Z

@pfiller I think the bower-chosen repo should contain a small Readme file explaining the goal of this repo and pointing to the chosen repo for contributions (and issues should be disabled on the repo)

koenpunt · 2015-03-11T14:35:00Z

@stof I don't mean including them in the repo, just in the published archive ;)

pfiller · 2015-03-11T17:47:52Z

I agree that it's gross to have a separate repo for the generated files, but the dependency on tags doesn't leave us a lot of wiggle room if we decide to support bower. The really nice thing about this is that, once it's set up, this flow doesn't require any extra work on our part. It doesn't seem like the extra repo will need much, if any, maintenance.

I think the bower-chosen repo should contain a small Readme file explaining the goal of this repo and pointing to the chosen repo for contributions (and issues should be disabled on the repo)

100% yes. A link back to the main Chosen repo should exist anywhere it's possible.

Note that you should add the Chosen team as collaborators on your repo too, so that other people than you can create releases as well. Having it in the same organization would make it easier by reusing the same Github team instead of duplicating the collaborator management.

Yes! Hadn't thought of that. One thing to note is that you'd need to add a "Personal access token" to your GitHub account for authenticating to the repo via the command line the way it's set up right now. Although, I suppose that might not be necessary if it's in the same organization.

Anywho, it seems like nobody has any blocking feedback on the actual implementation of this. It's really just a question of if you think we should do it or not. Bower generates a lot of noise and I'd like to try and do things to make this repo less noisy. That way, when we're spending time on Chosen, it's on things that actually matter.

A 👍 or 👎 from you guys would be real helpful. If it's +1'ed in concept, I'll go ahead and change the repo to harvest and add y'all.

stof · 2015-03-11T18:08:39Z

@koenpunt the issue is precisely that Bower does not support using the published archives

stof · 2015-03-11T18:10:52Z

👍 on this concept

Btw, foundation is updating it from Travis-CI for each push to the main repo, so that even dev versions are available. What do you think about this idea (it would also solve the collaborator thing as only Travis would need the access) ?

koenpunt · 2015-03-12T09:47:35Z

👍 for automated builds on commit, and maybe a travis setup could be a nice reboot of our testing attempts :)

Ninir · 2015-03-27T11:14:03Z

👍 Yeah, interesting idea @pfiller ! How much work do you guys think you would need to finish this? This subject has been in minds for months...

pfiller · 2015-03-27T18:39:46Z

Going to merge this and get it working with Travis today!

Add a way to build a public-facing Bower repo. This is still a WIP

tjschuck · 2015-03-27T20:00:37Z

pfiller · 2015-03-28T04:31:25Z

Published: bower install chosen

Ninir · 2015-04-14T07:10:34Z

👍 Great work guys!

pfiller added 3 commits March 10, 2015 23:57

Add a bower repo commit

cdde268

Targets a repo in my personal account which would be used as the *official* chosen bower package.

Add a bower publishing task

25454ee

`grunt bower_publish` publishes to the bower-chosen repo (currently on my personal account, but may change to Harves) https://github.com/pfiller/bower-chosen `grunt publish_release` publishes to Harvest's gh-pages and runs the bower task

Less _'s means less keypressing!

34d4d0a

pfiller mentioned this pull request Mar 11, 2015

Use grunt-gh-pages to build our pages #2263

Merged

pfiller mentioned this pull request Mar 27, 2015

Get a base travis file up and atom #2283

Merged

I moved the repo to @harvesthq's account

2582682

pfiller added a commit that referenced this pull request Mar 27, 2015

Merge pull request #2264 from harvesthq/bower-package

8aec3b8

Add a way to build a public-facing Bower repo. This is still a WIP

pfiller merged commit 8aec3b8 into master Mar 27, 2015

pfiller deleted the bower-package branch March 27, 2015 18:40

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

A Bower Option #2264

A Bower Option #2264

pfiller commented Mar 11, 2015

pfiller commented Mar 11, 2015

koenpunt commented Mar 11, 2015

adunkman commented Mar 11, 2015

adunkman commented Mar 11, 2015

stof commented Mar 11, 2015

stof commented Mar 11, 2015

koenpunt commented Mar 11, 2015

pfiller commented Mar 11, 2015

stof commented Mar 11, 2015

stof commented Mar 11, 2015

koenpunt commented Mar 12, 2015

Ninir commented Mar 27, 2015

pfiller commented Mar 27, 2015

tjschuck commented Mar 27, 2015

pfiller commented Mar 28, 2015

Ninir commented Apr 14, 2015

A Bower Option #2264

A Bower Option #2264

Conversation

pfiller commented Mar 11, 2015

pfiller commented Mar 11, 2015

koenpunt commented Mar 11, 2015

adunkman commented Mar 11, 2015

adunkman commented Mar 11, 2015

stof commented Mar 11, 2015

stof commented Mar 11, 2015

koenpunt commented Mar 11, 2015

pfiller commented Mar 11, 2015

stof commented Mar 11, 2015

stof commented Mar 11, 2015

koenpunt commented Mar 12, 2015

Ninir commented Mar 27, 2015

pfiller commented Mar 27, 2015

tjschuck commented Mar 27, 2015

pfiller commented Mar 28, 2015

Ninir commented Apr 14, 2015