[Call for Feedback] Roadmap to Sentry JavaScript SDK v7

¡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

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 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!

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

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

@kamilogorek

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

@prewk

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.

@kamilogorek

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

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.

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.

@jpike88

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

Support for Vue 3 👀

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

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?

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 🥀

lol; guess version 7 isn't coming

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

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

Navigation Menu

Repository navigation

[Call for Feedback] Roadmap to Sentry JavaScript SDK v7 #2817

¡Hola amigos!

24 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[Call for Feedback] Roadmap to Sentry JavaScript SDK v7 #2817

Description

¡Hola amigos!

Activity

alexcroox commented on Aug 13, 2020

jaylinski commented on Aug 14, 2020

radex commented on Aug 24, 2020

radex commented on Aug 26, 2020

thmclellan commented on Aug 26, 2020

ertant commented on Aug 27, 2020

piotr-cz commented on Sep 10, 2020

edelvalle commented on Sep 22, 2020

piotr-cz commented on Sep 22, 2020

chrsep commented on Sep 29, 2020

24 remaining items

prewk commented on May 19, 2021

chadwhitacre commented on May 19, 2021

feross commented on Jun 1, 2021

adarnon commented on Jun 5, 2021

jpike88 commented on Jun 9, 2021

kamilogorek commented on Jun 9, 2021

Kocal commented on Jun 11, 2021

pragmaticivan commented on Jun 28, 2021

eoinpayne commented on Aug 5, 2021

github-actions commented on Oct 14, 2021

osdiab commented on Oct 22, 2021

AbhiPrasad commented on Dec 6, 2021

AdamZaczek commented on Dec 9, 2021

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions