Sentry-javascript: @centinela/tamaño del navegador

Oye, gracias por mencionar esto.
Si bien entendemos y generalmente estamos de acuerdo con sus inquietudes sobre el tamaño del paquete, creo que es justo comparar primero los tamaños del paquete gzip en lugar del tamaño del archivo minificado sin comprimir:

@sentry/browser es 21.3799 KB
raven-js 13.44 KB

Además, si bien es posible que esto no sea aplicable a todos, proporcionamos y, por lo general, guiamos a las personas para que usen nuestro CDN Loader, que configurará el SDK para usted en su sitio web.

ver: https://docs.sentry.io/quickstart/?platform=browser

La huella y el impacto en el tiempo de carga de la página de este script es <1 KB comprimido con gzip manteniendo la misma funcionalidad.

así que tl; dr:
Somos conscientes de ello, sabemos que hay margen de mejora, pero no es la máxima prioridad en este momento.

Creo que es justo comparar primero los tamaños de los paquetes gzip en lugar del tamaño del archivo minificado sin comprimir:

Yo diría que también es justo comparar tamaños minificados, ya que los problemas de rendimiento no solo surgen de la descarga de JavaScript, sino también del análisis y la ejecución. ~92kb es bastante pesado y podría agregar hasta 1 segundo de tiempo de análisis en dispositivos de gama baja (¡solo para esta biblioteca!).

No estoy seguro de dónde toma el número de < 1KB para el script de CDN. ¿Podría elaborar? Cuando abro https://browser.sentry-cdn.com/4.0.4/bundle.min.js , veo un tamaño comprimido de 22 KB.

Debe tener en cuenta que el SDK de Sentry es solo una de las muchas bibliotecas que incluyen los desarrolladores.

PD: Me encanta Sentry, ha sido de gran ayuda para nosotros. El rendimiento web es algo que me apasiona. ;)

@klaemo
Jeje, no te preocupes 😅

Como dije, somos conscientes y no es que no queramos que sea más pequeño.
El mayor prioridad para nosotros fue enviar el nuevo SDK, trabajaremos para mejorar el tamaño del paquete con el tiempo.
Hay muchos más pasos que podemos tomar, por ejemplo: usar tslib , combinar cadenas...
Así que hay mucho espacio para mejoras.

Lo siento, el enlace que publiqué antes ya está desactualizado 🙃
Me refería al _Loader_: https://docs.sentry.io/platforms/javascript/loader/
Si bien _Loader_ también tiene sus limitaciones debido a su naturaleza asíncrona y, al final, aún obtiene e inyecta el SDK (incluso si es asíncrono), es una alternativa que ofrecemos porque la gente lo solicitó.

@HazAT Lo siento, chicos, pero ¿pueden proporcionar la fecha de lanzamiento de la próxima versión?
Quiero decir, ya hay algunos cambios en la rama #master pero aún no se han lanzado. Sin embargo, ese está decidiendo que la versión 4x se puede usar para proyectos Angular5 +.

@rayzru Acabo de publicar 4.0.5 , pero mantenga las publicaciones relacionadas con el tema.

En mi opinión, esto es definitivamente una regresión y la seria razón para no actualizar a la nueva versión.

💯 Estaba a punto de actualizar hasta que noté que:

• antes: https://bundlephobia.com/[email protected]
• después: https://bundlephobia.com/result?p=@sentry/browser @4.0.1

Al menos el tamaño del paquete es más pequeño , pero creo que ⚠️ +10 KB de JavaScript comprimido con gzip en un paquete es significativo. Esperaremos, sigan con el buen trabajo :)

@HazAT ¿Podría ser posible generar archivos esm? Permitiría que el paquete web tuviera un mejor resultado con la concatenación y la sacudida del árbol.

Es posible que desee agregar alguna herramienta de CI para rastrear el tamaño del paquete para cada solicitud de combinación. Desde este problema, en realidad ha crecido a 100 kB, consulte https://bundlephobia.com/result?p=@sentry/browser @4.3.0

Pruebe, por ejemplo, https://github.com/siddharthkp/bundlesize

