[Call for Feedback] Roadmap to Sentry JavaScript SDK v7

[kamilogorek]

¡Hola amigos!

Sentry helps every developer diagnose and fix their code. We are planning to start work on a new major version of the JavaScript SDK and we want to make it our best piece of software to date.

However, to do that, we need some feedback from you.

What are the biggest pain points when using the SDK?
What features are you missing the most?
What would you like to be changed?

We already plan to tackle some of the issues listed below:

• drop support for IE10 and officially-deprecated Node versions
• drastically reduce overall bundle size
• make the SDK more modularized
• improve tree-shaking compatibility
• rework integrations/extensions to work better with multiple clients

Help us help you, and let us know your thoughts! We'll make sure to answer all the comments, so every voice matters.

Cheers!
Kamil

[alexcroox]

My biggest gripe was always that my error logging library is one of my largest third party libraries. I've often considered lazy loading Sentry 5-10 seconds after first page load to get a better page speed score so I’m very excited you are addressing this ❤️

[jaylinski]

For me the drastically reduce overall bundle size-goal is also the most important one.

[radex]

Hi,

drastically reduce overall bundle size

I'm +1'ing this, in case this changes anything. And I'll add this: in my web app, Sentry initialization takes 30ms (on a fast computer), which is way too much for a diagnostics logger, and in the React Native app, it's significantly worse, because its bundler (Metro) is not capable of tree shaking, so Sentry imports a whopping 78 files, and also measurably contributes (a few %) to startup time.

[radex]

Hi, just some data from React Native:

