search

getsentry / sentry-javascript

Official Sentry SDKs for JavaScript
https://sentry.io
MIT License
7.87k stars 1.55k forks source link

Stop vendoring web vitals library #11186

Open AbhiPrasad opened 6 months ago

AbhiPrasad commented 6 months ago

When we first introduced frontend performance monitoring to the SDK we made the decision to vendor in web vitals library: https://github.com/GoogleChrome/web-vitals/.

https://github.com/getsentry/sentry-javascript/blob/a99f26051550c727a6dd94a479f4457fb15e10f3/packages/tracing-internal/src/browser/web-vitals/README.md

This was for a couple of reasons:

  1. Dependencies have a cost and we wanted to avoid introducing that to the SDK
  2. We didn't support some features like BFCache and multiple reports
  3. We didn't need all the metrics instrumentation exposed by that library

Today this looks very different. With https://github.com/getsentry/sentry-javascript/pull/11185 we basically rely on every single metric that the library exposes, and with sentry metrics we can potentially flush these metrics outside of a transaction (so BFCache support and multiple reports get vastly more useful).

Today we frequently fall behind on updating our vendored fork, which means our users don't get bug fixes or improvements in a timely manner.

It's also costing us to vendor this in - we maintain a slightly different implementation which means touching this code gets very complicated, very quickly. it also means adding support for things like attributions is very difficult.

I propose we stop vendoring web vitals entirely, and just rely on it as an npm dependency OR change the nature of the fork to mean we maintain @sentry-internal/web-vitals. Given there are no notable changes that we need to make to the vendored lib, I think the first option is the best, but open for discussion.

AbhiPrasad commented 6 months ago

The decision we make on this slightly blocks https://github.com/getsentry/sentry-javascript/issues/9885