[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'
)