Sentry-javascript: @taille sentinelle/navigateur

Hé, merci d'avoir soulevé ça.
Bien que nous comprenions et acceptions généralement vos préoccupations concernant la taille des bundles, je pense qu'il est juste de comparer d'abord les tailles des bundles gzip au lieu de la taille du fichier minifié non compressé :

@sentry/browser correspond à 21,3799 Ko
raven-js 13,44 Ko

De plus, bien que cela puisse ne pas s'appliquer à tout le monde, nous fournissons et guidons généralement les gens pour qu'ils utilisent notre CDN Loader qui configurera le SDK pour vous sur votre site Web.

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

L'empreinte et l'impact sur le temps de chargement de votre page de ce script sont <1 Ko gzippés tout en conservant les mêmes fonctionnalités.

donc tl;dr:
Nous en sommes conscients, nous savons qu'il y a place à l'amélioration mais ce n'est pas la priorité absolue en ce moment.

Je pense qu'il est juste de comparer d'abord les tailles des bundles gzip au lieu de la taille du fichier minifié non compressé :

Je dirais qu'il est également juste de comparer les tailles minifiées, car les problèmes de performances ne découlent pas seulement du téléchargement de javascript, mais également de l'analyse et de l'exécution. ~ 92 Ko est assez lourd et peut ajouter jusqu'à 1 seconde de temps d'analyse sur les appareils bas de gamme (juste pour cette bibliothèque !).

Je ne sais pas d'où vous prenez le nombre de < 1KB pour le script CDN. Pourriez-vous élaborer? Lorsque j'ouvre https://browser.sentry-cdn.com/4.0.4/bundle.min.js , je vois une taille gzippée de 22 Ko.

Vous devez savoir que le SDK de Sentry n'est qu'une des nombreuses bibliothèques incluses par les développeurs.

PS : J'adore la sentinelle, ça nous a été super utile. La performance Web est juste quelque chose qui me passionne. ;)

@klaemo
Héhé, pas de soucis 😅

Comme je l'ai dit, nous sommes conscients et ce n'est pas comme si nous ne voulions pas qu'il soit plus petit.
La priorité la plus élevée pour nous était d'expédier le nouveau SDK, nous travaillerons pour améliorer la taille du bundle au fil du temps.
Il y a beaucoup plus d'étapes que nous pouvons prendre, par exemple : utilisez tslib , combinez des chaînes ...
Il y a donc beaucoup de place pour des améliorations.

Désolé, le lien que j'ai posté avant est déjà obsolète 🙃
Je faisais référence au _Loader_ : https://docs.sentry.io/platforms/javascript/loader/
Bien que le _Loader_ ait également ses limites en raison de sa nature asynchrone et qu'il récupère et injecte toujours le SDK (même s'il est asynchrone), c'est une alternative que nous proposons parce que les gens l'ont demandé.

@HazAT Désolé, les gars, mais pouvez-vous fournir la date de sortie de la prochaine version ?
Je veux dire, il y a déjà quelques changements dans la branche #master mais pas encore publiés. Celui-ci décide cependant que la version 4x est utilisable pour les projets Angular5 +.

@rayzru vient de publier 4.0.5 , mais veuillez garder les messages liés au sujet.

À mon avis, c'est définitivement une régression et la raison sérieuse de ne pas mettre à jour vers la nouvelle version.

💯 J'étais sur le point de mettre à jour jusqu'à ce que j'ai remarqué que :

• avant : https://bundlephobia.com/[email protected]
• après : https://bundlephobia.com/result?p=@sentry/browser @4.0.1

Au moins , la taille du paquet est plus petite , mais je pense que ⚠️ +10 Ko de JavaScript gzippé dans un bundle est significatif. On va attendre, bonne continuation :)

@HazAT Serait-il possible de générer des fichiers esm. Cela permettrait à Webpack d'avoir de meilleurs résultats avec la concaténation et l'agitation de l'arborescence.

Vous voudrez peut-être ajouter un outil CI pour suivre la taille du paquet du package pour chaque demande de fusion. Depuis ce problème, il est en fait passé à 100 Ko, voir https://bundlephobia.com/result?p=@sentry/browser @4.3.0

