Reload uncaughtException plugin if enableUncaught changes, same with unhandledRejection

[BethanyBerkowitz]

See #1161 (comment).

Currently, the listeners for uncaughtException and unhandledRejection are only added if the corresponding setting is true. Then the listener decides not to report if the user later changes the setting to false. This is reasonable, but inconsistent because if the user sets up Honeybadger with the setting off, then later flips it to true, the plugin will not be reloaded and the listener will never be attached.

We prefer to reload the plugin if enableUncaught changes. (ie remove the listener if the value is set to false and add it if it's set to true). Same deal with enableUnhandledRejection.

• make uncaughtException plugin able to be loaded more than once (js package) chore(js): allow uncaughtException plugin to be loaded more than once #1170
• make unhandledRejection plugin able to be loaded more than once (js package) chore(js): allow unhandledRejection plugin to be loaded more than once #1172
• reload the plugins when the client is re-configured based on a setting (core package) feat(core): optionally reload plugins #1174
• update core pkg version that the js package uses, turn on setting to reload (js package). Can also remove duplicate checks for enableUncaught and enableUnhandledRejection at this point feat(js): reload unhandledRejection and uncaughtException plugins on configure #1184
• update the docs: https://github.com/honeybadger-io/docs/pull/334

[subzero10]

reload the plugins when the corresponding config option changes (core package)

Have you thought about this? What if we added a property on the Plugin type, such as shouldReloadOnConfigChange or something like it?

[BethanyBerkowitz]

reload the plugins when the corresponding config option changes (core package)

Have you thought about this? What if we added a property on the Plugin type, such as shouldReloadOnConfigChange or something like it?

Yes, that's what I was thinking! Just a boolean (default false) for whether to reload or not.

Another option would be to add an array of config keys that should cause a reload. We'd load everything the first time (ie when __pluginsExecuted is false. Then reload only if one of the designated keys was passed in to the configure() function. This would be more complex and I doubt that users are calling configure() all that often... so it seems like maybe over-optimizing.

[subzero10]

Just a boolean (default false) for whether to reload or not.

I would prefer this option over the other, simply because we are letting the plugin itself decide whether it should be reloaded or not. Having a an array of config keys could be easily forgotten when updating or creating a plugin.