storyarc/pagination — pull request #1 by pushred (2013-06-06 21:42:49+00:00)
Title: Update pagination for use with solidus/hipster

I think we can settle on Bower as the method for distributing this to sites. The requirements as I see them:

- **Easily install and load Solidus add-ons.** The proprietary nature of these are really at odds with Component but Bower provides some automation of Git cloning and dependency management, so it makes sense as a distribution method. Facilitating rapid development is a goal for any add-on, Bower will help with that. There's also a lot of value in providing bootstrap styles for sites, especially as Scss with customizable variables. Twitter Bootstrap and Foundation have proven how successful that can be. But developers will need to be able to freely modify these files, so they'll need to be distributed separately of Bower. As I noted earlier I think [grunt-init][1] could help there as an extension of what we started with the site template. We're going to need to have separate repos for each of those as a result, but that's a good thing. I just need to figure out where to put them =)

- **Easily install and load Scss mixin libraries.** This is where Bower is really lacking. None of the popular libraries I've pulled down have anything of significance in their bower.json files, they're just Git clones. The worst I've seen is Bourbon, one of my favorites. But it's so attached to the hip with Rails that it comes with a Rails 3.x directory structure, even though it can totally be used separately. I guess that's what we get for not using Stylus!

- **Easily install and load JavaScript libraries.** For this we may be able to provide some level of automation as the popular libraries (jQuery, jQuery UI, Underscore, etc) are at least using tags. They don't have manifests though, but for jQuery at least I saw a main file designated in the Bower registry. I would hope that the quality of their registry entries would be better than most.

- **Easily install and load jQuery plugins.** TJ hates them and I totally know what he's coming from. But it's going to take a long time (if ever) before Components has sufficient momentum that it's comparable to general level of maturity and capabilities that jQuery plugins have. Site developers will generally want to use jQuery plugins for the foreseeable future. Bower already has traction with some popular jQuery plugins and is focused on solving the problems concerning the inconsistencies between the various repos.

- **Easily install and load icon fonts.** This is probably one of the easier problems because valid font formats are going to reliably be the distributable files. Something like [grunt-bower-organiser][2] could make installing these from a repo relatively easy, locating and moving valid font file extensions. I wonder how slow walking the trees will make install though, [some of these repos][3] are pretty bloated.

So as the easy load requirement definitely isn't going to be satisfied by Bower in it's current state, particularly the registry. As simple clones of repos, Bower packages can have any sort of directory structure and require good manifests to point us to the files we care about. I wish Git sparse cloning existed as that would probably help in some cases where the distribution files are in paths we could target. For third-party projects we'll just have to defer on this goal for now — loading them will have to be the developer's responsibility.

However, as Bower users, we can do our part to help improve the current situation by expressing some demand, opening issues with substandard repos and advocating semver Git tags, quality manifest files, etc. These are best practices and I really appreciate that Bower's features leverage them, rather than creating something new altogether. It's unfortunate that there isn't any cooperation between Bower and Component (and other projects) on the spec of the manifest files, they even collided on filename conventions for a period with Bower using `component.json`. The manifest format is definitely [still being worked out][5] for Bower. I'd love to contribute to Bower wherever we can if we identify specific issues and have a good solution to propose.

Worst-case, Bower does provide us with the ability to add a registry of our own in front of theirs, allowing us to create conformant forks of anything significant where we run into poor registry entries that block our goals. But this isn't a pressing need. For now our focus needs to be on simplifying building sites with content from APIs.

So on that front, I think Bower works as-is for the needs of our own add-ons where we definitively control organization and manifests. As long as we don't have dependencies in the Bower registry outside perhaps some standard JS libraries we could provide some level of "plug-n-play", which is desirable because these add-ons potentially touch on many different file types. I really want to be able to bundle them up with grunt-init templates as well, so developers need only run a single command like `solidus add pagination`.

I don't think we should publish our add-ons though to the Bower registry, as GitHub provides a clean namespace that we control and may be cleanly scoped to Storyteller. That's one aspect of Component that I really appreciate, but Bower can work just like it. The registry is optional. I do appreciate Isaac Schlueter's [noble intentions][4] though for the npm namespace, but in our case the utility of these add-ons isn't purely on the frontend and they're going to generally be proprietary to Solidus/Hipster. No use in polluting the Bower registry namespace.

[1]: https://github.com/gruntjs/grunt-init
[2]: https://npmjs.org/package/grunt-bower-organiser
[3]: https://github.com/FortAwesome/Font-Awesome
[4]: http://wheelcode.blogspot.com/2013/05/a-pox-on-both-your-package-managers.html
[5]: https://docs.google.com/document/d/1APq7oA9tNao1UYWyOm8dKqlRP2blVkROYLZ2fLIjtWc/edit