El presupuesto de rendimiento predeterminado para un punto de entrada en Webpack es de 250 kb para asegurarse de obtener un rendimiento decente en cualquier dispositivo y red. 100 kb de Sentry ocupan una gran parte de ese presupuesto.

Manténganos informados si arreglar esta regresión está en la hoja de ruta o si la biblioteca seguirá creciendo sin un presupuesto de tamaño.

Estamos pagando a los clientes e invertimos mucho en Sentry tanto en el backend, nativo como en la web, pero una actualización a más de 3 veces el tamaño de la biblioteca ([email protected] es 31 kB) no es algo que podamos justificar.

@jacobrask Puedes quedarte con la versión anterior de la biblioteca, es lo que hacemos en https://www.onepixel.com/ , funciona bien 👌.

@jacobrask Definitivamente está en nuestra lista y también creemos que hay algunas frutas al alcance de la mano en las que podemos reducir fácilmente el tamaño de nuestro paquete.
Cada vez más personas preguntan por esto, por lo que probablemente lo abordaremos antes de lo esperado.

@HazAT
El paquete acumulativo SDK del navegador Sentry se puede optimizar. En el archivo bundle min js, hay muchos códigos tslib repetidos. Como __generator, __assign. En Browser env, es mejor compartir un código. Pero el proyecto del navegador usa otro archivo dist de paquetes. Tal vez reduzca el tamaño de gzip de 23K a 16K.

El tamaño del paquete es el mismo en 4.3.2
https://bundlephobia.com/result?p=@sentry/browser @4.3.2 independientemente de los cambios de
https://github.com/getsentry/sentry-javascript/pull/1738 :(

@vkrol Tuvimos que revertir los cambios que hizo @gaterking , al menos para el paquete npm.
El paquete en CDN, por otro lado, debería ser más pequeño.

Seguramente volveremos a agregar los cambios, pero tenemos que hablar de ello, ya que necesitamos una dependencia de tslib por ejemplo.
También se rompió la forma en que se generaron los tipos.

@HazAT Está bien, gracias.

@vkrol Tuvimos que revertir los cambios que hizo @gaterking , al menos para el paquete npm.
El paquete en CDN, por otro lado, debería ser más pequeño.

Seguramente volveremos a agregar los cambios, pero tenemos que hablar de ello, ya que necesitamos una dependencia de tslib por ejemplo.
También se rompió la forma en que se generaron los tipos.

Espero lo antes posible.

@gaterking @kamilogorek Ya lo arregló https://github.com/getsentry/sentry-javascript/pull/1751
Solo teníamos que hacer un lanzamiento "urgente", por eso lo revertimos.

En el lado del cliente, básicamente quiero que esto capture los errores y los envíe a la API.

¿Qué más está haciendo esta biblioteca que es tan compleja?

Es realmente difícil entender por qué un informador de errores más simple necesita tener una huella tan importante 😐

@mindplay-dk Es principalmente porque JavaScript y los navegadores son un desastre ^^
Tenemos que arreglar mucho los rastros de pila rotos o incorrectos.
La simple tarea de "simplemente detectar errores" también es mucho más compleja de lo que parece.

Es realmente difícil entender por qué un informador de errores más simple necesita tener una huella tan importante 😐

@mindplay-dk porque no es simple.

Aquí está el código para capturar errores en todos los navegadores y unificarlos en una estructura de datos utilizable: https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/tracekit.ts

Bien hecho por la reciente reducción de tamaño, muy apreciada. 👍

Un vistazo rápido al archivo vinculado muestra el código para manejar errores para Opera 10, ¿realmente todavía es necesario? TraceKit tampoco tiene en cuenta el aumento de tamaño 2x (actualmente) de Raven, que ya era grande.

Algunas sugerencias:

• Quitar md5
• Reduzca el uso de async/await, se compila mal en ES5. Compare https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/baseclient.ts#L307 -L378 con el código de salida (busque "processEvent" en el paquete de producción). Todo ese archivo se vuelve enorme en el paquete de producción.