Essayez par exemple https://github.com/siddharthkp/bundlesize

Le budget de performances par défaut pour un point d'entrée dans Webpack est de 250 Ko pour vous assurer d'obtenir des performances décentes sur n'importe quel appareil et réseau. 100 ko de Sentry occupent une grande partie de ce budget.

Veuillez nous tenir au courant si la correction de cette régression est sur la feuille de route, ou si la bibliothèque continuera de croître sans budget de taille.

Nous payons des clients et investissons massivement dans Sentry à la fois sur le backend, en natif et sur le Web, mais une mise à niveau à plus de 3 fois la taille de la bibliothèque ([email protected] fait 31 Ko) n'est pas quelque chose que nous pouvons justifier.

@jacobrask Vous pouvez vous en tenir à l'ancienne version de la bibliothèque, c'est ce que nous faisons sur https://www.onepixel.com/ , ça marche bien 👌.

@jacobrask C'est définitivement sur notre liste et nous pensons aussi qu'il y a des fruits à portée de main où nous pouvons facilement réduire la taille de notre paquet.
De plus en plus de personnes le demandent, nous allons donc probablement nous y attaquer plus tôt que prévu.

@HazAT
Le kit de déploiement du SDK du navigateur Sentry peut être optimisé. Dans le fichier bundle min js, de nombreux codes tslib sont répétés. Comme __generator, __assign. Dans Browser env, il est préférable de partager un code. Mais le projet de navigateur utilise un autre fichier de distribution de packages. Réduisez peut-être la taille de gzip de 23K à 16K.

La taille du bundle est la même dans 4.3.2
https://bundlephobia.com/result?p=@sentry/browser @4.3.2 indépendamment des changements de
https://github.com/getsentry/sentry-javascript/pull/1738 :(

@vkrol Nous avons dû annuler les modifications apportées par @gaterking , au moins pour le package npm.
Le bundle sur CDN, en revanche, devrait être plus petit.

Nous allons certainement rajouter les modifications mais nous devons en parler car nous avons besoin d'une dépendance sur tslib par exemple.
De plus, la façon dont les typages étaient générés était cassée.

@HazAT D'accord, merci.

@vkrol Nous avons dû annuler les modifications apportées par @gaterking , au moins pour le package npm.
Le bundle sur CDN, en revanche, devrait être plus petit.

Nous allons certainement rajouter les modifications mais nous devons en parler car nous avons besoin d'une dépendance sur tslib par exemple.
De plus, la façon dont les typages étaient générés était cassée.

Espérons le plus tôt possible.

@gaterking @kamilogorek Correction déjà https://github.com/getsentry/sentry-javascript/pull/1751
Nous devions juste faire une version "urgente", c'est pourquoi nous l'avons annulée.

Côté client, je souhaite essentiellement que cela capture les erreurs et les soumette à l'API.

Que fait d'autre cette bibliothèque si complexe ?

Il est vraiment difficile de comprendre pourquoi un simple rapporteur d'erreurs doit avoir une empreinte aussi importante 😐

@mindplay-dk C'est surtout parce que JavaScript et les navigateurs sont un gâchis ^^
Nous devons faire beaucoup de réparations sur les traces de pile cassées/erronées.
La simple tâche de "simplement détecter les erreurs" est également beaucoup plus complexe qu'il n'y paraît.

Il est vraiment difficile de comprendre pourquoi un simple rapporteur d'erreurs doit avoir une empreinte aussi importante 😐

@mindplay-dk parce que ce n'est pas simple.

Voici le code pour simplement capturer les erreurs dans tous les navigateurs et les unifier dans une structure de données utilisable : https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/tracekit.ts

Bravo pour la récente réduction de taille, très appréciée. 👍

Un coup d'œil rapide sur le fichier lié montre le code pour gérer les erreurs pour Opera 10, est-ce vraiment toujours nécessaire ? TraceKit ne tient pas non plus compte de l'augmentation de taille 2x (actuellement) de Raven, qui était déjà importante.

Quelques suggestions:

