Sentry-javascript: [Solicitud de comentarios] Hoja de ruta para Sentry JavaScript SDK v7

Creado en 13 ago. 2020  ·  18Comentarios  ·  Fuente: getsentry/sentry-javascript

¡Hola amigos!

Sentry ayuda a todos los desarrolladores a diagnosticar y corregir su código. Estamos planeando comenzar a trabajar en una nueva versión principal del SDK de JavaScript y queremos convertirlo en nuestro mejor software hasta la fecha.

Sin embargo, para hacer eso, necesitamos algunos comentarios de usted.

_¿Cuáles son los mayores puntos débiles al usar el SDK?_
_¿Qué características echas más de menos?_
_¿Qué te gustaría que cambiara?_

Ya planeamos abordar algunos de los problemas que se enumeran a continuación:

  • elimine el soporte para IE10 y las versiones de Node obsoletas oficialmente
  • reducir drásticamente el tamaño total del paquete
  • hacer que el SDK sea más modularizado
  • mejorar la compatibilidad con el movimiento de árboles
  • reelaborar integraciones/extensiones para trabajar mejor con múltiples clientes

¡Ayúdenos a ayudarlo y háganos saber sus pensamientos! Nos aseguraremos de responder a todos los comentarios, por lo que cada voz importa.

¡Salud!
kamil

Breaking Discussion

Comentario más útil

Para mí, el objetivo de drastically reduce overall bundle size es también el más importante.

Todos 18 comentarios

Mi mayor queja siempre fue que mi biblioteca de registro de errores es una de mis bibliotecas de terceros más grandes. A menudo he considerado la carga diferida de Sentry de 5 a 10 segundos después de la carga de la primera página para obtener una mejor puntuación de velocidad de página, así que estoy muy emocionado de que esté abordando esto ❤️

Para mí, el objetivo de drastically reduce overall bundle size es también el más importante.

Hola,

reducir drásticamente el tamaño total del paquete

Estoy haciendo +1 en esto, en caso de que esto cambie algo. Y agregaré esto: en mi aplicación web , la inicialización de Sentry toma 30 ms (en una computadora rápida), lo cual es demasiado para un registrador de diagnóstico, y en la aplicación React Native, es significativamente peor, porque su paquete (Metro) no es capaz de sacudir el árbol, por lo que Sentry importa la friolera de _78 archivos_, y también contribuye considerablemente (un pequeño %) al tiempo de inicio.

Hola, solo algunos datos de React Native:

image

Esto está perfilado en un iPhone X. Sentry tarda 54 ms en el lanzamiento: ~ 40 solo para importar la mayor parte de los archivos, ~ 15 para inicializar el código JS. Agregue a eso ~ 30 ms bloqueando el hilo principal para inicializar el lado _native_, y hay algo de tiempo no contabilizado en lexing/analizar JS de Sentry (del cual hay mucho): sospecho que 5-15 ms, pero no lo he medido con precisión. En total, 90-100 ms, ¡eso es el 15 % del tiempo total para iniciar mi aplicación!

¡Gran pregunta! Me gustaría ver opciones de registro más flexibles (o cómo hacer documentos) para aplicaciones de producción en las que no desea exponer al usuario a ningún archivo console.log, pero sí desea que se capturen como migas de pan. Esto podría resolver problemas como https://github.com/getsentry/sentry/issues/12618 y https://github.com/getsentry/sentry-javascript/issues/1883.

Tal vez las migas de pan Sentry podrían integrarse con una biblioteca de registro como debug o loglevel . Esto parece un caso de uso común para las aplicaciones de producción, y tal vez ya sea compatible con algunos enfoques de bricolaje, pero no está muy claro si esto es posible según los documentos actuales. (O si lo es y de alguna manera me lo perdí, entonces agradecería cualquier consejo). ¡Gracias!

Hola, tengo una recomendación sobre la inicialización de SDK.