¿Hay algún código compartido ( app:///${base} en rewriteframes.ts) en otros paquetes como paquete/núcleo? No son utilizados por el cliente, sino por el nodo.

porque no es sencillo.

@kamilogorek , obviamente tienes razón... Me di cuenta de que JavaScript era un desastre. Supongo que nunca antes había investigado esta área, no me di cuenta de lo malo que era. Supongo que realmente no hay una forma sencilla de manejar los seguimientos de pila en JS. Sólo. ¡Ay! 😐

En lugar de simplemente intentar minimizar los ayudantes, podría simplemente proporcionar los archivos esm ya mencionados, eso es fácil e incluso una buena práctica hoy en día.

Reduzca el uso de async/await, se compila mal en ES5. Compare https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/baseclient.ts#L307 -L378 con el código de salida (busque "processEvent" en el paquete de producción). Todo ese archivo se vuelve enorme en el paquete de producción.

Esa es la forma incorrecta, en lugar de optimizar aún más para ES5, es más importante optimizar para 80.07% que usan navegadores modernos.

Para todos los que necesitan compatibilidad con navegadores antiguos:
Las funciones asincrónicas son compatibles con cualquier navegador que admita <script type="module"> ( caniuse : esm, async ), por lo que solo los usuarios de navegadores más antiguos deben esperar más (de todos modos, les lleva más tiempo)

Prueba:
160 KB (es5, incluido) > 119 KB (esm, archivos sin formato)

Así que empaque el archivo esm (también), es tan fácil como cambiar la configuración module y target en /tsconfig.esm.json (que se extiende tsconfig.build.json ) a esnext , agregar archivos tsconfig.esm.json similares a los archivos tsconfig.build.json a los paquetes, agregarlo a la compilación y al paquete y especificar una entrada de módulo en package.json

Si quieres, puedo agregar un PR para eso.

Si quieres, puedo agregar un PR para eso.

Me encantaría @cromefire :)

Sería increíble si hubiera una opción para seleccionar entre el modo clásico y moderno, como vue cli. Donde la versión moderna solo tiene soporte para la mayoría de los navegadores modernos y, por lo tanto, podría estar menos hinchada.

O incluso mejor si pudiera funcionar como webpack env, para que el usuario pudiera especificar el soporte del navegador necesario. Ofc, esta no es una característica fácil, pero solo quería lanzarla :)

¡Producto impresionante!

Con ese nuevo PR, puede configurar babel como quiera que admita solo los navegadores que necesita

El tamaño de @sentry/browser es más del doble del tamaño de raven-js: 86 kB frente a 39 kB (minificado).

FYI: el tamaño de la última versión de @sentry/browser ha aumentado a 91,8 kB . Fuente: https://bundlephobia.com/result?p=@sentry/browser @4.5.0.

@cromefire ¡ Gracias por su trabajo con la optimización del tamaño de la biblioteca!

Intenté usar la nueva compilación de esm de v4.5.0 pero recibí muchos errores. Todos ellos se activan porque los módulos de @sentry/utils/esm no se pudieron resolver.

