Making the web a better place: Bower Hitlist

213 views
Skip to first unread message

Daniel Garcia

unread,
Sep 24, 2012, 2:38:08 PM9/24/12
to twitte...@googlegroups.com
Hey guys, I was told that I should re-post this call to arms from the folks on twitter, @twitterOSS. Here's the skinny, excerpted from my summary on a new initiative I'm trying to start:

I'm aiming to take some of the more popular jQuery plugins that have suffered near disappearance from the plugin site going down and making sure they have a github presence. If they do, I'll be forking the repo and adding a components.json to their root so the plugin can be listed against bower. If they don't, I've created an org called bower-hitlist which will be the home of plugins who do not already have an established presence or are not being actively maintained.

If this is something you're interested in contributing to, or you'd like to suggest projects to add to the hitlist, let me know! Bower is one of the very few systems I actually can back, and see as something that can make an immediate impact with the community.

Getting involved is as simple as sending a pull request to your favorite plugin's repo with a component.json file if they don't already have it.  I've also included a short sample component.json for use with this project on the summary page.

Let me know what you guys think, and please contribute if you can. Thank you very much!

Eric Strathmeyer

unread,
Sep 24, 2012, 2:50:40 PM9/24/12
to twitte...@googlegroups.com
Awesome! I want to help.

A related task is to make sure that all the packages registered with bower actually have usable component.json files. I actually went through all of them last night.  Here's the list of registered repos which don't have a component.json at all. Please help submit pull requests to them (or get them removed from the registry if they're not a front-end package)


A third related task is to go through the packages that do have a components.js and make sure it declares a main asset, and any relevant dependencies.


--
 
 

Alex MacCaw

unread,
Sep 24, 2012, 2:56:04 PM9/24/12
to twitte...@googlegroups.com
This is all awesome!

--
 
 



--
Alex MacCaw

+12147175129
@maccman

http://alexmaccaw.com

Daniel Garcia

unread,
Sep 24, 2012, 3:04:08 PM9/24/12
to twitte...@googlegroups.com
I'm updating the gist right now with these new items. I'm also going to be migrating the overview into the main repo for the hitlist org, so that'll be available for pulls there shortly. Keep them coming!

William Oliveira

unread,
Sep 24, 2012, 3:05:27 PM9/24/12
to twitte...@googlegroups.com
Nice!

I'm in. :-D

--
 
 



--
// w. oliveira 
// js - python - lisp - clojure

Daniel Garcia

unread,
Sep 24, 2012, 3:35:10 PM9/24/12
to twitte...@googlegroups.com
Cool stuff! I've updated the list, and to allow for pull requests, issues, and contribution I've migrated it here:


Hope to see you guys there!

Eric Strathmeyer

unread,
Sep 29, 2012, 9:21:23 PM9/29/12
to twitte...@googlegroups.com
Thanks for getting this set up, Daniel!

I saw that you're using a much more complicated componen.json than Bower requires. Do you know if there are official plans to support these extra keys?

Daniel Garcia

unread,
Oct 1, 2012, 6:45:28 PM10/1/12
to twitte...@googlegroups.com
Sorry for the late response! I just got back from a conference. I'm currently following the Common.JS syntax for a package.json, stripped further down to account for less necessary items on client side. You can find them here:


This is entirely opinionated, but the reason I'm moving to this is because we already HAVE a package format that works, and why not utilize something that's proudly invented elsewhere? I'm also working on a fork which adds the extra fields to bower so it behaves similarly to NPM-- but this needs to be out in the wild before it can be tested extensively! Worst case is that it won't support these properties, and the repo author can strip it out if they don't want it.

David DeSandro

unread,
Oct 7, 2012, 9:07:01 PM10/7/12
to twitte...@googlegroups.com
Looks like Masonry and Isotope on the top of the hitlist and I'd like to help mark those off properly. One question: should we follow a naming convention for plugins? i.e. should the "name": "masonry" or "name": "jquery-masonry".

I see that someone has already registered "jquery-masonry", so should we follow that?

David DeSandro

unread,
Oct 7, 2012, 9:12:25 PM10/7/12
to twitte...@googlegroups.com
I also see that flesler's jQuery plugins use the dot syntax. i.e. "jquery.scrollTo"

Eric Strathmeyer

unread,
Oct 7, 2012, 9:16:23 PM10/7/12
to twitte...@googlegroups.com
The list of registered packages seems to be split right down the middle between dots and dashes.

I prefer dash (and all lowercase), but that's just me.

Perhaps match the git repo?


--
 
 

Daniel Garcia

unread,
Oct 7, 2012, 9:54:30 PM10/7/12
to twitte...@googlegroups.com
My personal opinion would be follow jquery-masonry since it was established and don't want to segment the work, right? It also makes sense that if its a direct jquery plugin, jquery hyphen name would be a great syntax to follow for registered packages.

On Oct 7, 2012, at 9:07 PM, David DeSandro <desand...@gmail.com> wrote:

Looks like Masonry and Isotope on the top of the hitlist and I'd like to help mark those off properly. One question: should we follow a naming convention for plugins? i.e. should the "name": "masonry" or "name": "jquery-masonry".

I see that someone has already registered "jquery-masonry", so should we follow that?

--
 
 

Daniel Garcia

unread,
Oct 7, 2012, 9:55:33 PM10/7/12
to twitte...@googlegroups.com
That's correct, I helped him set those up as such, so that is actually my opinionation again-- please feel free to give additional input here if you disagree.

Typos and brevity brought to you by iaPd.
--
 
 
Reply all
Reply to author
Forward
0 new messages