We use the @sentry/browser npm package at work, and communicate with it via ports. But doing it entirely in Elm looks nice since @sentry/browser is a pretty heavy module.
Do you use this in production? How is it working out so far?
Do you miss breadcrumbs?
Do you miss catching of JS errors, such as Elm’s virtual DOM “crashing” when people use some browser extensions, or when there’s a mistake in some port code throwing an error? Maybe it’s possible to manually add window.onerror and send stuff into Elm so elm-sentry can report it…
Is Sentry grouping the errors nicely for you? Sentry groups errors by their “fingerprint” – same fingerprint, same group. The default fingerprinting looks at stack traces. That turned out to work really badly for Elm code – our errors were grouped seemingly randomly. So we started manually assigning fingerprints to all errors we sent from Elm (which works great!). Do you know how that works with your package?
To be honest, I haven’t integrated with Sentry in my current app, not via JS or ELM. I built this to start using it, and improve it overtime while reading the sentry docs. I think this is a good 1.0 version because it covers at least the basic thing, which is, to report an error with a context and some extra data defined by you.
I will use it in production.
I haven’t used breadcrumbs.
I think that’s a good idea, to try to catch the error in Sentry with a Port, but you need to take into account if the app doesn’t even load, so no elm application/elm-sentry to use.
According to the documentation, my package will use the context to group errors, more specifically, it will use a Tag and a context, so it will be searchable in the UI. If you define extra-data and calculate a fingerprint, I think is also searchable but haven’t tested it