En lugar de llamar a Sentry.init con opciones, SDK puede verificar automáticamente una SentryOptions como una variable global con nombre para obtener la identificación de DSN y otras opciones.

Estamos cargando archivos JS dinámicamente cuando es necesario y es difícil rastrear el evento de carga del paquete js en solicitudes de dominio cruzado o problemas de red. Verificar automáticamente esta variable sería útil para esto y no es necesario llamar exclusivamente a la función de inicio.

_SDK no pudo enviar la indicación de evento_

Me gustaría tener algún tipo de indicación de que capureEvent no pudo enviar una solicitud, por lo que podría ponerse en cola y volver a intentarlo más tarde.

Esto sería realmente útil para las primeras aplicaciones fuera de línea (aplicaciones web progresivas).

Hay situaciones en las que el navegador está en línea, pero la solicitud de la red falla debido a una conexión inestable/tiempo de espera (es decir, viajar a través de áreas con poca cobertura de red).

Hay una integración fuera de línea, sin embargo, se basa en los eventos en

Los errores de red pueden causar que la aplicación que no considere tal situación arroje errores que Sentry no pueda registrar y simplemente desaparezcan en el vacío.

Tengo un proyecto que es un PWA y no obtengo eventos cuando la aplicación está fuera de línea, y no hay forma de realizar una sincronización en segundo plano en el trabajador del servicio, porque no está registrado para el dominio de ingesta de Sentry.

@edelvalle
Esto debería ser posible con Workbox y su complemento de sincronización de fondo ~, sin embargo, aún no lo probé ~
Parece funcionar bien, también la fecha del evento es a partir de cuando ocurrió el error.

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

Hola, me encantaría ver que drastically reduce overall bundle size está planeado. Tenemos un proyecto gatsby+preact y sentry ocupa ~28% del tamaño de nuestro paquete principal (27kb de 95kb). Estamos tratando de llevar nuestro paquete js por página a menos de 90 kb para que nuestra aplicación pueda funcionar mejor en áreas rurales con malas conexiones. Un SDK centinela drásticamente más pequeño ayudaría mucho.

¿Por qué no eliminar el soporte de IE11 tampoco? Muchos sitios grandes, incluido Microsoft, dejarán de admitir este navegador a finales de año. Por supuesto, la pregunta es si esto realmente afecta el tamaño de la biblioteca.

@kamilogorek, ¿ alguna idea de cuándo podría llegar v6?

También estoy de acuerdo con @ xr0master y creo que la compatibilidad con IE debería eliminarse por completo, incluido IE11 en la nueva versión.

¿Cuáles son los mayores puntos débiles al usar el SDK?

  • Importador. Pero supongo que eso va junto con la "capacidad de sacudir el árbol" o la modularidad.
// 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'
  • Depuración de pila de llamadas. Puede ser obvio desde la perspectiva de cómo se implementa Sentry, pero cada console.log parece originarse en instruments.js:1 , lo que no es útil durante la depuración. Dado que console.trace es excesivo, termino escribiendo migas de pan manualmente en mi console.log para obtener información sobre lo que se está registrando actualmente.

¿Qué características echas más de menos?

Apoyo a la salud .

¿Hay planes para usar AsyncLocalStorage en versiones de Node que lo admitan?

Así que enviamos 6.0.0 hoy, sin cambios importantes además de enviar datos de sesión de forma predeterminada. cc @OmgImAlexis
Cambié el título de este problema a v7, que debería reflejarlo mejor.

Sería increíble exponer las integraciones del marco por separado de Sentry.init . Esto abordaría #3232 , en el que Vue se carga de forma perezosa y, por lo tanto, no se garantiza que exista en el momento de la inicialización del centinela. Algo así como Sentry.configureVue(Vue) que se puede llamar en el momento de la carga de Vue.

Integración de enrutador de reacción para admitir la carga y descarga de una aplicación de reacción secundaria dentro del mismo documento con invocación diferida, utilizando su propio enrutador y rutas más específicas

¿Fue útil esta página
0 / 5 - 0 calificaciones