De hecho, no encontré las carpetas en node_modules después de un yarn install nuevo. (Ver captura de pantalla)

 ERROR en ./node_modules/@sentry/core/esm/baseclient.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/async' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/browser/esm/backend.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/is' en './node_modules/@sentry/browser/esm'

 ERROR en ./node_modules/@sentry/browser/esm/tracekit.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/is' en './node_modules/@sentry/browser/esm'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/is' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/is' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/pluggable/vue.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/is' en './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERROR en ./node_modules/@sentry/core/esm/baseclient.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/is' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/core/esm/dsn.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/is' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Módulo no encontrado: Error: no se puede resolver '@sentry/utils/esm/is' en './node_modules/@sentry/core/esm/integrations'

 ERROR en ./node_modules/@sentry/core/esm/integrations/extraerrordata.js

 Módulo no encontrado: Error: no se puede resolver '@sentry/utils/esm/is' en './node_modules/@sentry/core/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/globalhandlers.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/logger' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/logger' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/core/esm/baseclient.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/logger' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/core/esm/basebackend.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/logger' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/core/esm/sdk.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/logger' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/core/esm/integration.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/logger' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/core/esm/integrations/dedupe.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/logger' en './node_modules/@sentry/core/esm/integrations'

 ERROR en ./node_modules/@sentry/core/esm/integrations/sdkinformation.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/logger' en './node_modules/@sentry/core/esm/integrations'

 ERROR en ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/logger' en './node_modules/@sentry/core/esm/integrations'

 ERROR en ./node_modules/@sentry/hub/esm/hub.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/logger' en './node_modules/@sentry/hub/esm'

 ERROR en ./node_modules/@sentry/browser/esm/client.js

 Módulo no encontrado: Error: no se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/browser/esm'

 ERROR en ./node_modules/@sentry/browser/esm/tracekit.js

 Módulo no encontrado: Error: no se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/browser/esm'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/useragent.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/trycatch.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/pluggable/reportingobserver.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/pluggable/vue.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/pluggable/ember.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERROR en ./node_modules/@sentry/browser/esm/transports/beacon.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/browser/esm/transports'

 ERROR en ./node_modules/@sentry/browser/esm/transports/fetch.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/browser/esm/transports'

 ERROR en ./node_modules/@sentry/core/esm/baseclient.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/core/esm/integrations/dedupe.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/core/esm/integrations'

 ERROR en ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/core/esm/integrations'

 ERROR en ./node_modules/@sentry/hub/esm/scope.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/hub/esm'

 ERROR en ./node_modules/@sentry/hub/esm/hub.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/misc' en './node_modules/@sentry/hub/esm'

 ERROR en ./node_modules/@sentry/browser/esm/parsers.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/object' en './node_modules/@sentry/browser/esm'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/object' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/trycatch.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/object' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/object' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/core/esm/api.js

 Módulo no encontrado: Error: no se puede resolver '@sentry/utils/esm/object' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/core/esm/basebackend.js

 Módulo no encontrado: Error: no se puede resolver '@sentry/utils/esm/object' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/core/esm/dsn.js

 Módulo no encontrado: Error: no se puede resolver '@sentry/utils/esm/object' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/hub/esm/scope.js

 Módulo no encontrado: Error: no se puede resolver '@sentry/utils/esm/object' en './node_modules/@sentry/hub/esm'

 ERROR en ./node_modules/@sentry/core/esm/integrations/pluggable/rewriteframes.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/path' en './node_modules/@sentry/core/esm/integrations/pluggable'

 ERROR en ./node_modules/@sentry/browser/esm/parsers.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/string' en './node_modules/@sentry/browser/esm'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo no encontrado: Error: no se puede resolver '@sentry/utils/esm/string' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/core/esm/baseclient.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/string' en './node_modules/@sentry/core/esm'

 ERROR en ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/string' en './node_modules/@sentry/core/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/backend.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/supports' en './node_modules/@sentry/browser/esm'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/supports' en './node_modules/@sentry/browser/esm/integrations'

 ERROR en ./node_modules/@sentry/browser/esm/integrations/pluggable/reportingobserver.js

 Módulo no encontrado: Error: No se puede resolver '@sentry/utils/esm/supports' en './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERROR en ./node_modules/@sentry/browser/esm/transports/fetch.js

 Módulo no encontrado: Error: no se puede resolver '@sentry/utils/esm/supports' en './node_modules/@sentry/browser/esm/transports'

@pascaliske esm aún se encuentra en la fase de experimentación y aún no lo hemos documentado públicamente. Lo haremos una vez que todo esté probado y publicaremos nuestros hallazgos aquí.

@kamilogorek Sí, lo sé. Solo quería informarle de estos errores. 🙂

Gracias, lo aprecio @pascaliske! Intentaremos brindar soporte de ESM lo antes posible :)

@pascaliske prueba yarn build primero

@cromefire No, esto no ayudará, creo. Acabo de descargar el paquete de npm, por lo que no hay un entorno de compilación disponible. 🙂

Busqué un poco en el código fuente y comparé @sentry/browser con @sentry/utils . Creo que este es el problema: packages/utils/tsconfig.build.json#L5 vs. packages/browser/tsconfig.build.json#L5 . ¿Es posible que la salida de compilación normal sobrescriba la salida de compilación de esm? 🤔

