Add support for bower package manager

[peters]

Also added latest release files.

Visit http://bower.io for installation instructions.

After you have installed bower, you need to register the package:
bower register jquery.sparkline git://github.com/gwatts/jquery.sparkline.git

[gwatts]

Why'd you add this?

[peters]

Ignore all files except javascript. It's pretty much useless to integrate bower support if you have to manually
compile a dependency.

[gwatts]

The dist files should not be checked in as we'd have to continue to check them in after every commit - If bower isn't capable of running a make script, then it shouldn't be in the repo, but could be part of the build process instead and distributed as a .tar.gz

the dist directory uses * for it's .gitignore as it should also include things like the Changelist, which isn't .js

[gwatts]

Rejecting in favour of someone coming up with an alternative that doesn't involve checking in duplicate code.

[neverfox]

Bower requires a pre-built distribution. However, I don't see why this couldn't be handled here. It only responds to new release tags, so you wouldn't have to build and check in after every commit, unless you're tagging every commit as a new release. You could have stable built distribution file somewhere in the repo and set it as the main file for Bower.

[filipegiusti]

@neverfox this bower requirement is stupid and @gwatts doesn't want to do stupid things in his repository because of that.

[neverfox]

@filipegiusti Maybe so. Maybe not making your library accessible on what's becoming a widely adopted method of dependency management just to avoid adding 120kb or so to your repo is also stupid. Maybe the fact that Bower is becoming somewhat of a standard is stupid. I tend not to worry about it, since I imagine it'll all sort itself out.

[gwatts]

Someone else pointed out in another issue that you can do:
bower install --save http://omnipotent.net/jquery.sparkline/2.1.2/jquery.sparkline.js
or
bower install --save http://omnipotent.net/jquery.sparkline/latest/jquery.sparkline.js

[neverfox]

@gwatts Yes, being able to use a direct link works fine. Not ideal for automatic semantic version control of dependencies, but it serves.

[filipegiusti]

@neverfox did you checked why jQuery doesn't commit the build to the repository? Can you understand that the problem is not only the 120kb in the repo?

[neverfox]

Sure, but just about every reason I've heard can be overcome by pushing the dist files to the tag (all Bower cares about) and resetting. No dist in the repo outside of those tags. No merge conflicts etc.

[bjmiller]

Can we put a very simple package.json in the repo, so that it can be installed using npm for use with Browserify?

It would only need a name, a version (which doesn't have to be the actual version, it only needs the field filled out with something) and a pointer to the Makefile so that it can run the build locally for the user after it installs.

Give an OK, and I'll submit a PR.

[mryellow]

The dist copy should be specified as a main file, this means it is available after install from a known path. While using dist makes for nice clean Grunt path patterns, as almost everyone uses this path.

This would fit with the conventions I'm observing in your peers JS libs.

Here are some examples with dist committed to repo:
https://github.com/twbs/bootstrap
https://github.com/jquery/jquery
https://github.com/pouchdb/pouchdb

Here is an example where dist doesn't exist until Grunt is run:
https://github.com/knockout/knockout

edit: Actually PouchDB builds it after too.....

This works in concert with grunt grunt-bower-task and others which go through and install/build each lib from their bower config.