• Supprimer md5
• Réduisez l'utilisation de async/wait, il se compile mal en ES5. Comparez https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/baseclient.ts#L307 -L378 au code de sortie (recherchez "processEvent" dans le bundle de production). Ce fichier entier devient énorme dans le bundle de production.

Existe-t-il du code partagé ( app:///${base} dans rewriteframes.ts) dans un autre package tel que package/core ? Ils ne sont pas utilisés par le client, mais par le nœud.

car ce n'est pas simple.

@kamilogorek yikes, vous avez évidemment raison... J'ai réalisé que JavaScript était un gâchis - je suppose que je n'avais jamais creusé dans ce domaine auparavant, je n'avais pas réalisé à quel point c'était grave. Je suppose qu'il n'y a vraiment pas de moyen simple de gérer les traces de pile dans JS. Juste. Ouais. 😐

Au lieu d'essayer simplement de minimiser les aides, vous pouvez simplement fournir les fichiers esm déjà mentionnés, c'est facile et même une meilleure pratique aujourd'hui.

Réduisez l'utilisation de async/wait, il se compile mal en ES5. Comparez https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/baseclient.ts#L307 -L378 au code de sortie (recherchez "processEvent" dans le bundle de production). Ce fichier entier devient énorme dans le bundle de production.

C'est la mauvaise façon, au lieu d'optimiser davantage pour ES5, il est plus important d'optimiser pour 80.07% qui utilisent des navigateurs modernes.

Pour tous ceux qui ont besoin de prendre en charge les anciens navigateurs :
Les fonctions asynchrones sont prises en charge par tout navigateur prenant en charge <script type="module"> (caniuse: esm , async ) de sorte que seuls les utilisateurs d'anciens navigateurs doivent attendre plus longtemps (cela leur prend de toute façon plus de temps)

Preuve:
160 Ko (es5, fourni) > 119 Ko (esm, fichiers simples)

Donc, s'il vous plaît regrouper le fichier esm (aussi), c'est aussi simple que de changer le paramètre module et target dans /tsconfig.esm.json (qui s'étend tsconfig.build.json ) à esnext , en ajoutant des fichiers tsconfig.esm.json similaires aux fichiers tsconfig.build.json aux packages, ajoutez-le à la construction et au package et spécifiez une entrée de module dans le package.json

Si vous le souhaitez, je peux ajouter un PR pour cela.

Si vous le souhaitez, je peux ajouter un PR pour cela.

J'adorerais ça @cromefire :)

Ce serait génial s'il y avait une option pour choisir entre le mode classique et moderne, comme vue cli. Où la version moderne ne prend en charge que la plupart des navigateurs modernes et pourrait donc être moins gonflée.

Ou encore mieux si cela pouvait fonctionner comme webpack env, afin que l'utilisateur puisse spécifier la prise en charge du navigateur nécessaire. Bien sûr, ce n'est pas une fonctionnalité facile, mais je voulais juste la lancer :)

Produit génial!

Avec ce nouveau PR, vous pouvez configurer babel comme vous le souhaitez pour ne prendre en charge que les navigateurs dont vous avez besoin

La taille de @sentry/browser est plus de deux fois supérieure à la taille de raven-js : 86 ko contre 39 ko (minifié).

Pour info : la taille de la dernière version de @sentry/browser est passée à 91,8 ko . Source : https://bundlephobia.com/result?p=@sentry/browser @4.5.0.

@cromefire Merci pour votre travail d'optimisation de la taille de la bibliothèque !

Je viens d'essayer d'utiliser la nouvelle version esm de la v4.5.0 mais j'ai eu beaucoup d'erreurs. Tous sont déclenchés car les modules de @sentry/utils/esm n'ont pas pu être résolus.

En fait, je n'ai pas trouvé les dossiers dans node_modules après un nouveau yarn install . (Voir capture d'écran)

 ERREUR dans ./node_modules/@sentry/core/esm/baseclient.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/async' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/browser/esm/backend.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/is' dans './node_modules/@sentry/browser/esm'

 ERREUR dans ./node_modules/@sentry/browser/esm/tracekit.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/is' dans './node_modules/@sentry/browser/esm'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/is' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/is' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/pluggable/vue.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/is' dans './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERREUR dans ./node_modules/@sentry/core/esm/baseclient.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/is' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/core/esm/dsn.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/is' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/is' dans './node_modules/@sentry/core/esm/integrations'

 ERREUR dans ./node_modules/@sentry/core/esm/integrations/extraerrordata.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/is' dans './node_modules/@sentry/core/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/globalhandlers.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/logger' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/logger' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/core/esm/baseclient.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/logger' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/core/esm/basebackend.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/logger' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/core/esm/sdk.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/logger' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/core/esm/integration.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/logger' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/core/esm/integrations/dedupe.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/logger' dans './node_modules/@sentry/core/esm/integrations'

 ERREUR dans ./node_modules/@sentry/core/esm/integrations/sdkinformation.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/logger' dans './node_modules/@sentry/core/esm/integrations'

 ERREUR dans ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/logger' dans './node_modules/@sentry/core/esm/integrations'

 ERREUR dans ./node_modules/@sentry/hub/esm/hub.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/logger' dans './node_modules/@sentry/hub/esm'

 ERREUR dans ./node_modules/@sentry/browser/esm/client.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/browser/esm'

 ERREUR dans ./node_modules/@sentry/browser/esm/tracekit.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/browser/esm'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/useragent.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/trycatch.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/pluggable/reportingobserver.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/pluggable/vue.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/pluggable/ember.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERREUR dans ./node_modules/@sentry/browser/esm/transports/beacon.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/browser/esm/transports'

 ERREUR dans ./node_modules/@sentry/browser/esm/transports/fetch.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/browser/esm/transports'

 ERREUR dans ./node_modules/@sentry/core/esm/baseclient.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/core/esm/integrations/dedupe.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/core/esm/integrations'

 ERREUR dans ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/core/esm/integrations'

 ERREUR dans ./node_modules/@sentry/hub/esm/scope.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/hub/esm'

 ERREUR dans ./node_modules/@sentry/hub/esm/hub.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/misc' dans './node_modules/@sentry/hub/esm'

 ERREUR dans ./node_modules/@sentry/browser/esm/parsers.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/object' dans './node_modules/@sentry/browser/esm'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/object' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/trycatch.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/object' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/object' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/core/esm/api.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/object' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/core/esm/basebackend.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/object' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/core/esm/dsn.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/object' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/hub/esm/scope.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/object' dans './node_modules/@sentry/hub/esm'

 ERREUR dans ./node_modules/@sentry/core/esm/integrations/pluggable/rewriteframes.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/path' dans './node_modules/@sentry/core/esm/integrations/pluggable'

 ERREUR dans ./node_modules/@sentry/browser/esm/parsers.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/string' dans './node_modules/@sentry/browser/esm'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/string' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/core/esm/baseclient.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/string' dans './node_modules/@sentry/core/esm'

 ERREUR dans ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/string' dans './node_modules/@sentry/core/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/backend.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/supports' dans './node_modules/@sentry/browser/esm'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/supports' dans './node_modules/@sentry/browser/esm/integrations'

 ERREUR dans ./node_modules/@sentry/browser/esm/integrations/pluggable/reportingobserver.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/supports' dans './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERREUR dans ./node_modules/@sentry/browser/esm/transports/fetch.js

 Module introuvable : erreur : impossible de résoudre '@sentry/utils/esm/supports' dans './node_modules/@sentry/browser/esm/transports'