Dentro de mi carpeta node_modules, el paquete browser contiene resultados de compilación tanto de normal como de esm. Pero el paquete utils solo contiene la salida de compilación normal en la carpeta raíz.

¿Ya está lanzado?

Busqué un poco en el código fuente y comparé @sentry/browser con @sentry/utils. Creo que este es el problema: packages/utils/tsconfig.build.json#L5 vs. packages/browser/tsconfig.build.json#L5 . ¿Es posible que la salida de compilación normal sobrescriba la salida de compilación de esm? 🤔

No, tienes que mirar el esm tsconfig

Lo mirare mañana

¡Oigan todos! También estamos investigando algunos de los tamaños de paquete en Sentry y encontramos esto: https://github.com/getsentry/sentry-javascript/blob/master/packages/minimal/package.json#L20

Parece que está agregando una porción de tamaño para muy pocas funciones (difundir y asignar). No estoy muy familiarizado con Typescript, pero ¿es necesario para esto en tiempo de ejecución?

Tampoco me queda claro por qué @sentry/types debe ser una dependencia de _runtime_ y no estar ubicado en devDependencies ...

@evocateur para todos los usuarios de mecanografiado esto es necesario. Typescript lo optimiza todo.
(pero puede ser necesario para los archivos .d.ts )

@IanMitchell No se usa para la compilación de esm, sino para las normales

El bundle.js de 4.5.0 contiene una gran cantidad de código duplicado, como Severity, htmlElementAsString, htmlElementAsString, uuid4, parseUrl, etc. ¡Esto no puede ser intencionado!

Lo mismo sucede cuando hago un paquete a través import * as Sentry from '@sentry/browser'; (como la única línea en el archivo) usando WebPack + Babel 7, entonces el tamaño del paquete es de 326kb. Ver: centinela.bundle.js.txt
También usamos la misma configuración para nuestros otros paquetes, pero Sentry es el único paquete con ese problema.

El paquete.min.js no tiene un código duplicado dentro , lo que puede ser el resultado de la sacudida del árbol con el resumen.

Entonces, una solución temporal es usar import '@sentry/browser/build/bundle.min.js';

El bundle.js de 4.5.0 contiene una gran cantidad de código duplicado, como Severity, htmlElementAsString, htmlElementAsString, uuid4, parseUrl, etc. ¡Esto no puede ser intencionado!

Esta es la razón (o es al menos una de las razones) por la que existe la compilación esm . Si tiene un paquete de todos modos, es más eficiente que usar un paquete precompilado. (Es solo beta y en este momento todavía está roto)

Mirando esto de nuevo, y no creo que esto no pueda ser más pequeño. Mucho más pequeña.

Stack-traces con soporte de mapa de origen debería ser, con mucho, lo más complejo en esta biblioteca, ¿y no parece que lo sea? Parece que la mayor parte de la huella proviene del marco central, que comparte con el cliente node.js, donde estoy seguro de que la huella no es realmente una preocupación.

No me malinterpreten, esta es una hermosa pieza de arquitectura: muy buen trabajo de TypeScript.

Pero en el lado del cliente, eso no significa mucho. Debe ser pequeño y cargar rápido, especialmente para algo de tan bajo nivel como este, realmente no importa si el código fuente es hermoso o no. Por lo que puedo decir, lo impresionante es que la arquitectura cuesta muchos bytes en el futuro.

Para comparacion:

Encontré TrackJS , que tiene capacidades similares (seguimiento de pila entre navegadores con mapas de origen) en un paquete de ~10 KB.

El TraceKit original es ~3KB min+gz.

Encontré esta biblioteca que puede hacer el bit del mapa de origen (en el lado del cliente) en ~ 8 KB min + gz o ~ 10 KB con polyfills del navegador x.

Más allá de eso, se trata de recopilar algunos bits de información del navegador, envolverlos en el formato JSON esperado y publicarlos, que no deberían tener más de unos pocos KB min+gz. ¿Deberia?

