Sentry-javascript: [Call for Feedback] Roadmap to Sentry JavaScript SDK v7

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 ❤️

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

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.

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!

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 https://github.com/getsentry/sentry/issues/12618 and https://github.com/getsentry/sentry-javascript/issues/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!

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.

_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.

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.

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

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.

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.

@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.

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.

What features are you missing the most?

Support for health.

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

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.

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.

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