Build automation and Bower package

[molefrog]

Hey! I was really impressed by the work you did, I even used your library to create dynamic visualization on my personal website http://molefrog.com. But the one thing that I missed during the work is the ability to install all browser dependencies using package manager (bower in my case). So I'm actually thinking to publish your library to bower repository (if you don't mind, of course), so people can easily install it using command line or even fully automate this process.

But first of all I decided to change project structure just a little bit and add a support for modern front-end development workflow tools, such as Grunt. So in order to build the library one just need to type:

npm install -g grunt-cli
npm install
grunt

This will compile and minify all source file in src/ folder and create distribution script and it's minified version in the root folder, so we can later specify it as a bower endpoint.

I'm also planning to add some basic test cases, but I haven't decided what is the most appropriate way to do it yet. I hope that you will like the whole idea. Waiting for your feedback!

[fxb]

Hi! I haven't worked on this project in a long time and I'm happy that it's still used. I had one comment on committing the dist/ directory, but otherwise it looks fine and I can merge the pull request.

[molefrog]

I decided to remove the /dist folder in the very last commit (22c31c5). I thought that it is more convenient, so there is no longer need in this folder.

[fxb]

I actually meant that committing a minified file not really good practice.

[molefrog]

Ok, got it. Actually, since Bower uses git repo as a package storage (i.e. it only saves metainformation about the package including the url to the reporsitory), many packages do have minified version. Take a look on https://github.com/mbostock/d3, for example.
But it's totally up to you, I don't think it matters in our case.

[fxb]

It seems a bit weird to me to do it that way, especially when there are mutliple repos / forks. Since now package.json (in this repository) would then contain a hardcoded URL to your fork at 'https://github.com/molefrog/lastfm-api.git'.

[molefrog]

Well, that's my fault: I wasn't patient enough to wait for your answer, so I managed to publish package to the Bower registry pointing to my local fork. As for the way of publishing packages: I can understand you, I don't like it either, because it seems that Bower does it more dummy than for example npm does (it doesn't point to any git repository, and everything including source is copied to the central registry).
But I see 3 possible solutions of our problem:

1. We can change the repository field in package.json and bower.json to your repository and republish the package. I suppose that would be the most appropriate choice for me.
2. You can reject the pull request and we will remain the package (that points to my fork). This seems dirty for me, but in that case we will still have the package.
3. You reject the pull request and we remove the package. I remove my fork, since the whole thing was a bad idea from the beginning :)