Siento que esto es mucho más arquitectura de lo que la mayoría de la gente necesita. Si necesito algún complemento compatible, tal vez necesite un enlace simple que me permita ingresar información en la publicación JSON, pero eso es todo.

Sé que es común implementar megabytes de JS en estos días, pero tenemos políticas de contenido estrictas en el trabajo, para garantizar que enviemos proyectos que se carguen rápido en dispositivos móviles, y no puedo justificar gastar más de la mitad de nuestro presupuesto de JS en errores. registro: tal vez un 10% como máximo, por lo que algo como ~ 15-20 KB parece razonable.

Me encanta su producto, pero no puedo implementar este cliente 😐

Para algo como esto, podría ser una buena idea delegar el seguimiento de la pila y el análisis del mapa de origen al servidor, donde el tamaño es irrelevante.

Para algo como esto, podría ser una buena idea delegar el seguimiento de la pila y el análisis del mapa de origen al servidor, donde el tamaño es irrelevante.

@cromefire idea interesante. Me pregunto si eso es lo que hace, por ejemplo, TrackJS para mantener el tamaño bajo. (Su cliente es propietario: solo está disponible la fuente minimizada, por lo que es difícil decir qué hacen. Supongamos que pudiera instalarlo y ver qué pasa por el cable...)

Aquí hay un paquete más simple para resolver mapas de origen en el navegador: source-map-resolve at ~2KB min+gz... eso es sin polyfills, pero (si esto funciona) creo que deberíamos poder llegar a ~10KB para navegadores modernos que no necesitan polyfills.

eso es sin polyfills

Polyfills no debería estar en la compilación esm , por lo que también podría funcionar, pero en el bachend sería aún menos

La compilación @cromefire ESM debería estar disponible en 4.5.1 ahora. Todavía no está documentado, ya que queremos asegurarnos de que esté probado en batalla, pero hasta ahora todo bien. Revisé la compilación regular del paquete web con babel loader y funciona de maravilla.

Más allá de eso, se trata de recopilar algunos bits de información del navegador, envolverlos en el formato JSON esperado y publicarlos, que no deberían tener más de unos pocos KB min+gz. ¿Deberia?

@mindplay-dk no realizamos ninguna resolución de seguimiento de pila en el lado del cliente. Todo se hace en el servidor, es por eso que necesita cargar mapas de origen en primer lugar para obtener soporte para ellos.

Sin embargo, lo que hacemos es:

• procesadores de eventos para proporcionar ganchos personalizados que le permitan modificar/filtrar/mejorar los datos enviados a Sentry
• ocúpese de todo el ajuste de la API nativa
• capturar migas de pan de todas las interacciones del usuario, llamadas de red, navegaciones
• extraer datos del agente de usuario
• extraiga datos de error adicionales de errores vinculados, para que pueda hacer niveles de error múltiple como en otros idiomas
• escuchar ambos controladores de errores globales
• proporcionar múltiples transportes de red, de modo que el usuario siempre obtenga el mejor para su entorno actual
• ocúpese de décimas de casos extremos y varios objetos de error (incluso personalizados) y varias implementaciones nativas
• proporcionar respaldos a la información de error de repuesto o rota
• amortiguar eventos para que no inunde su propia instancia de Sentry o se quede sin eventos gratuitos si algo sale mal

Sólo para nombrar unos pocos. Realmente desearía que fuera tan fácil como "atrapar el error, agregar algunos datos y enviarlo".
Sin embargo, en el mundo real, hay decenas de entradas, decenas de fuentes de las que puede provenir el error (que proporcionan datos diferentes) y decenas de entornos que varían en comportamiento.
Definitivamente seguiremos trabajando en cómo reducir esto a ~10-15kB, pero llevará algún tiempo. Solo tenemos tantos recursos (léase personas/tiempo) que podemos gastar ahora.

Sé que es común implementar megabytes de JS en estos días, pero tenemos políticas de contenido estrictas en el trabajo, para garantizar que enviemos proyectos que se carguen rápido en dispositivos móviles, y no puedo justificar gastar más de la mitad de nuestro presupuesto de JS en errores. registro: tal vez un 10% como máximo, por lo que algo como ~ 15-20 KB parece razonable.

