package management for rails and javascript
jedschneider opened this issue · comments
@jejacks0n and @boyajian I'd like your guidance on this, i'm pretty sure doing a gem package and defining that as a dependency in utensils is fine and I can figure that out, but for pure JS users, I've been looking at bower since its a part of yeoman and this seems like a logical way to distribute the standalone javascript/coffeescript version of bindable that lives outside utensils. But, maybe I'm missing another more popular platform for JS users. I dont think it would make sense to distribute via npm directly, since its not really a server side thing, but maybe @mkitt would disagree...?
also, I'm sure @cacheflowe may have some pretty strong opinions on this?
I'm not sure we should package it as a gem if it is a standalone js package. Having a bower or components https://github.com/components/components manifest file plus a pre minified version for download is probably sufficient. Spine.js is potentially a good reference point.
seems like that is exactly the way spine approaches it: spine-rails gem for rails and then bower for distribution as pure js. does the spine-rails gem do more than setup a directory structure, etc.
i think the solution I'd want to solve with the gem is to improve the package management process over just a download endpoint.
The problem with spine-rails is it doesn't track the versions of spine fast enough. The other problem with js in a gem is it only helps rails devs. I have seen some debate about whether asset gems should be used at all. My guess is something like bower will eventually have a rails hook and js will be distributed more in that manner.
I'm struggling with this too. And I'm curious where you land. I was planning on doing a submodule for mercury/mercury-rails, but that makes me cringe.
hmm. maybe we should write the asset manager for rails based on bower. seems like it would be pretty straight forward.
So, the problem isn't that there's no decent solutions.. the problem is that the community hasn't decided on which one.
I feel like we need something like bundler for js files. Since I have been back in chef land and using Berkshelf http://berkshelf.com/ it has made life way easier for managing cookbooks. It uses a similar api to the Gemfile for listing the dependencies. They get downloaded locally still but, it provides a nice way to manage locations and versions outside any other assumed dependencies. The same setup is being used in iOS, CocoaPods http://cocoapods.org/ and it uses the same Gemfile format. Seems like this might be a possible method for declaring dependencies no matter the platform.
The Berksfile is parsed using https://github.com/RiotGames/solve and there is also https://github.com/applicationsonline/librarian which is used in librarian-chef a competitor to Berkshelf.
I'm all for it. So let me explain my experience with mercury dependencies and see if there's a solution for it. Mercury has a few dependencies -- listed:
jQuery
marked (markdown parsing)
Rangy (selection library)
liquidmetal (string similarity library)
and a few other libraries that handle html cleaning and beautifying.
Using bower I could specify exactly one of those libraries -- jQuery. When I release Mercury I will provide a definition, (likely bower?) so it can be added as a dependency, but the problem isn't that there's nothing good out there -- the problem is that so few libraries have moved in that direction that it borders useless. I ended up taking it out of the project because what it provided wasn't worth the extra work.
I'm not being a nay-sayer, I really want a solution -- which we can write. =) But it has to take that into account.
Maybe what we need is a way to create adhoc package definitions for projects that don't have them. So, if we list an asset it looks locally in a specifications folder or something for that component. If, there isn't one there it checks the url for it? I know this was also an issue with CocoaPods so, it seems like providing a way to override a dependency declaration would be useful generally.
so, I guess another way to look at that is that there is seemingly nothing stopping you from registering those other dependencies with bower, and presumably it would be as much work to update your forks for those dependencies as it would be to copy and paste and handle those dependencies manually. building too on what gabe is saying for allowing a locally vendored copy, like the gemfile, you could point to a local clone. just some ideas...
Let's use the term spec for gemspec here.. the chain of events in my head:
a url to a git repo (look for spec)
a url to a package (eg. zip with spec)
a url to a path (look for spec)
a url to a spec
a url to a remote file (curl it, but what about versions?)
a path to a package (eg. zip with spec)
a path to a dir (look for a spec)
a path to a spec
a path to a file (what about versions?)
That fits into the way bundler works, right? Just another added layer for single files.. how do we handle versions with that though? it has to be sort of flexible because I've learned that versions sometimes don't exist.
well and I wasn't even necessarily thinking about the source as much as the spec file. It would be like overriding a gemspec for a gem that has outdated dependencies in it. Also, to frame the problem space what I am proposing is just the bundler part of this. Bower and Components are still trying to solve the RubyGems side of this issue. Seems like maybe we want to stay away from the package management and maybe focus on the dependency management side of this?
just as a sidenote, it does seem that at least a couple of the dependencies you needed for mercury have been picked up by bower now. so maybe the adoption is coming?
[joule] net_magazine [1.9.3-p194] [master #] /usr/local/share/npm/bin/bower search marked
Search results:
marked git://github.com/chjj/marked.git
[joule] net_magazine [1.9.3-p194] [master #] /usr/local/share/npm/bin/bower search rangy
Search results:
rangy git://github.com/Dakuan/Rangy-bower.git
I hadn't really considered that dependency management and package management are separate things, but, clearly they are.
@jed, yeah the direction is really bower at the moment, which is good. The Rangy one was out of date, and I never checked the marked one because it came in after I gave up. =)
Yep it's still sort of the wild west out there. I read this article a while back which gives some other alternatives as well: http://wibblycode.wordpress.com/2013/01/01/the-state-of-javascript-package-management/
Not sure what the right answer is here. I don't think anyone really knows yet. I do think we should drop a version into npm as well. Really once you figure out how the package management works, it's as easy as dropping in a package.json file along with a component.json file and pushing it up.
@mkitt is there a way for users to use bindable as an npm module for brower based applications? I'm not sure i've ever seen that done, but shoot its just javascript so why not? is this common? what are the workflows associated with using via npm?
Probably not, but not everyone in the node/npm community has bought into the idea of components yet. So people are using npm similar to how the rails community uses bundler for managing packages. jQuery itself hasn't even added a components.json file yet, but they do have a package.json. Figured there is no harm in having it in there.
@mkitt is this popular? https://github.com/substack/node-browserify
That one looks pretty convincing -- I don't think I like the require part, but the rest seems legit.
Yep, that dude is one of the big players in the node community.
So it does look like Bower is being incorporated into sprockets
- sstephenson/sprockets#358
- http://kaeff.net/posts/sprockets-bower-better-component-packaging-for-rails-asset-pipeline.html
Not sure how this changes things, but seems like Bower is where things are headed.