docs: async loader

[kamilogorek]

I'm still not sure how we should approach passing CDN/DSN url and Raven configs.

As last arguments to the snippet?

<script>
(function () { ...snippet code... }(
  'http://sdk.url',
  'http://cdn.url',
  { options }
))
</script>

As global variables with predefined names?

<script>
var RAVEN_CDN = 'http://sdk.url';
var RAVEN_DSN = 'http://cdn.url';
var RAVEN_OPTIONS = { options };
(function () { ...snippet code... }())
</script>

Also, it looks kinda big, even when compiled with closure compiler.

function(a,b,g,e,h,n,p,q){function f(a){(f.data=f.data||[]).push(a)}var k=a[e];a[e]=function(c,b,e,d,
h){f({e:[].slice.call(arguments)});k&&k.apply(a,arguments)};var l=a[h];a[h]=function(c){f({p:c.reason});
l&&l.apply(a,arguments)};var m=b.getElementsByTagName(g)[0];b=b.createElement(g);
b.src=n;b.g="anonymous";b.addEventListener("load",function(){try{a[e]=k;a[h]=l;var c=f.data,
b=a.a;b.f(p,q).install();var g=a[e];if(c.length)for(var d=0;d<c.length;d++)c[d].e?
g.apply(b.b,c[d].e):c[d].p&&b.c(c[d].p)}catch(r){console.log(r)}});m.parentNode.insertBefore(b,m)})
(window,document,"script","onerror","onunhandledrejection","https://cdn.ravenjs.com/3.23.2/raven.js",
"https://363a337c11a64611be4845ad6e24f3ac@sentry.io/297378",{h:function(a){console.log(a);return a}});

It's also hard to predict whether I covered all the edge cases (eg. I found out that I had to do things like on L63, as some browsers doesn't provide last argument to onerror functions).

[kamilogorek]

Related:

• https://gist.github.com/MaxMilton/e2338b02b7381fc7bef2ccd96f434201
• Asynchronous Loading and Capturing Errors #169

[jan-auer]

Generally looks good, though I agree about edge cases. Would be great if we could run it through our browser test matrix to verify - maybe as part of the standard test suite?

Regarding configuration: Your approach is probably already better. We could also go with a way Google Analytics handles this. Just assume a global object that has configuration.

[kamilogorek]

Things to do/consider:

• build and remove setTimeout from loader (needed for tests)
• do we really need to run the tests on Travis? It'll be rarely if ever changed tbh
• minify and add to docs

[kamilogorek]

It doesn't seem to timeout anymore, so we should be fine with leaving it on TravisCI for now.

I guess it's done... 'ish?

[benvinegar]

I recommend putting a semicolon before the snippet to prevent people from shooting their own foot:

;(function(a,b,g,e,h){...

[kamilogorek]

Fair point. Changed. Unfortunately, silly prettifier removes it from the source, so I had to add a silly perl addition to the build command :S

[benvinegar]

You could also mention that some cross-origin errors are more likely to be swallowed (and maybe link to our "what is script error" blog post).

[benvinegar]

Ah, I see your comment below, but I think this can also affect production.

[kamilogorek]

Added

[benvinegar]

Should we be re-throwing? Or pushing these errors into Raven's internals?

If we re-throw, it means there's a possibility other onerror instrumentation will pick up on this twice (e.g. if New Relic browser agent was loaded before ours).

[kamilogorek]

We are overriding onerror handler on line 14, so it won't be picked up by anything else initially. Only when we re-trigger it, so I think it shouldn't be caught twice by any other instrumentation.

[benvinegar]

There's a safer way to do this, at least, in Webpack, Browserify and other loaders. You can define a global variable (e.g. TEST), that if undefined does a no-op, and have that code branch stripped during minification.

As it is, we're relying on a "DO NOT REMOVE" comment to ensure that this potentially dangerous setTimeout never reaches production. I think we can do something a little stricter.

[kamilogorek]

The reason why I did it this way, was exactly to not use any webpack, browserify or other loader. As this will rarely (if ever) change, I wanted a whole thing to be a "single line" in package.json npm scripts. This way we can move it out from the repo, move it to packages, port it to v4.0 or do anything we want without remembering about any configs, loaders or similar things. Just take the source, pipe it to

cat src/loader.js | sed '/build_marker/{N;d;}' | npx google-closure-compiler-js | perl -e \"print ';'; print <STDIN>;\"

(which has no dependencies, as npx is a standard thing in npm now), and we're good to go.

[benvinegar]

Okay. Just worried this might be brittle. Should probably comment explicitly what's happening here.

[kamilogorek]

^bump @benvinegar