Entonces puede usar nuestro cargador: https://docs.sentry.io/platforms/javascript/loader/ :)

Entonces puede usar nuestro cargador: https://docs.sentry.io/platforms/javascript/loader/ :)

Pero lamentablemente no hay solución para webpack.

Sólo para nombrar unos pocos. Realmente desearía que fuera tan fácil como "atrapar el error, agregar algunos datos y enviarlo".

Tal vez alguien debería proponer algo en tc39 . Tendría que ver cómo es el proceso, pero tal vez alguien podría proponer una API estandarizada para la lectura de stacktrace.

Pero lamentablemente no hay solución para webpack.

¿Qué quieres decir exactamente? ¿Tiene un paquete que podría coexistir con el cargador, que podría importarse y agruparse, pero luego comunicarse con el SDK cargado de forma asíncrona una vez que ocurre un error o una llamada de excepción de captura?

¿Qué quieres decir exactamente? ¿Tiene un paquete que podría coexistir con el cargador, que podría importarse y agruparse, pero luego comunicarse con el SDK cargado de forma asíncrona una vez que ocurre un error o una llamada de excepción de captura?

Sí, si recapitulo correctamente, el cargador solo está disponible a través de un cdn

@cromefire sí, porque está destinado a usarse como un "fragmento". Sin embargo, puede encontrar su código aquí https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/loader.js

Parece que tengo que abrir un nuevo PR, porque con esm esto también se puede usar desde su propio código

Tenemos una solución que le permitirá usar loader junto con minimal y agregará de manera efectiva solo unos pocos kB a su paquete final.

No debería ser difícil escribir un cargador que cargue eso en menos de 1kb, entonces, ¿por qué no? Intentaré escribir uno rápido.

Una cosa que podría ayudar mucho aquí es si algunas de las funcionalidades son opcionales.

Por ejemplo, un mínimo realmente agradable podría ser:

• seguimiento de pila de error nativo (no importa si no es óptimo en algunos navegadores)
• agente de usuario
• marca de tiempo
• URL
• coincidir con los mapas de origen en el servidor

Cualquier funcionalidad adicional puede ser solo un complemento. Solo admitimos navegadores modernos, por lo que no necesitamos evitar todo el comportamiento peculiar de los navegadores antiguos.

Resolvimos esto usando la división del código del paquete web y cargando el cliente centinela solo en caso de error.

sentry.js

import * as Sentry from '@sentry/browser';
Sentry.init({
  ...
  integrations: integrations => {
    return integrations.filter(integration => integration.name !== 'GlobalHandlers');
  },
});
export const logError = error => Sentry.captureException(error);

errors.js

const captureError = async error => {
 const { logError } await import(/* webpackChunkName: "sentry" */ './sentry');
 logError(error);
}
window.onerror = (message, url, line, column, error) => captureError(error);
window.onunhandledrejection = event => captureError(event.reason);

Hacemos algo más allí, como llenar migas de pan, agregar extra, agregar etiquetas, etc., pero es posible usar el cliente centinela y no hacer que su paquete sea más grande.

Esto es un poco lo que implementé en #1846

Puede ser útil para otros:
Usé la compilación ESM con paquete web ( 4.29.5 ) por:

• agregando un alias de paquete web para usar la compilación ESM en lugar de la compilación estándar, ya que no hay una declaración de module en package.json

