Rafał Chłodnicki

There are limitations on what can be done given how Nuxt modules work. While we would likely be able to toggle the "initialize" option based on runtime config, we are...

Just checked and yes, errors from `fetch()` are not caught. Nuxt catches those itself and exposes on `this.$fetchState.error` so Sentry would have to have some extra logic to capture those.

@pi0 any suggestions here? I see that Nuxt sets the error on `this.$fetchState.error` and `nuxt.error` so in theory I could watch those somehow but I think it would cleaner if...

Actually, I couldn't watch that property as there is no reactivity on the server-side. Also, that error is normalized and I would need the original error.

Is there some existing code like that that I could take inspiration from? It wouldn't be hard to just call `vm.$root.onFetchError` if it exists but if it's a simple function...

It would have to be done using the `beforeSend` hook, as shown in one of the examples in the documentation but it won't work currently because there is no way...

A little hacky for my liking but true, it's an option. But probably I would just do a truthy check `Sentry?.showReportDialog` instead of `Sentry?.showReportDialog != null` as we don't want...

> That is covered because `null == undefined`, so a `!= null` condition matches both. Fair but that's IMO bad practice since you are seemingly checking against a specific value...

Personally I'd prefer to use loose truthiness check `if (property)` then something that looks almost like a strict check but isn't (`if (property != null)`). Of course if I'm checking...

> @rchl is there a possibility of having Sentry as a peer dependancy so this module doesn't need to be re-published every time they make a release? `npm` (and `yarn`...