search

gwatts / jquery.sparkline

A plugin for the jQuery javascript library to generate small sparkline charts directly in the browser
http://omnipotent.net/jquery.sparkline/
1.24k stars 278 forks source link

Add support for bower package manager #77

Closed peters closed 11 years ago

peters commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

neverfox commented 10 years ago

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 commented 10 years ago

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

neverfox commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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

filipegiusti commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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 commented 9 years ago

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.