La construction de @pascaliske esm est toujours en phase d'expérimentation et nous ne l'avons pas encore documentée publiquement. Nous le ferons une fois que tout aura été testé et publierons nos conclusions ici.

@kamilogorek Oui, je sais. Je voulais juste vous faire part de ces erreurs. 🙂

Merci, j'apprécie @pascaliske ! Nous essaierons de fournir un support ESM dès que possible :)

@pascaliske essayez d'abord yarn build

@cromefire Non, cela n'aidera pas, je pense. Je viens de télécharger le package à partir de npm, il n'y a donc pas d'environnement de construction disponible. 🙂

J'ai cherché un peu dans le code source et comparé @sentry/browser avec @sentry/utils . Je pense que c'est le problème : packages/utils/tsconfig.build.json#L5 vs packages/browser/tsconfig.build.json#L5 . Est-il possible que la sortie de construction normale écrase la sortie de construction esm ? 🤔

Dans mon dossier node_modules, le package browser contient la sortie de construction de normal et esm. Mais le package utils ne contient que la sortie de construction normale dans le dossier racine.

Est-il déjà sorti ?

J'ai cherché un peu dans le code source et comparé @sentry/browser avec @sentry/utils . Je pense que c'est le problème : packages/utils/tsconfig.build.json#L5 vs packages/browser/tsconfig.build.json#L5 . Est-il possible que la sortie de construction normale écrase la sortie de construction esm ? 🤔

