Better plugin support

Need to come up with/think of a better plugin system. The current one was done as simple as possible to get things moving, but there are lots of downsides to it currently.

Doesn't work with AMD loaders or browserify or anything like that.
Raven has no concept of what's installed or how it's installed, so no way to uninstall.
No way to test them.
They rely on some magic globals.

Probably other stuff too.

@mattrobenolt

Let us brainstorm a bit about this... 💭

So Raven-js needs a registry of all installed plugins. And a plugin needs a common interface. It could be something like this:

unique name for the plugin for referencing
install: function(window, Raven)
uninstall: function(window)

Then in a Browserify scenario, it could look something like this:

var raven = require('raven-js/raven.js');
var plugin1 = require('raven-js/plugins/1');
var plugin2 = require('raven-js/plugins/1');

var options = {
    ignoreErrors: [],
    plugins: [plugin1, plugin2]
}

Raven.config('https://public@getsentry.com/1', options).install()

@mattrobenolt something like this?

How does this work in non-browserify scenarios? Say, including as a <script> tag, or through require.js?

The question is if we will continue with custom build where plugins are 'baked in'. If we do then the plugins list would already be prepopulated.

Looks like your comment got removed by some XSS detector... :)

Currently when including one of the custom builds with raven and some plugins, the plugins are automatically loaded, right? In the new solution we only want them to be loaded when raven is being installed.

They are automatically loaded, but noop'd until Raven is configured/installed.

Ok. So what is your take on the plugins in a non-browserify world? I guess the custom builds where everything is included is pretty nice.

The problem is we need to covery many use cases:

A nice combined build suitable for a <script> tag. I personally like this since it's the most versatile and easy to get up and running. I also don't personally use these fancy package managers and whatnot.
Browserify
Normal AMD style loader
Installing from bower
Installing from npm
CommonJS

I understand personally 2 of these cases. <script> because lol JavaScript used to be easy, and require.js (AMD) which has been around for a long time.

Take a look at: https://github.com/getsentry/raven-js/blob/master/template/_footer.js for what raven core needs to support. I'd imagine this all needs to carry over into plugins and needing to support somehow all of these cases as well.

I think a good first step is providing a plugin interface that Raven understands, with the suggested install/uninstall methods. We can convert the plugins over to that. Then worry about module loading and whatnot after.

Another aspect I'm very cognizant of is file size. I try very very hard to keep raven as small as possible, and keep in mind how things will get minified, and compare gzipped sizes.

So I like to keep the public APIs small, since public APIs cannot get minified and contribute to overall size. :)

@BYK

@BYK Any opinions? Disqus has switched over to using raven.js through bower now, and through doing that has lost the plugins. I think it's bower + require.js?

So curious if there has been any thought or plans on how to make this work.

@mattrobenolt

Makes sense. : )

One challenge with package managers might be to get a reference to for example Backbone, as it might not be saved to window.Backbone. In some of the cases it might be necessary to pass in reference directly to the plugins. But we should be able to extend the outlined plugin system with this.

But I agree @mattrobenolt , we would start with a first plugin version where we support that plugins can be uninstalled together with Raven-js. But let's get some input on the package manager use cases.

In the case of browserify, I found out, there literally is no window object at all. It mutates the JavaScript to actually remove any attempt at using window at compile time.

@mattrobenolt

@mattrobenolt this is not true at all.

@terinjokes

@terinjokes Then I was misinformed. We had lots of issues checking for window.JSON because that didn't work.

See: #261

I've literally never used browserify, fwiw. I can't keep track of these things, so there is some amount of trust that people who use this are fixing bugs that affect them. :)

We've since changed the plugins dramatically – they no-longer self-execute, can be tested, etc.

Closing this ticket.

Navigation Menu

Repository navigation

Better plugin support #282

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Better plugin support #282

Description

Activity

skovhus commented on Nov 16, 2014

mattrobenolt commented on Nov 16, 2014

skovhus commented on Nov 16, 2014

skovhus commented on Nov 16, 2014

skovhus commented on Nov 16, 2014

mattrobenolt commented on Nov 16, 2014

skovhus commented on Nov 16, 2014

mattrobenolt commented on Nov 16, 2014

mattrobenolt commented on Nov 16, 2014

mattrobenolt commented on Nov 16, 2014

mattrobenolt commented on Nov 16, 2014

skovhus commented on Nov 16, 2014

mattrobenolt commented on Nov 16, 2014

terinjokes commented on Nov 18, 2014

mattrobenolt commented on Nov 18, 2014

benvinegar commented on Feb 22, 2016

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions