Sentry-ruby: Proposal to include Raven-JS

[SirRawlins]

Morning Folks,

This morning I noticed that whilst my raven-ruby was a current version, my link to raven-js for tracking client side errors was very out of date. Being that it was a hotlink in my boilerplate HTML template rather than a gem it got missed during our usual bundle updates.

I'd like to propose that we gemify the raven-js client, so it can be maintained along with the rest of the raven bundle, and can also be included through things like the rails asset pipeline.

As to whether this lives within raven-ruby or it's own gem (raven-rails?) I'm a little unsure, although I do notice someone else appears to have done this before, but it's fallen out of maintenance. https://github.com/christianvuerings/ravenjs-gem

Interested in peoples thoughts on this.

Robert

[nateberkopec]

Paging @dcramer, do we do this in any other language clients?

Happy to provide raven-js, not sure what would be the best way to deliver it though either. People probably want to be able to //= require raven.js in application.js I imagine. That means we'll have to have a Rails engine rather an Railtie IIRC, but I dont think that's a big deal.

[SirRawlins]

@nateberkopec thanks for input. Personal preference would certainly be to have it part of the asset pipeline. I guess one could argue that this falls outside the scope of raven-ruby and would perhaps be better off in its own distinct package (perhaps raven-rails) which included both raven-ruby and raven-js in a combined bundle.

It'll be good to hear from @dcramer about his thoughts on the best direction.

[syndbg]

There's npm for node packages and it's quite straight-forward how to maintain with it.

I'd like to propose that we gemify the raven-js client, so it can be maintained along with the rest of the raven bundle, and can also be included through things like the rails asset pipeline.

You can still include it in the Rails asset pipeline w/o being a pointless gem for just a JS dependency.

vendor/assets is for assets that are owned by outside entities, such as code for JavaScript plugins and CSS frameworks. Keep in mind that third party code with references to other files also processed by the asset Pipeline (images, stylesheets, etc.), will need to be rewritten to use helpers like asset_path.

(ref: http://guides.rubyonrails.org/asset_pipeline.html)

[SirRawlins]

@syndbg I understand I can drop JS assets into the vendor/assets directory, but it's then a separate dependency which I have to manually maintain - rather than having bundler do it for me.

I agree that spawning gems purely for JS assets is overkill, but it is a common enough practice.

Ideally, I'd like to see the Rails core team come up with a better way to manage front-end dependencies - but for the moment I'm not aware of any plans.

[syndbg]

@SirRawlins I think with https://github.com/rails/webpacker becoming part of Rails 5.1, npm's package.json is the way to go.

[SirRawlins]

@syndbg excellent, that looks interesting. I'll dig a little deeper into that. Appreciate the nudge in the right direction.

[nateberkopec]

I think I'm going to close this - with webpacker/rails new --webpack, people should generally just be using webpack and installing raven-js through NPM if they want a "packaged" version of Raven-JS.