resolve: {
    alias: {
        // use sentry ESM build which is not declared in the @sentry/browser package.json
        '@sentry/browser': path.resolve(
            __dirname,
            'node_modules/@sentry/browser/esm',
        ),
    }

• agregue una exclusión a sentry/.+/esm a nuestra configuración babel-loader , ya que parece que la compilación de ESM incluye características más nuevas que ES2015.

{
    test: /\.m?jsx?$/,
    loader: 'babel-loader',
    // compile sentry as the ESM build is new and ships modern features which break our supported browsers
    exclude: /(node_modules\/(?!(@sentry\/[^/]+\/esm))|bower_components)\//,
}

Notas:

• Usamos alias para que no tengamos que preocuparnos por la agrupación cuando lo usamos en el código (hacemos lo mismo para lodash-es entre otras cosas)

@Limess

Simplemente puede redirigir a @sentry/browser/esm :

resolve: {
    alias: {
        // use sentry ESM build which is not declared in the @sentry/browser package.json
        '@sentry/browser': '@sentry/browser/esm'
    }

Pero no necesita agregar un alias, solo importe @sentry/browser/esm

Para el cargador es más fácil escribirlo así:

• Si tienes otras cosas en babel:

{
    test: /other_things/,
    include: [/@sentry\/.+\/esm/],
    exclude: /node_modules/,
    // config
}

• Si no:

{
    test: /@sentry\/.+\/esm/,
    exclude: /node_modules/,
    // config
}

También recuerde personalizar la configuración de babel para sus necesidades: babel docs , de lo contrario, no vale la pena usar la versión esm

Actualización: pronto lanzaremos una nueva versión principal del SDK que reduce significativamente el tamaño del paquete.

26.1 kB - https://bundlephobia.com/result?p=@sentry/browser @4.6.4
contra
17.2 kB - https://bundlephobia.com/result?p=@sentry/browser @5.0.0-rc.1

Nuestras versiones de CDN preconstruidas incluso muestran mejores resultados (no estoy seguro de cómo mide las cosas la fobia a los paquetes)

ES6:  14.3535 kB
ES5:  15.6846 kB

De todos modos, quería informarles que todavía estamos trabajando para reducir aún más el tamaño del paquete, pero esto ya debería ser un gran paso en la dirección correcta.

Nota sobre la actualización: es un bache importante ya que hay muchos cambios internos en el SDK. No debería haber ningún cambio de código necesario de su lado. Actualmente estamos probando la nueva versión nosotros mismos en sentry.io para ver cómo se comporta. referencia: https://github.com/getsentry/sentry/pull/12492

Descargo de responsabilidad: No uses 5.0.0-rc.x en producción todavía como lo hacemos nosotros 🙈

@HazAT , ¡gracias por tomarte esto en serio! este es un gran paso adelante. Ya estoy mucho menos preocupado por implementar esto ahora :-)

@kamilogorek Solo por curiosidad, ¿podría agregar a la comparación la última versión de la rama 3.x ?

Estoy cerrando este problema, a partir de ahora, creemos que la reducción que introdujimos al pasar de v4 a v5 es una tendencia en la dirección correcta. Todavía intentaremos reducirlo aún más y seremos muy conscientes de aumentarlo nunca más.

Como comentario rápido, realmente solo nos gusta comparar el tamaño de nuestro "paquete", ya que dependiendo del paquete que esté usando, su kilometraje puede variar, así que aquí está el número de paquete de CDN que enviamos (pedimos):

| Paquete | Versión | Tamaño en Bytes | Tamaño en kB | Enlace |
|--------|---------|---------------|----- -------|------------------------------------------- ----------|
| cuervo-js | 3.27.0 | 13741 bytes | ~13.4kB | https://cdn.ravenjs.com/3.27.0/raven.min.js |
| @centinela/navegador | 4.6.6 | 22607 bytes | ~22.1kB | https://navegador.sentry-cdn.com/4.6.6/bundle.min.js |
| @centinela/navegador | 5.0.3 | 16059 bytes | ~15.7kB | https://navegador.sentry-cdn.com/5.0.3/bundle.min.js |

Con v5 también enviamos y compilamos esm , lo que significa que si está utilizando un paquete, debería ser capaz de generar rutas de código no utilizadas.

Gracias a todos por su paciencia 🙇

@HazAT @kamilogorek increíble!

@Limess ¿Sigue siendo relevante usar esto hoy: @sentry/browser/esm en lugar de @sentry/browser ?

Se importa como import * as Sentry from "@sentry/browser/esm"; y se incluye con webpack -p pero no veo ninguna diferencia en los tamaños de los paquetes. También tengo webpack.config.js desnudos sin complementos ni cargadores.

@0xbkt No hay diferencia en el tamaño del paquete, al menos ahora cuando se usa el paquete acumulativo para agrupar la aplicación.