This is profiled on an iPhone X. Sentry takes a whopping 54ms at launch - ~40 just to import the bulk of the files, ~15 to initialize JS code. Add to that ~30ms blocking the main thread to initialize native side, and there's some time unaccounted for in lexing/parsing Sentry's JS (of which there's a lot) - i suspect 5-15ms, but haven't measured precisely. In total - 90-100ms - that's 15% of the total time to launch my app!

[thmclellan]

Great question! I'd like to see more flexible logging options (or how to docs) for production apps where you don't want to expose the user to any console.log's, but you do want them captured as breadcrumbs. This could solve for issues like getsentry/sentry#12618 and #1883.

Maybe Sentry breadcrumbs could integrate with a logging library like debug or loglevel. This seems like a common use case for production apps, and maybe it's supported with some DIY approaches already, but it's not really clear if this is possible based on the current docs. (Or if it is and I somehow missed it, then I'd be grateful any tips). Thanks!

[ertant]

Hi, i have a recommendation about initialization of SDK.

Instead of calling Sentry.init with options, SDK can be automatically check an SentryOptions like named global variable to fetch DSN id and other options.

We are dynamically loading JS files when required and It's hard to track load event of bundle js in cross domain requests or networking issues. Automatically checking this variable would helpful to this and no need to exclusively call to init function.

[piotr-cz]

SDK failed to send event indication

I'd like to have some sort of indication that the capureEvent failed to send a request - so it could be queued up and retried later.

This would be really helpful for offline-first apps (progressive web apps).

There are situations when browser is in online state, but network request fails due to flaky connection/ timeout (ie. travelling trough areas with poor network coverage).

There is an Offline integration however it relies on the Online and Offline events which is not enough to cover that case.

Network errors may cause application that doesn't consider such situation to throw errors which fail to be logged by Sentry and just disappear in the void.

[edelvalle]

I have a project that is a PWA and I don't get events when the app is offline, and there is no way to do a background sync in the service worker, because is not registered for the sentry ingest domain.

[piotr-cz]

@edelvalle
This should be possible with Workbox and it's Background Sync plugin , however I didn't test it yet
It seems to work fine, also event date is as of when error occurred.

// service-worker.js
import { registerRoute } from 'workbox-routing'
import { NetworkOnly } from 'workbox-strategies'
import { BackgroundSyncPlugin } from 'workbox-background-sync'

registerRoute(
  new RegExp('^https://[^\\.]+\\.ingest\\.sentry\\.io/api/.*$'),
  new NetworkOnly({
    plugins: [
      new BackgroundSyncPlugin('project-name/sentry-event-queue', {
        maxRetentionTime: 7 * 24 * 60, // 7 days
      })
    ],
  }),
  'POST'
)

[chrsep]

Hi, love to see drastically reduce overall bundle size is planned. We have a gatsby+preact project and sentry takes up ~28% of our main bundle size (27kb out of 95kb). We are trying to bring our per page js bundle under 90kb so our app can perform better in rural areas with bad connections. A drastically smaller sentry SDK size would help a lot.

[xr0master]

Why not drop IE11 support either? Many large sites, including Microsoft, will end support for this browser by the end of the year. Of course the question is if this really affects the size of the library.

[hakimio]

@kamilogorek any idea when v6 might be coming?

I also agree with @xr0master and think IE support should be dropped entirely including IE11 in the new version.

[EtienneBruines]

What are the biggest pain points when using the SDK?

• Importing. But I guess that goes right along with "tree shakability", or modularity.

// This is not nice, as it doesn't get auto-completion when importing
import * as Sentry from '@sentry/browser'

// This is better, but has given me problems on Sentry 5.x
import { captureException } from '@sentry/browser'

• Call-stack debugging. It might be obvious from the perspective of how Sentry is implemented, but every console.log seems to originate from instruments.js:1, which isn't helpful during debugging. Since console.trace is overkill, I end up writing breadcrumbs manually in my console.log to get information about what is currently logging.

[OmgImAlexis]

What features are you missing the most?

Support for health.

[kibertoad]

Are there plans for using AsyncLocalStorage on Node versions that support it?

[HazAT]

So we shipped 6.0.0 today, with no major changes besides sending session data by default. cc @OmgImAlexis
I changed the title of this issue to v7 which should better reflect that.

[fsateler]

It would be awesome to expose the framework integrations separately from Sentry.init. This would address #3232 , in which Vue is loaded lazily, and thus is not guaranteed to exist at sentry initialization time. Something like Sentry.configureVue(Vue) which can be called at Vue load time.

[edzis]

react-router integration to support loading and unloading a secondary react app inside the same document with lazy invocation, using it's own router and more specific routes

[sandhose]

One of my biggest blocker for fully adopting Sentry for tracing in my org is missing integration with the OpenTelemetry ecosystem.
We publish many libraries, in which it makes a lot more sense to adopt tracing based on the OpenTelemetry SDK rather than on the Sentry SDK, but in our end-user apps (that make heavy use of those libraries), we want to use Sentry-based tracing. If there was a span processor or an exporter that made the bridge between the OTEL ecosystem and Sentry so that spans created with the OTEL SDK are caught by Sentry, it would help a lot. The other way around does not necessarily make sense IMHO.

[qilin000]

Hey guys, do we roughly have an idea when Sentry JavaScript SDK v7 is going to release? We need this fix badly:

rework integrations/extensions to work better with multiple clients

thanks!

[jbarker47]

We are adding Sentry to our React apps and have run into an issue that prevents multiple clients from working on the same page (why is there only a single Carrier / Hub on the global / window and why do events only go to the last-added Client / Scope)?

It's good to see that this is on your roadmap for v7, but since this may not come out for a while (only 12% complete in last 6 months) are there any recommended workarounds for this?

We are investigating possibly creating customized versions of the various Integrations like GlobalHandlers and TryCatch to manually traverse the private Hub stack inside the event listener callback, and try to find the "correct" client by matching a custom tag in the corresponding scope to a targetScope passed in to the custom integration during instantiation, but not sure if this will work. Any thoughts?

Also, not sure if this is currently possible, but it would be really helpful if errors events could be scoped to either the entire page or just specific sub-sections. Right now we're thinking we'll have to manually inspect the DOM inside our custom Integration to see if the target event is a child of the specified ancestor node, which is not ideal. Is there a better way to do this?

[kamilogorek]

It's good to see that this is on your roadmap for v7, but since this may not come out for a while (only 12% complete in last 6 months) are there any recommended workarounds for this?

We are aiming to release v7 early Q2. This 12% meter is not used in any way, and we only use it to categorize some issues, so no worries :)

Reworking integrations/multiple-clients experience and bundle size are the main areas of focus, and they both will definitely be solved.

[minonl]

react-router 6 intergration, maybe Sentry.reactRouterV6Instrumentation

[jmfrancois]

On our side we deploy our apps using CDN.
In sdk v5 it was easy to setup. But with v6 integrations are not available in CDN mode.
The only option for us is to build our own bundle of sentry and deploy it.
I do so to start sentry before the App to catch more potential errors (this is still JS and we dont want blank page).

[EtienneBruines]

On our side we deploy our apps using CDN.
In sdk v5 it was easy to setup. But with v6 integrations are not available in CDN mode.
The only option for us is to build our own bundle of sentry and deploy it.
I do so to start sentry before the App to catch more potential errors (this is still JS and we dont want blank page).

That raises an interesting point.

Would be nice if there was some modular part that we could load that "just" catches the errors, queueing them for processing and sending off to the server, and then at a later point in time (whenever we want to, e.g. window.requestIdleCallback) we can parse the JS-file that actually knows how to handle this data. The "retrieving" of errors is what is crucial and needs to be initialized before other code runs, but how they are handled could happen later at a less time-critical moment. Lots of people won't mind their errors being sent a few seconds later when the page is all settled, as long as the important on-load errors are caught reliably.

[geoffharcourt]

A few things related to noise:

• being able to more easily define what browsers you don't want to collect reports from at the browser side. I don't want to rack up events that count against my API count for unsupported browsers
• better filtering for known noisy exceptions that are unactionable
• make it easier to filter out reports from non-HTTP sources (we get exceptions from people/bots downloading our source and then the JS failing there)

[Tofandel]

@EtienneBruines This separate sentry bundle could even be included in a service worker

[prewk]

@OmgImAlexis

What features are you missing the most?

Support for health.

I was under the impression that it already supports health: https://docs.sentry.io/platforms/javascript/configuration/releases/#release-health

...but I can't make it work in our stand-alone environment. It's just not showing up even though I'm sending trace/sessions. Are you having the same problem as me?

This is of course not a support thread, but if health indeed is missing then I would love for it to happen in v7 as well. (Sorry for bloating the thread)

[StephanBijzitter]

Why not drop IE11 support either? Many large sites, including Microsoft, will end support for this browser by the end of the year. Of course the question is if this really affects the size of the library.

And if this is not an option but it would drastically reduce size, perhaps an alternative would be to make IE11 support optional by means of a plugin/integration?

[OmgImAlexis]

This is of course not a support thread, but if health indeed is missing then I would love for it to happen in v7 as well. (Sorry for bloating the thread)

It's not added they really need to update their advertising to show it's not available yet.

[squidsoup]

Support for react router v6 would be nice. The top level router in v6 no longer takes a history prop, which no doubt complicates matters.

[kamilogorek]

Health is already released in JS SDK and is coming to Node.js soon (it's already opt-in, which we play around with):

https://blog.sentry.io/2021/01/27/track-session-data-with-sentry-for-javascript
https://blog.sentry.io/2021/02/23/3-ways-to-improve-javascript-applications#release-health---so-you-can-rest-easy
https://docs.sentry.io/platforms/javascript/configuration/releases/#release-health

[prewk]

@kamilogorek Thanks, are you sure it's on self-hosted Sentry yet? We're running self-hosted 21.3.0 and @sentry/angular with @sentry/tracing both at 6.2.1. No release health even though we've got session tracking and performance metrics etc.

[chadwhitacre]

We're running self-hosted 21.3.0

@prewk That's a couple months out of date. I did a quick check and I'm almost positive that self-hosted should be able to process release health info. I would say try upgrading and if that doesn't resolve it then take it up in the forums/discord/onpremise repo.

[feross]

@kamilogorek What's the ETA on releasing v7 with a drastically reduced bundle size? The sentry bundle size is currently our biggest gripe with Sentry and it's measurably impacting our website's performance.

[adarnon]

Sentry Node pretty serious flaws with async-await. In servers like Next that support async-await in API routes, Sentry doesn't properly track the call stack and all logs/breadcrumbs pollute each other when multiple requests are being processed at the same time. I believe this is due to the dependency on the deprecated node domain module.

[jpike88]

Issues like #3660 and #3659 should take precedence over all the other nice-to-haves. This library is not on the same level of usability or functionality as sentry's key competitors in the APM space, and it needs to get the basics locked down.

[kamilogorek]

@jpike88 you already commented on how inconvenient the SDK is multiple times within one hour. We hear you, and we are working on it :)

[Kocal]

Support for Vue 3 👀

[pragmaticivan]

OpenTelemetry support would be great. The go lib has something already: https://levelup.gitconnected.com/golang-opentelemetry-and-sentry-the-underrated-distributed-tracing-stack-69dcda886ffe

[eoinpayne]

It's good to see that this is on your roadmap for v7, but since this may not come out for a while (only 12% complete in last 6 months) are there any recommended workarounds for this?

We are aiming to release v7 early Q2. This 12% meter is not used in any way, and we only use it to categorize some issues, so no worries :)

Reworking integrations/multiple-clients experience and bundle size are the main areas of focus, and they both will definitely be solved.

Hello! Just wondering if there is any update on the timeline for when v7 can be expected?

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[osdiab]

lol; guess version 7 isn't coming

[AbhiPrasad]

Hey folks, I know it's been a long while, but we've finally got a plan for what the major bump release will look like: #4240. Please leave feedback for the plan in that issue!

No timeline for this atm, but we will be actively working on this going forward.

For those concerned with bundle size/better treeshaking support, we've created a seperate milestone to track that: https://github.com/getsentry/sentry-javascript/milestone/11

[AdamZaczek]

Just an update from another dev team.
We used to use sentry in all of our apps and love the service but we will not add it to new apps because of the bundle size.

Logic is simple here.
Slow apps = bad user experience
User experience > dev experience