Create @automattic/sentry package

[p-jackson]

Proposed Changes

Moving the code at client/lib/sentry to @automattic/sentry so that other packages can send messages and exceptions to Sentry.

This idea spawned from #66061 where I wanted to catch an asynchronous exception and make sure it got funneled to Sentry. The functions in client/lib/sentry allow this, however the code where the exception is handled is in @automattic/components and so it can't import the Sentry library.

This PR creates a new @automattic/sentry package and copies the client lib code into it.

There's probably a way to decouple the initSentry() code from the captureException() code so that users of this package only have to bundle the bare minimum of code. But I think this is a good simple first approach.

Testing Instructions

Pre-merge Checklist

• [ ] Have you written new tests for your changes?
• [ ] Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• [ ] Have you checked for TypeScript, React or other console errors?
• [ ] Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• [ ] Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?

Related to #66061

[github-actions[bot]]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-39618

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-39618&env=jetpack

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~202 bytes added 📈 [gzipped])

name        parsed_size           gzip_size
entry-main       +211 B  (+0.0%)     +202 B  (+0.1%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[noahtallen]

This is really interesting, thanks for working on it!

My concern is that Sentry is by definition tied to the Calypso application. The config we have is specific to running on wordpress.com, etc. This config shouldn't be used in wp-admin, in ETK, for example.

But if it's exposed as a package, wouldn't that allow for a scenario where package A uses the sentry lib, ETK uses package A, and then we get two instances of Sentry running in wp-admin? (ETK already bootstraps its own instance.)

Plus, if we're using the components package outside of Calypso across Automattic, we probably don't want calypso's sentry version to be loaded there. (And we definitely don't want that for 3rd party consumers.)

I'm not sure if there's an easy way to solve that with this approach. 🤔

[p-jackson]

Thanks @noahtallen those are good points. The initSentry is binding event listeners to window, so it really is more of an app-level concern. The reason I think it's worth trying is that the alternative is a lot of prop drilling: if a component in @automattic/components might raise an error then it'll have to accept an onError prop, and the Calypso code will have to pass the captureException function all the way down through various onError props. I don't think many people could be bothered doing that, so I want it to be as easy as possible to capture the exception.

I've given it another try

• @automattic/sentry only has method shims
• most of the code (especially Calypso config) is still in lib/sentry
• coupling between the package and lib/sentry is as loose as possible

So if the captureException function is called outside a Calypso environment it's a noop.

If we only had to support React then another idea is to use context to provide the dispatchSentryMethodCall method. That'd address the prop drilling case I mentioned above. But the way I've done it is useful for non-React situations.

[noahtallen]

Yeah, that's a good point. We did use filters for a similar use case (capturing Gutenberg errors within React error boundaries), but that was really the only viable solution for integration with Gutenberg.

A benefit of this approach is that we can define window.a8cSentryCallQueue in our other environments (like ETK in wp-admin), so this would work with whichever Sentry implementation is available

[p-jackson]

I'm not quite sure about the cleanest way to do this. I'll just leave it for now. Next time a need comes up it might be more obvious what to do.

[noahtallen]

Ok! It's definitely an interesting problem. Maybe at some point we (@Automattic/team-calypso-platform) could think about how to have a sharable Sentry library which can connect to the running sentry instance on any platform :)