Better plugin support

[mattrobenolt]

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.

[skovhus]

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?

[mattrobenolt]

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

[skovhus]

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.

[skovhus]

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

[skovhus]

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.

[mattrobenolt]

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

[skovhus]

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.

[mattrobenolt]

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.

[mattrobenolt]

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.

[mattrobenolt]

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. :)