Non, vous devez regarder le esm tsconfig

Je vais regarder ça demain

Salut à tous! Nous examinons également certaines des tailles de bundles dans Sentry et sommes tombés sur ceci : https://github.com/getsentry/sentry-javascript/blob/master/packages/minimal/package.json#L20

On dirait que cela ajoute un morceau de taille pour très peu de fonctions (répartir et attribuer). Je ne suis pas très familier avec Typescript, mais est-ce nécessaire pour cela au moment de l'exécution ?

Je ne comprends pas non plus pourquoi @sentry/types doit être une dépendance _runtime_, et non située dans devDependencies ...

@evocateur pour tous les utilisateurs de tapuscrit c'est nécessaire. Typescript optimise tout cela.
(mais cela peut être nécessaire pour les fichiers .d.ts )

@IanMitchell Il n'est pas utilisé pour la construction esm, mais pour les versions normales

Le bundle.js de 4.5.0 contient beaucoup de code en double, comme Severity, htmlElementAsString, htmlElementAsString, uuid4, parseUrl et ainsi de suite. Cela ne peut pas être voulu !

La même chose se produit lorsque je fais un Bundle via import * as Sentry from '@sentry/browser'; (comme seule ligne dans le fichier) en utilisant WebPack + Babel 7, alors la taille groupée est de 326kb. Voir : sentry.bundle.js.txt
Nous utilisons également la même configuration pour nos autres bundles, mais Sentry est le seul bundle avec ce problème.

Le bundle.min.js n'a pas de code en double à l'intérieur de , ce qui peut être le résultat d'un tree shaking avec rollup.

Donc, une solution temporaire consiste à utiliser import '@sentry/browser/build/bundle.min.js';

Le bundle.js de 4.5.0 contient beaucoup de code en double, comme Severity, htmlElementAsString, htmlElementAsString, uuid4, parseUrl et ainsi de suite. Cela ne peut pas être voulu !

