Sentry within a NPM library

Hi!

We are a small team that is developing a private NPM library used by several products in a larger organization. The library will then be bundled in different web applications that is connected to different Sentry projects (within the same “organization”).

What might be the best way for our team to keep track of the errors occurred in this library?

Our first approach was to create a scoped instance of Raven client in our library that reported to a “project” owned by our team. The code is however minified and it doesn’t seem to be a way to connect multiple sourcemaps.

We’re currently looking at @sentry/minimal but I can’t get my head around how this will help my team to collect the errors connected to the library.

Thanks!

I’m almost in the same “ship”…

What I’ve been doing is a lot of try ... catch blocks, whenever we think it’s a culprit for fail and on catch, just call a log.external(err, ... options)

there we simply call a REST endpoint and create our “bug”

as we can’t use any library by default, as it will catch all errors on a website, and all we want is to catch error on our own library, as we’re “just” a javascript file the client appends to their website.

The initial motivation for @sentry/minimal was a bit different.
It was meant for you, as a library dev, to have it as a dependency and make calls to Sentry.* as usual.
But it wouldn’t send anything to you as a library dev, instead if someone would use Sentry in their app and also uses your lib they would have a better experience if you for example have Sentry.addBreadcrumb in you lib.
Does this make sense?

It’s a bit trickier what you are trying to achieve. You would need to create a Client (I would not recommend hooking into global errors since it would influence someones app using your lib and you would get their errors as well).
See: https://docs.sentry.io/platforms/javascript/advance-settings/#using-a-client-directly

And then do what @balexandre said, have try/catch blocks and call captureException with your Client.

@HazAT Sorry to wake this thread but is this still the recommended way two years later?