CODEWITHSUNDEEP
javascriptruby-on-railsgitbundler
iblue
iblue

Reputation: 30424

What is the best way to keep javascript libraries up-to-date in rails?

I am currently develoing a Rails application which makes heavy use of some javascript libraries, including jquery, backbone.js and d3.js. For jquery, there is the jquery-rails gem, for backbone, we have backbone-rails. But nothing like this exists for d3.js.

I copied the javascript from d3.js to my repository, this feels a bit unclean to me though, because when d3 gets updated, I have to copy it again (and I have to notice, that d3 got updated!). I thought about git submodules, but I have to pull them manually every time I check out the repository. May be there is way to let bundler check out a specific release of the d3 repository?

How do you handle updating third-party javascript libraries in rails? Is there a preferred way?

Upvotes: 6

Views: 742

Answers (2)

John
John

Reputation: 4382

Why not create a d3-rails gem if there isn't one? The convention now seems to be to put these javascript libraries in their own gems with jquery-rails now included in Rails 3.1. It's more work now but it might payoff for you down the road. You would be helping the community and it would make for easy updates within your app.

Upvotes: 6

Xavier Holt
Xavier Holt

Reputation: 14619

Not sure why you got downvoted for this...

But I'm going to have to agree with the comment that says to do it manually. I wouldn't leave it out of your repository - no call for that; you want to keep your current version around - but I'd not recommend having it update automatically.

That's for stability. If you make "heavy use" of JS like you say, a quirk - or even a bugfix for a bug you worked around - in the latest version of a library could play havoc with your code. We got bit by something like this when jQuery tweaked how it treated attr() and prop() between two versions.

So if you always update your libraries manually:

  • You always know when they change, and that you have to do some thorough testing before making the changes public.
  • You can stay with an older version of the library if you want to - for performance, or to give you time to work around the latest quirks, or whatever.

Hope that helps!

Upvotes: 7

Related Questions