C'est pourquoi (ou c'est au moins une raison) il y a la construction esm . Si vous avez de toute façon un bundler, c'est plus efficace que d'utiliser un bundle pré-construit. (C'est juste une version bêta et pour le moment toujours cassé)

En regardant à nouveau, et je ne crois pas que cela ne pourrait pas être plus petit. Beaucoup plus petit.

Les traces de pile avec prise en charge de la carte source devraient être de loin la chose la plus complexe de cette bibliothèque - et il ne semble pas que ce soit le cas? Il semble que la majeure partie de l'empreinte provienne du cadre principal, qu'il partage avec le client node.js, où je suis sûr que l'empreinte n'est pas vraiment un problème.

Ne vous méprenez pas, c'est une belle architecture - un très beau travail TypeScript.

Mais côté client, cela ne veut pas dire grand-chose. Il doit être petit et se charger rapidement - en particulier pour quelque chose d'aussi bas niveau que celui-ci, peu importe si le code source est beau ou non. Autant que je sache, toute cette architecture impressionnante coûte beaucoup d'octets sur toute la ligne.

En comparaison:

Je suis tombé sur TrackJS , qui a des capacités similaires (trace de pile entre navigateurs avec des cartes source) dans un package d'environ 10 Ko.

Le TraceKit d' origine est d'environ 3 Ko min + gz.

J'ai trouvé cette bibliothèque qui peut faire le bit de carte source (côté client) dans ~ 8 Ko min + gz ou ~ 10 Ko avec des polyfills x-browser.

Au-delà de cela, il s'agit de collecter quelques informations sur le navigateur, de les envelopper dans le format JSON attendu et de les publier - ce qui ne devrait pas dépasser quelques Ko min + gz. Devrait-il?

J'ai l'impression que c'est juste beaucoup plus d'architecture que ce dont la plupart des gens ont besoin. Si j'ai besoin d'un support de plugin, j'ai peut-être besoin d'un simple crochet qui me permet de brancher des informations dans le message JSON, mais c'est à peu près tout.

Je sais qu'il est courant de déployer des mégaoctets de JS ces jours-ci, mais nous avons des politiques de contenu strictes au travail, pour nous assurer que nous expédions des projets qui se chargent rapidement sur les mobiles, et je ne peux pas justifier de dépenser plus de la moitié de notre budget JS sur erreur- logging - peut-être 10% en tête, donc quelque chose comme ~15-20 KB semble raisonnable.

J'adore votre produit, mais je n'arrive pas à déployer ce client 😐

Pour quelque chose comme ça, il pourrait être judicieux de déléguer l'analyse de stacktrace et de source-map au serveur, où la taille n'est pas pertinente

Pour quelque chose comme ça, il pourrait être judicieux de déléguer l'analyse de stacktrace et de source-map au serveur, où la taille n'est pas pertinente

@cromefire idée intéressante. Je me demande si c'est ce que fait par exemple TrackJS pour réduire la taille? (Leur client est propriétaire - seule la source minifiée est disponible, il est donc difficile de dire ce qu'ils font. Supposons que je puisse l'installer et voir ce qui se passe sur le fil ...)

Voici un package plus simple pour résoudre les cartes source dans le navigateur : source-map- resolve at ~2KB min+gz ... c'est sans polyfills, mais (si cela fonctionne) je pense que nous devrions pouvoir atteindre ~10KB pour les navigateurs modernes qui n'ont pas besoin de polyfills.

c'est sans polyfills

Les polyfills ne devraient pas être dans la construction esm , donc cela pourrait aussi fonctionner, mais dans le bachend, ce serait encore moins

La version @cromefire ESM devrait être disponible en 4.5.1 maintenant. Toujours pas documenté car nous voulons nous assurer qu'il est testé au combat, mais jusqu'à présent tout va bien. J'ai vérifié la construction régulière de Webpack avec Babel Loader et cela fonctionne comme un charme.

Au-delà de cela, il s'agit de collecter quelques informations sur le navigateur, de les envelopper dans le format JSON attendu et de les publier - ce qui ne devrait pas dépasser quelques Ko min + gz. Devrait-il?

@mindplay-dk nous n'effectuons aucune résolution de trace de pile côté client. Tout se fait sur le serveur, c'est pourquoi vous devez d'abord télécharger les cartes source pour obtenir de l'aide.

Ce que nous faisons cependant, c'est :

• processeurs d'événements pour fournir des crochets personnalisés qui vous permettent de modifier/filtrer/améliorer les données envoyées à Sentry
• prendre soin de tous les emballages d'API natifs
• capturer le fil d'Ariane de toutes les interactions des utilisateurs, des appels réseau, des navigations
• extraire les données de l'agent utilisateur
• extraire des données d'erreur supplémentaires à partir d'erreurs liées, de sorte que vous pouvez créer plusieurs niveaux d'erreur comme dans d'autres langues
• écouter les deux gestionnaires d'erreurs globaux
• fournir plusieurs transports réseau, de sorte que l'utilisateur obtienne toujours le meilleur pour son environnement actuel
• prendre en charge des dixièmes de cas extrêmes et divers objets d'erreur (même personnalisés) et diverses implémentations natives
• fournir des solutions de secours aux informations d'erreur de rechange ou cassées
• mettre en mémoire tampon les événements afin de ne pas inonder votre propre instance Sentry ou de manquer d'événements gratuits en cas de problème

Juste pour en nommer quelques-uns. J'aimerais vraiment que ce soit aussi simple que "attraper une erreur, ajouter des données et l'envoyer".
Dans le monde réel cependant, il existe des dizaines d'entrées, des dizaines de sources d'erreurs (qui fournissent toutes des données différentes) et des dizaines d'environnements dont le comportement varie.
Nous allons certainement continuer à travailler sur la façon de réduire cela à ~ 10-15 Ko, mais cela prendra du temps. Nous n'avons qu'un nombre limité de ressources (lire les personnes/le temps) que nous pouvons dépenser maintenant.

Je sais qu'il est courant de déployer des mégaoctets de JS ces jours-ci, mais nous avons des politiques de contenu strictes au travail, pour nous assurer que nous expédions des projets qui se chargent rapidement sur les mobiles, et je ne peux pas justifier de dépenser plus de la moitié de notre budget JS sur erreur- logging - peut-être 10% en tête, donc quelque chose comme ~15-20 KB semble raisonnable.

Vous pouvez alors utiliser notre chargeur - https://docs.sentry.io/platforms/javascript/loader/ :)

Vous pouvez alors utiliser notre chargeur - https://docs.sentry.io/platforms/javascript/loader/ :)

Mais il n'y a malheureusement pas de solution pour webpack

Juste pour en nommer quelques-uns. J'aimerais vraiment que ce soit aussi simple que "attraper une erreur, ajouter des données et l'envoyer".

Peut-être que quelqu'un devrait proposer quelque chose à tc39 . Je devrais regarder comment se déroule le processus, mais peut-être que quelqu'un pourrait proposer une API standardisée pour la lecture de stacktrace

Mais il n'y a malheureusement pas de solution pour webpack

Que voulez-vous dire exactement? Avoir un package qui pourrait coexister avec le chargeur, qui pourrait être importé et regroupé, mais ensuite communiquer avec le SDK chargé de manière asynchrone une fois qu'une erreur ou un appel captureException se produit ?

Que voulez-vous dire exactement? Avoir un package qui pourrait coexister avec le chargeur, qui pourrait être importé et regroupé, mais ensuite communiquer avec le SDK chargé de manière asynchrone une fois qu'une erreur ou un appel captureException se produit ?

Oui, si je récapitule bien, le loader n'est disponible que via un cdn

@cromefire oui, car il est destiné à être utilisé comme "extrait". Cependant, vous pouvez trouver son code ici https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/loader.js

On dirait que je dois ouvrir un nouveau PR, car avec esm cela serait également utilisable à partir de votre propre code

Nous avons une solution à venir qui vous permettra d'utiliser loader aux côtés minimal et n'ajoutera effectivement que quelques Ko à votre bundle final.

Il ne devrait pas être difficile d'écrire un chargeur qui charge cela en moins de 1 Ko, alors pourquoi pas, je vais essayer d'en écrire un rapide

Une chose qui pourrait beaucoup aider ici est que certaines fonctionnalités soient facultatives.

Par exemple, un très bon minimum pourrait être :

• trace native de la pile d'erreurs (peu importe que ce ne soit pas optimal sur certains navigateurs)
• agent utilisateur
• horodatage
• URL
• correspondance avec les cartes source sur le serveur

Toutes les fonctionnalités supplémentaires peuvent simplement être ajoutées. Nous ne prenons en charge que les navigateurs modernes, nous n'avons donc pas besoin de contourner tous les comportements bizarres des anciens navigateurs.

Nous avons résolu ce problème en utilisant le fractionnement du code Webpack et en chargeant le client Sentry uniquement en cas d'erreur.

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);

