As discussed, this implementation is completely deferent to the existing window.RavenConfig, copying over any properties from the UI-entered settings only when they're undefined on the existing window.RavenConfig.config. The reasoning here was that since we don't have a rule engine for when to apply settings (they're blanketed across your whole project), that we should totally respect the RavenConfig variable as the user's page-specific "escape hatch" settings-wise.
Where I still need a hand / extra-careful review:
[ ] is allowing customers to pass their regexps as strings sane? is this the right approach for letting them do so?
Obviously, status is DO NOT MERGE until we update metadata accordingly.
This PR adds support for a few new settings via the UI:
http://raven-js.readthedocs.org/en/latest/config/index.html
Here's the way
window.RavenConfig
is used in initializing the lib — https://github.com/getsentry/raven-js/blob/master/src/raven.js#L849-L852. All of the options I've added belong in thatRavenConfig.config
sub-object.As discussed, this implementation is completely deferent to the existing
window.RavenConfig
, copying over any properties from the UI-entered settings only when they'reundefined
on the existingwindow.RavenConfig.config
. The reasoning here was that since we don't have a rule engine for when to apply settings (they're blanketed across your whole project), that we should totally respect the RavenConfig variable as the user's page-specific "escape hatch" settings-wise.Where I still need a hand / extra-careful review:
Obviously, status is DO NOT MERGE until we update metadata accordingly.
@ndhoule @f2prateek