Nous faisons un peu plus là-dedans, comme remplir le fil d'Ariane, ajouter des éléments supplémentaires, ajouter des balises, etc., mais il est possible d'utiliser le client sentinelle et de ne pas agrandir votre bundle.

C'est un peu ce que j'ai implémenté dans #1846

Peut être utile à d'autres :
J'ai utilisé la construction ESM avec webpack ( 4.29.5 ) par:

• ajouter un alias webpack pour utiliser la version ESM plutôt que la version standard car il n'y a pas de déclaration module dans 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',
        ),
    }

• ajoutez une exclusion à sentry/.+/esm à notre configuration babel-loader , car il semble que la version ESM inclut des fonctionnalités plus récentes 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)\//,
}

Remarques:

• Nous avons utilisé des alias pour ne pas avoir à nous soucier du regroupement lors de son utilisation dans le code (nous faisons la même chose pour lodash-es entre autres)

@Limess

Vous pouvez simplement rediriger vers @sentry/browser/esm :

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

Mais vous n'avez pas besoin d'ajouter un alias, importez simplement @sentry/browser/esm

Pour le chargeur, il est plus facile de l'écrire comme ceci :

• Si vous avez d'autres choses à babel :

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

• Si ce n'est pas le cas :

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

Pensez également à personnaliser la configuration de babel selon vos besoins : babel docs , sinon ce n'est pas la peine d'utiliser la version esm

Mise à jour : Nous publierons bientôt une nouvelle version majeure du SDK qui réduit considérablement la taille du bundle.

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

Nos versions CDN prédéfinies affichent même de meilleurs résultats (je ne sais pas comment la bundlephobie mesure les choses)

ES6:  14.3535 kB
ES5:  15.6846 kB

Quoi qu'il en soit, je voulais vous faire savoir que nous travaillons toujours à réduire davantage la taille du bundle, mais cela devrait déjà être un grand pas dans la bonne direction.

Remarque sur la mise à niveau : il s'agit d'un problème majeur car il existe de nombreux changements internes dans le SDK. Aucune modification de code ne devrait être nécessaire de votre côté. Nous testons actuellement nous-mêmes la nouvelle version sur sentry.io pour voir comment elle se comporte. réf : https://github.com/getsentry/sentry/pull/12492

Avis de non-responsabilité : n'utilisez pas encore 5.0.0-rc.x en production comme nous le faisons 🙈

@HazAT merci de prendre cela au sérieux ! c'est un grand pas en avant - je suis déjà beaucoup moins préoccupé par le déploiement maintenant :-)

@kamilogorek Juste par curiosité, pourriez-vous ajouter à la comparaison la dernière version de la branche 3.x ?

Je ferme ce sujet, à partir de maintenant, nous pensons que la réduction que nous avons introduite en passant de la v4 à la v5 est une tendance dans la bonne direction. Nous essaierons toujours de le réduire davantage et nous serons très soucieux de l'augmenter à nouveau.

En guise de remarque rapide, nous n'aimons vraiment comparer que la taille de notre « bundle », car selon le bundle que vous utilisez, votre kilométrage peut varier, voici donc le numéro de bundle CDN que nous expédions (ped):

| Forfait | version | Taille en octets | Taille en Ko | Lien |
|----------------|---------|---------------|----- -------|------------------------------------------------------- ----------|
| corbeau-js | 3.27.0 | 13741 octets | ~13.4kB | https://cdn.ravenjs.com/3.27.0/raven.min.js |
| @sentinelle/navigateur | 4.6.6 | 22607 octets | ~22,1 Ko | https://browser.sentry-cdn.com/4.6.6/bundle.min.js |
| @sentinelle/navigateur | 5.0.3 | 16059 octets | ~15,7 Ko | https://browser.sentry-cdn.com/5.0.3/bundle.min.js |

Avec la v5, nous expédions également et construisons esm , ce qui signifie que si vous utilisez un bundler, il devrait être capable d'arborescence des chemins de code inutilisés.

Merci à tous pour votre patience 🙇

@HazAT @kamilogorek génial !

@Limess Est-il toujours pertinent d'utiliser ceci aujourd'hui : @sentry/browser/esm au lieu de @sentry/browser ?

Il est importé comme import * as Sentry from "@sentry/browser/esm"; et fourni avec webpack -p mais je ne vois aucune différence dans la taille des paquets. J'ai aussi un webpack.config.js nu sans plugins ni chargeurs.

@0xbkt Cela ne fait aucune différence dans la taille du bundle, du moins maintenant lors de l'utilisation du rollup pour regrouper l'application.