Sentry-javascript: @sentry/browsergröße

Hey, danke, dass du das angesprochen hast.
Obwohl wir Ihre Bedenken bezüglich der Paketgröße verstehen und ihnen im Allgemeinen zustimmen, halte ich es für fair, zuerst die gzip-Paketgrößen anstelle der Größe der unkomprimierten verkleinerten Datei zu vergleichen:

@sentry/browser ist 21,3799 KB groß
raven-js 13,44 KB

Auch wenn dies möglicherweise nicht auf jeden zutrifft, stellen wir Menschen zur Verfügung und leiten sie normalerweise an, unseren CDN Loader zu verwenden, der das SDK für Sie auf Ihrer Website einrichtet.

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

Der Platzbedarf und die Auswirkung auf Ihre Seitenladezeit dieses Skripts ist <1 KB gzippt, während die gleiche Funktionalität beibehalten wird.

also tl;dr:
Wir sind uns dessen bewusst, wir wissen, dass es Raum für Verbesserungen gibt, aber es hat derzeit nicht die höchste Priorität.

Ich denke, es ist fair, zuerst die gzip-Bundle-Größen anstelle der unkomprimierten verkleinerten Dateigröße zu vergleichen:

Ich würde argumentieren, dass es auch fair ist, minimierte Größen zu vergleichen, da Leistungsprobleme nicht nur beim Herunterladen von Javascript auftreten, sondern auch beim Parsen und Ausführen. ~ 92 KB ist ziemlich umfangreich und kann auf Low-End-Geräten bis zu 1 Sekunde Analysezeit hinzufügen (nur für diese eine Bibliothek!).

Ich bin mir nicht sicher, woher Sie die Nummer von < 1KB für das CDN-Skript nehmen. Könnten Sie das näher erläutern? Wenn ich https://browser.sentry-cdn.com/4.0.4/bundle.min.js öffne, sehe ich eine gezippte Größe von 22 KB.

Sie sollten sich darüber im Klaren sein, dass das SDK von Sentry nur eine von vielen Bibliotheken ist, die Entwickler enthalten.

PS: Ich liebe Sentry, es war super hilfreich für uns. Web-Performance ist einfach etwas, wofür ich leidenschaftlich bin. ;)

@klaemo
Hehe, keine Sorge 😅

Wie ich schon sagte, wir sind uns dessen bewusst und es ist nicht so, dass wir nicht wollen, dass es kleiner wird.
Die höchste Priorität für uns war die Auslieferung des neuen SDK, wir werden daran arbeiten, die Bundle-Größe im Laufe der Zeit zu verbessern.
Es gibt noch viele weitere Schritte, die wir unternehmen können, z. B.: tslib , Zeichenfolgen kombinieren ...
Es gibt also viel Raum für Verbesserungen.

Entschuldigung, der Link, den ich zuvor gepostet habe, ist bereits veraltet 🙃
Ich bezog mich auf den _Loader_: https://docs.sentry.io/platforms/javascript/loader/
Obwohl der _Loader_ aufgrund seiner asynchronen Natur auch seine Grenzen hat und am Ende immer noch das SDK abruft und einfügt (selbst wenn es asynchron ist), ist es eine Alternative, die wir anbieten, weil Leute danach gefragt haben.

@HazAT Tut mir leid, Leute, aber können Sie das Veröffentlichungsdatum der nächsten Version angeben?
Ich meine, es gibt bereits einige Änderungen am #master-Zweig, die aber noch nicht veröffentlicht wurden. Dass man sich entscheidet, ist die 4x-Version jedoch für Angular5+-Projekte verwendbar.

@rayzru Gerade veröffentlicht 4.0.5 , aber bitte behalte Posts, die sich auf das Thema beziehen.

Das ist meiner Meinung nach definitiv ein Rückschritt und der schwerwiegende Grund, nicht auf die neue Version zu updaten.

💯 Ich wollte gerade upgraden, bis mir folgendes auffiel:

• vorher: https://bundlephobia.com/[email protected]
• nach: https://bundlephobia.com/result?p=@sentry/browser @4.0.1

Zumindest ist die Paketgröße +10 KB gzipptes JavaScript in einem Bundle erheblich ist. Wir werden warten, macht weiter so :)

@HazAT Könnte es möglich sein, ESM-Dateien zu generieren. Es würde Webpack ermöglichen, bessere Ergebnisse mit Verkettung und Tree Shaking zu erzielen.

Möglicherweise möchten Sie ein CI-Tool hinzufügen, um die Bündelgröße des Pakets für jede Zusammenführungsanforderung zu verfolgen. Seit diesem Problem ist es tatsächlich auf 100 kB angewachsen, siehe https://bundlephobia.com/result?p=@sentry/browser @4.3.0

Versuchen Sie es zum Beispiel mit https://github.com/siddharthkp/bundlesize

Das standardmäßige Leistungsbudget für einen Einstiegspunkt in Webpack beträgt 250 KB, um sicherzustellen, dass Sie auf jedem Gerät und in jedem Netzwerk eine angemessene Leistung erhalten. 100 KB von Sentry nehmen ziemlich viel von diesem Budget in Anspruch.

Bitte halten Sie uns auf dem Laufenden, ob die Behebung dieser Regression überhaupt auf der Roadmap steht oder ob die Bibliothek ohne Größenbudget einfach weiter wächst.

Wir zahlen Kunden und haben stark in Sentry investiert, sowohl im Backend, nativ als auch im Web, aber ein Upgrade auf die dreifache Größe der Bibliothek ([email protected] ist 31 kB) können wir nicht rechtfertigen.

@jacobrask Sie können sich an die ältere Version der Bibliothek halten, das machen wir bei https://www.onepixel.com/ , es funktioniert gut 👌.

@jacobrask Es steht definitiv auf unserer Liste und wir denken auch, dass es einige niedrig hängende Früchte gibt, bei denen wir unsere
Immer mehr Leute fragen danach, also werden wir das wahrscheinlich früher als erwartet angehen.

@HazAT
Sentry-Browser-SDK-Rollup-Bundle kann optimiert werden. In der Bundle-Min-js-Datei werden viele tslib-Codes wiederholt. Wie __generator, __assign. In Browser env ist es am besten, einen Code zu teilen. Aber das Browser-Projekt verwendet eine andere Paketdist-Datei. Reduzieren Sie möglicherweise die gzip-Größe von 23 KB auf 16 KB.

Die Bündelgröße ist in 4.3.2 gleich
https://bundlephobia.com/result?p=@sentry/browser @4.3.2 unabhängig von den Änderungen ab
https://github.com/getsentry/sentry-javascript/pull/1738 :(

@vkrol Wir mussten die von @gaterking vorgenommenen Änderungen rückgängig machen, zumindest für das npm-Paket.
Das Bundle auf CDN sollte dagegen kleiner sein.

Wir werden die Änderungen sicher wieder hinzufügen, aber wir müssen darüber reden, da wir zum Beispiel eine Abhängigkeit von tslib brauchen.
Auch wie Typisierungen generiert wurden, war kaputt.

@ HazAT OK, danke.

@vkrol Wir mussten die von @gaterking vorgenommenen Änderungen rückgängig machen, zumindest für das npm-Paket.
Das Bundle auf CDN sollte dagegen kleiner sein.

Wir werden die Änderungen sicher wieder hinzufügen, aber wir müssen darüber reden, da wir zum Beispiel eine Abhängigkeit von tslib brauchen.
Auch wie Typisierungen generiert wurden, war kaputt.

Hoffe so schnell wie möglich.

@gaterking @kamilogorek Bereits behoben https://github.com/getsentry/sentry-javascript/pull/1751
Wir mussten einfach eine "dringende" Veröffentlichung machen, deshalb haben wir sie rückgängig gemacht.

Auf der Client-Seite möchte ich im Grunde, dass dies Fehler erfasst und an die API übermittelt.

Was macht diese Bibliothek sonst noch so komplex?

Es ist wirklich schwer zu verstehen, warum ein einfacherer Fehlermelder einen so großen Fußabdruck haben muss 😐

@mindplay-dk Es liegt hauptsächlich daran, dass JavaScript und Browser ein Chaos sind ^^
Wir müssen viel kaputte/falsche Stack-Traces reparieren.
Die einfache Aufgabe, „nur Fehler abzufangen“, ist auch viel komplexer, als es scheint.

Es ist wirklich schwer zu verstehen, warum ein einfacherer Fehlermelder einen so großen Fußabdruck haben muss 😐

@mindplay-dk weil es nicht einfach ist.

Hier ist der Code, um einfach Fehler in allen Browsern zu erfassen und sie in einer verwendbaren Datenstruktur zu vereinheitlichen: https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/tracekit.ts

Gut gemacht bei der jüngsten Größenreduzierung, sehr geschätzt. 👍

Ein kurzer Blick auf die verlinkte Datei zeigt Code zur Behandlung von Fehlern für Opera 10, wird das wirklich noch benötigt? TraceKit berücksichtigt auch nicht die (derzeit) 2-fache Größenzunahme von Raven, die bereits groß war.

Einige Vorschläge:

• md5 entfernen
• Reduzieren Sie die Verwendung von async/await, es lässt sich schlecht in ES5 kompilieren. Vergleichen Sie https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/baseclient.ts#L307 -L378 mit dem Ausgabecode (suchen Sie „processEvent“ im Produktionspaket). Diese gesamte Datei wird im Produktionspaket riesig.

Gibt es einen gemeinsam genutzten Code ( app:///${base} in rewriteframes.ts) in anderen Paketen wie Paket/Kern? Sie werden nicht vom Client, sondern vom Knoten verwendet.

weil es nicht einfach ist.

@kamilogorek huch, du hast offensichtlich recht ... Mir wurde klar, dass JavaScript ein Chaos war - ich glaube, ich habe mich noch nie mit diesem Bereich befasst, ich wusste nicht, wie schlimm das war. Ich denke, es gibt wirklich keine einfache Möglichkeit, Stack-Traces in JS zu handhaben. Gerade. Huch. 😐

Anstatt nur zu versuchen, Helfer zu minimieren, könnten Sie einfach die bereits erwähnten esm-Dateien bereitstellen, das ist einfach und heute sogar eine bewährte Methode.

Reduzieren Sie die Verwendung von async/await, es lässt sich schlecht in ES5 kompilieren. Vergleichen Sie https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/baseclient.ts#L307 -L378 mit dem Ausgabecode (suchen Sie „processEvent“ im Produktionspaket). Diese gesamte Datei wird im Produktionspaket riesig.

Das ist der falsche Weg, anstatt weiter für ES5 zu optimieren, ist es wichtiger, für 80.07% zu optimieren, die moderne Browser verwenden.

Für alle, die Unterstützung für alte Browser benötigen:
Asynchrone Funktionen werden von jedem Browser unterstützt, der <script type="module"> (caniuse: esm , async ) unterstützt, sodass nur Benutzer älterer Browser länger warten müssen (bei ihnen dauert es sowieso länger).

Nachweisen:
160 KB (es5, gebündelt) > 119 KB (esm, reine Dateien)

Also bündeln Sie bitte die ESM-Datei (auch), es ist so einfach wie das Ändern der Einstellung module und target in /tsconfig.esm.json (das tsconfig.build.json ) zu esnext , fügen Sie tsconfig.esm.json Dateien ähnlich den tsconfig.build.json Dateien zu den Paketen hinzu, fügen Sie sie dem Build und dem Paket hinzu und geben Sie einen Moduleintrag in package.json

Wenn Sie möchten, kann ich eine PR dafür hinzufügen.

Wenn Sie möchten, kann ich eine PR dafür hinzufügen.

Ich würde das @cromefire lieben :)

Wäre toll, wenn es eine Option gäbe, zwischen klassischem und modernem Modus zu wählen, wie vue cli. Wobei die moderne Version nur die meisten modernen Browser unterstützt und daher weniger aufgebläht sein könnte.

Oder noch besser, wenn es wie webpack env funktionieren könnte, sodass der Benutzer die benötigte Browserunterstützung angeben könnte. Ofc, das ist kein einfaches Feature, aber ich wollte es nur rauswerfen :)

Tolles Produkt!

Mit diesem neuen PR können Sie babel so konfigurieren, wie Sie möchten, dass nur die Browser unterstützt werden, die Sie benötigen

Die Größe von @sentry/browser ist mehr als doppelt so groß wie die Größe von raven-js: 86 kB gegenüber 39 kB (verkleinert).

FYI: Die Größe der neuesten Version von @sentry/browser wurde auf 91,8 kB erhöht. Quelle: https://bundlephobia.com/result?p=@sentry/browser @4.5.0.

@cromefire Vielen Dank für Ihre Arbeit bei der Optimierung der Bibliotheksgröße!

Ich habe gerade versucht, den neuen esm-Build von v4.5.0 zu verwenden , aber ich habe viele Fehler bekommen. Alle werden ausgelöst, weil Module von @sentry/utils/esm nicht aufgelöst werden konnten.

Tatsächlich habe ich die Ordner in node_modules nach einem neuen yarn install nicht gefunden. (Siehe Screenshot)

 FEHLER in ./node_modules/@sentry/core/esm/baseclient.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/async“ kann nicht in „./node_modules/@sentry/core/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/backend.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/is“ kann nicht in „./node_modules/@sentry/browser/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/tracekit.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/is“ kann nicht in „./node_modules/@sentry/browser/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/is“ kann nicht in „./node_modules/@sentry/browser/esm/integrations“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/is“ kann nicht in „./node_modules/@sentry/browser/esm/integrations“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/pluggable/vue.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/is“ kann nicht in „./node_modules/@sentry/browser/esm/integrations/pluggable“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/baseclient.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/is“ kann nicht in „./node_modules/@sentry/core/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/dsn.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/is“ kann nicht in „./node_modules/@sentry/core/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/is“ kann nicht in „./node_modules/@sentry/core/esm/integrations“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/integrations/extraerrordata.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/is“ kann nicht in „./node_modules/@sentry/core/esm/integrations“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/globalhandlers.js

 Modul nicht gefunden: Fehler: Kann '@sentry/utils/esm/logger' in './node_modules/@sentry/browser/esm/integrations' nicht auflösen

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Modul nicht gefunden: Fehler: Kann '@sentry/utils/esm/logger' in './node_modules/@sentry/browser/esm/integrations' nicht auflösen

 FEHLER in ./node_modules/@sentry/core/esm/baseclient.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/logger“ kann nicht in „./node_modules/@sentry/core/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/basebackend.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/logger“ kann nicht in „./node_modules/@sentry/core/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/sdk.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/logger“ kann nicht in „./node_modules/@sentry/core/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/integration.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/logger“ kann nicht in „./node_modules/@sentry/core/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/integrations/dedupe.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/logger“ kann nicht in „./node_modules/@sentry/core/esm/integrations“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/integrations/sdkinformation.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/logger“ kann nicht in „./node_modules/@sentry/core/esm/integrations“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/logger“ kann nicht in „./node_modules/@sentry/core/esm/integrations“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/hub/esm/hub.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/logger“ kann nicht in „./node_modules/@sentry/hub/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/client.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/browser/esm“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/tracekit.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/browser/esm“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/useragent.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/browser/esm/integrations“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/browser/esm/integrations“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/trycatch.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/browser/esm/integrations“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/browser/esm/integrations“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/pluggable/reportingobserver.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/browser/esm/integrations/pluggable“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/pluggable/vue.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/browser/esm/integrations/pluggable“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/pluggable/ember.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/browser/esm/integrations/pluggable“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/transports/beacon.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/browser/esm/transports“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/transports/fetch.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/browser/esm/transports“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/baseclient.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/core/esm“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/integrations/dedupe.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/core/esm/integrations“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/core/esm/integrations“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/hub/esm/scope.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/hub/esm“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/hub/esm/hub.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/misc“ kann in „./node_modules/@sentry/hub/esm“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/parsers.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/object“ kann nicht in „./node_modules/@sentry/browser/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/object“ kann nicht in „./node_modules/@sentry/browser/esm/integrations“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/trycatch.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/object“ kann nicht in „./node_modules/@sentry/browser/esm/integrations“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/object“ kann nicht in „./node_modules/@sentry/browser/esm/integrations“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/api.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/object“ kann nicht in „./node_modules/@sentry/core/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/basebackend.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/object“ kann nicht in „./node_modules/@sentry/core/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/dsn.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/object“ kann nicht in „./node_modules/@sentry/core/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/hub/esm/scope.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/object“ kann nicht in „./node_modules/@sentry/hub/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/integrations/pluggable/rewriteframes.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/path“ kann nicht in „./node_modules/@sentry/core/esm/integrations/pluggable“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/parsers.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/string“ kann nicht in „./node_modules/@sentry/browser/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/string“ kann in „./node_modules/@sentry/browser/esm/integrations“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/baseclient.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/string“ kann nicht in „./node_modules/@sentry/core/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/string“ kann in „./node_modules/@sentry/core/esm/integrations“ nicht aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/backend.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/supports“ kann nicht in „./node_modules/@sentry/browser/esm“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/supports“ kann nicht in „./node_modules/@sentry/browser/esm/integrations“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/integrations/pluggable/reportingobserver.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/supports“ kann nicht in „./node_modules/@sentry/browser/esm/integrations/pluggable“ aufgelöst werden

 FEHLER in ./node_modules/@sentry/browser/esm/transports/fetch.js

 Modul nicht gefunden: Fehler: „@sentry/utils/esm/supports“ kann nicht in „./node_modules/@sentry/browser/esm/transports“ aufgelöst werden

@pascaliske esm build ist noch in der Experimentierphase und wir haben es noch nicht öffentlich dokumentiert. Wir werden es tun, sobald alles durchgetestet ist, und unsere Ergebnisse hier veröffentlichen.

@kamilogorek Ja, ich weiß. Ich wollte Sie nur über diese Fehler informieren. 🙂

Danke, danke @pascaliske! Wir werden versuchen, ESM-Support so schnell wie möglich bereitzustellen :)

@pascaliske versuche zuerst yarn build

@cromefire Nein, das wird nicht helfen, denke ich. Ich habe das Paket gerade von npm heruntergeladen, daher ist keine Build-Umgebung verfügbar. 🙂

Ich habe den Quellcode etwas durchsucht und @sentry/browser mit @sentry/utils verglichen. Ich denke, das ist das Problem: packages/utils/tsconfig.build.json#L5 vs. packages/browser/tsconfig.build.json#L5 . Ist es möglich, dass die normale Build-Ausgabe die esm-Build-Ausgabe überschreibt? 🤔

In meinem Ordner node_modules enthält das Paket browser Build-Ausgaben von normal und esm. Das Paket utils enthält jedoch nur die normale Build-Ausgabe im Stammordner.

Ist es schon freigegeben?

Ich habe den Quellcode ein wenig durchsucht und @sentry/browser mit @sentry/utils verglichen. Ich denke, das ist das Problem: packages/utils/tsconfig.build.json#L5 vs. packages/browser/tsconfig.build.json#L5 . Ist es möglich, dass die normale Build-Ausgabe die esm-Build-Ausgabe überschreibt? 🤔

Nein, Sie müssen sich die esm tsconfig ansehen

Werde es mir morgen anschauen

Hey alle zusammen! Wir stochern auch in Sentry in einigen Paketgrößen herum und sind auf Folgendes gestoßen: https://github.com/getsentry/sentry-javascript/blob/master/packages/minimal/package.json#L20

Sieht so aus, als würde es für sehr wenige Funktionen (Verteilen und Zuweisen) ein Stück Größe hinzufügen. Ich bin mit Typescript nicht sehr vertraut, aber ist es dafür zur Laufzeit notwendig?

Es ist mir auch unklar, warum @sentry/types eine _Laufzeit_-Abhängigkeit sein muss und sich nicht in devDependencies befindet ...

@evocateur für alle Benutzer von Schreibmaschinenschrift ist dies erforderlich. Typescript optimiert alles weg.
(kann aber für die .d.ts Dateien benötigt werden)

@IanMitchell Es wird nicht für den ESM-Build verwendet, sondern für normale

Die bundle.js von 4.5.0 enthält viel doppelten Code, wie Severity, htmlElementAsString, htmlElementAsString, uuid4, parseUrl und so weiter. Das kann nicht gewollt sein!

Dasselbe passiert, wenn ich ein Bundle über import * as Sentry from '@sentry/browser'; (als einzige Zeile in der Datei) mit WebPack + Babel 7 mache, dann beträgt die gebündelte Größe 326 KB. Siehe: sentry.bundle.js.txt
Wir verwenden dieselbe Konfiguration auch für unsere anderen Bundles, aber Sentry ist das einzige Bundle mit diesem Problem.

Die bundle.min.js enthält keinen doppelten Code , was ein Ergebnis von Tree Shaking mit Rollup sein kann.

Eine vorübergehende Lösung ist also die Verwendung import '@sentry/browser/build/bundle.min.js';

Die bundle.js von 4.5.0 enthält viel doppelten Code, wie Severity, htmlElementAsString, htmlElementAsString, uuid4, parseUrl und so weiter. Das kann nicht gewollt sein!

Aus diesem Grund (oder zumindest aus einem Grund) gibt es den esm -Build. Wenn Sie sowieso einen Bundler haben, ist dies effizienter als die Verwendung eines vorgefertigten Bundles. (Es ist nur Beta und im Moment noch kaputt)

Wenn ich mir das noch einmal ansehe, glaube ich nicht, dass das nicht kleiner sein könnte. Viel kleiner.

Stack-Traces mit Source-Map-Unterstützung sollten bei weitem das Komplexeste in dieser Bibliothek sein - und es sieht nicht danach aus? Es scheint, als ob der größte Teil des Fußabdrucks vom Kern-Framework stammt, das es mit dem node.js-Client teilt, wo ich sicher bin, dass der Fußabdruck kein wirkliches Problem darstellt.

Verstehen Sie mich nicht falsch, dies ist ein wunderschönes Stück Architektur – sehr schöne TypeScript-Arbeit.

Aber auf der Client-Seite bedeutet das nicht viel. Es muss klein sein und schnell geladen werden - besonders für etwas so Low-Level wie dieses spielt es keine Rolle, ob der Quellcode schön ist oder nicht. Soweit ich das beurteilen kann, ist alles, was beeindruckend ist, Architektur, die viele Bytes auf der ganzen Linie kostet.

Zum Vergleich:

Ich bin auf TrackJS gestoßen , das ähnliche Funktionen (browserübergreifendes Stack-Trace mit Source-Maps) in einem ~10-KB-Paket hat.

Das ursprüngliche TraceKit ist ~3KB min+gz.

Ich habe diese Bibliothek gefunden, die das Source-Map-Bit (auf der Client-Seite) in ~ 8 KB min + gz oder ~ 10 KB mit X-Browser-Polyfills ausführen kann.

Darüber hinaus müssen ein paar Browserinformationen gesammelt, im erwarteten JSON-Format verpackt und gepostet werden - was nicht mehr als ein paar KB min+gz sein sollte. Sollte es?

Ich habe das Gefühl, dass dies einfach viel mehr Architektur ist, als die meisten Menschen brauchen. Wenn ich überhaupt Plugin-Unterstützung benötige, brauche ich vielleicht einen einfachen Hook, mit dem ich Informationen in den JSON-Post einfügen kann, aber das war es auch schon.

Ich weiß, dass es heutzutage üblich ist, Megabytes von JS bereitzustellen, aber wir haben strenge Inhaltsrichtlinien bei der Arbeit, um sicherzustellen, dass wir Projekte versenden, die schnell auf Mobilgeräte geladen werden, und ich kann es nicht rechtfertigen, mehr als die Hälfte unseres JS-Budgets für Fehler auszugeben. Protokollierung - vielleicht 10 % tops, also scheint etwas wie ~ 15-20 KB vernünftig zu sein.

Ich liebe Ihr Produkt, aber ich kann diesen Client nicht bereitstellen 😐

Für so etwas könnte es eine gute Idee sein, den Stacktrace und das Parsing der Source-Map an den Server zu delegieren, wo die Größe irrelevant ist

Für so etwas könnte es eine gute Idee sein, den Stacktrace und das Parsing der Source-Map an den Server zu delegieren, wo die Größe irrelevant ist

@cromefire interessante Idee. Ich frage mich, ob das zB TrackJS tut, um die Größe gering zu halten? (Ihr Client ist proprietär - nur die minimierte Quelle ist verfügbar, daher ist es schwer zu sagen, was sie tun. Angenommen, ich könnte es installieren und sehen, was über die Leitung wandert ...)

Hier ist ein einfacheres Paket zum Auflösen von Quellkarten im Browser: source-map-resolve at ~2KB min+gz ... das ist ohne Polyfills, aber (wenn das funktioniert) Ich denke, wir sollten in der Lage sein, ~10KB für zu erreichen moderne Browser, die keine Polyfills benötigen.

das ist ohne Polyfills

Polyfills sollten nicht im esm -Build sein, das könnte also auch funktionieren, aber im Bachend wären es noch weniger

@cromefire ESM-Build sollte jetzt in 4.5.1 verfügbar sein. Noch nicht dokumentiert, da wir sicherstellen wollen, dass es kampferprobt ist, aber so weit, so gut. Ich habe den regulären Webpack-Build mit dem Babel Loader überprüft und es funktioniert wie ein Zauber.

Darüber hinaus müssen ein paar Browserinformationen gesammelt, im erwarteten JSON-Format verpackt und gepostet werden - was nicht mehr als ein paar KB min+gz sein sollte. Sollte es?

@mindplay-dk Wir führen keine Stack-Trace-Auflösung auf der Client-Seite durch. Es wird alles auf dem Server erledigt, deshalb müssen Sie zunächst Quellkarten hochladen, um Unterstützung dafür zu erhalten.

Was wir jedoch tun, ist:

• Ereignisprozessoren, um benutzerdefinierte Hooks bereitzustellen, mit denen Sie an Sentry gesendete Daten ändern/filtern/verbessern können
• Kümmern Sie sich um das gesamte native API-Wrapping
• Erfassen Sie Breadcrumbs aus allen Benutzerinteraktionen, Netzwerkanrufen und Navigationen
• User-Agent-Daten extrahieren
• Extrahieren Sie zusätzliche Fehlerdaten aus verknüpften Fehlern, sodass Sie wie in anderen Sprachen mehrere Fehlerebenen erstellen können
• Hören Sie auf beide globalen Fehlerbehandlungsroutinen
• Bereitstellung mehrerer Netzwerktransporte, sodass der Benutzer immer den besten für seine aktuelle Umgebung erhält
• Kümmern Sie sich um Zehntel von Randfällen und verschiedene Fehlerobjekte (sogar benutzerdefinierte) und verschiedene native Implementierungen
• Bereitstellung von Fallbacks für Ersatz- oder defekte Fehlerinformationen
• Ereignisse puffern, damit Sie Ihre eigene Sentry-Instanz nicht überfluten oder keine freien Ereignisse mehr haben, wenn etwas schief geht

Nur um ein paar zu nennen. Ich wünschte wirklich, es wäre so einfach wie "Fehler abfangen, Daten hinzufügen und durchsenden".
In der realen Welt gibt es jedoch Dutzende von Eingaben, Dutzende von Fehlerquellen (die alle unterschiedliche Daten liefern) und Dutzende von Umgebungen, die sich im Verhalten unterscheiden.
Wir werden definitiv weiter daran arbeiten, wie wir das auf ~10-15kB herunterbekommen, aber es wird einige Zeit dauern. Wir haben nur so viele Ressourcen (gelesene Personen/Zeit), die wir jetzt aufwenden können.

Ich weiß, dass es heutzutage üblich ist, Megabytes von JS bereitzustellen, aber wir haben strenge Inhaltsrichtlinien bei der Arbeit, um sicherzustellen, dass wir Projekte versenden, die schnell auf Mobilgeräte geladen werden, und ich kann es nicht rechtfertigen, mehr als die Hälfte unseres JS-Budgets für Fehler auszugeben. Protokollierung - vielleicht 10 % tops, also scheint etwas wie ~ 15-20 KB vernünftig zu sein.

Sie können dann unseren Loader verwenden – https://docs.sentry.io/platforms/javascript/loader/ :)

Sie können dann unseren Loader verwenden – https://docs.sentry.io/platforms/javascript/loader/ :)

Aber es gibt leider keine Lösung für Webpack

Nur um ein paar zu nennen. Ich wünschte wirklich, es wäre so einfach wie "Fehler abfangen, Daten hinzufügen und durchsenden".

Vielleicht sollte jemand bei tc39 etwas

Aber es gibt leider keine Lösung für Webpack

Was genau meinst du? Haben Sie ein Paket, das mit dem Loader koexistieren könnte, das importiert und gebündelt werden könnte, aber dann mit dem asynchron geladenen SDK kommuniziert, sobald ein Fehler oder ein captureException-Aufruf auftritt?

Was genau meinst du? Haben Sie ein Paket, das mit dem Loader koexistieren könnte, das importiert und gebündelt werden könnte, aber dann mit dem asynchron geladenen SDK kommuniziert, sobald ein Fehler oder ein captureException-Aufruf auftritt?

Ja, wenn ich es richtig zusammenfasse, ist der Loader nur über eine CDN verfügbar

@cromefire ja, weil es als "Snippet" verwendet werden soll. Den Code finden Sie jedoch hier https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/loader.js

Anscheinend muss ich einen neuen PR öffnen, denn mit esm wäre dies auch aus Ihrem eigenen Code nutzbar

Wir haben eine Lösung in Vorbereitung, mit der Sie loader neben minimal verwenden können und Ihrem endgültigen Paket effektiv nur ein paar kB hinzufügen.

Es sollte nicht schwer sein, einen Loader zu schreiben, der das in weniger als 1 KB lädt, also warum nicht, ich werde versuchen, einen schnellen zu schreiben

Eine Sache, die hier sehr hilfreich sein könnte, ist, wenn einige der Funktionen optional sind.

Ein wirklich nettes Minimum könnte zum Beispiel sein:

• nativer Fehler-Stack-Trace (egal, dass es auf einigen Browsern nicht optimal ist)
• User-Agent
• Zeitstempel
• URL
• Übereinstimmung mit Quellkarten auf dem Server

Alle zusätzlichen Funktionen können nur ein Add-on sein. Wir unterstützen nur moderne Browser, daher müssen wir nicht all das skurrile Verhalten alter Browser umgehen.

Wir haben dies gelöst, indem wir Webpack-Code-Splitting verwendet haben und den Sentry-Client nur im Fehlerfall geladen haben.

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

Wir machen dort noch mehr, wie Breadcrumbs füllen, Extras hinzufügen, Tags hinzufügen usw., aber es ist möglich, den Sentry-Client zu verwenden, ohne Ihr Bündel zu vergrößern.

Dies ist in etwa das, was ich in #1846 implementiert habe

Könnte für andere hilfreich sein:
Ich habe den ESM-Build mit Webpack ( 4.29.5 ) verwendet von:

• Hinzufügen eines Webpack-Alias, um den ESM-Build anstelle des Standard-Builds zu verwenden, da es keine module -Deklaration in package.json gibt

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',
        ),
    }

• fügen Sie einen Ausschluss für sentry/.+/esm zu unserer babel-loader -Konfiguration hinzu, da der ESM-Build anscheinend neuere Funktionen als ES2015 enthält.

{
    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)\//,
}

Anmerkungen:

• Wir haben Aliase verwendet, damit wir uns bei der Verwendung im Code keine Gedanken über die Bündelung machen müssen (unter anderem machen wir ähnliches für lodash-es ).

@ Limess

Sie können einfach zu @sentry/browser/esm umleiten:

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

Aber Sie müssen keinen Alias ​​hinzufügen, importieren Sie einfach @sentry/browser/esm

Für den Loader ist es einfacher, es so zu schreiben:

• Wenn Sie andere Dinge in babel haben:

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

• Falls nicht:

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

Denken Sie auch daran, die babel-Konfiguration an Ihre Bedürfnisse anzupassen: babel docs , sonst lohnt es sich nicht, die esm-Version zu verwenden

Update: Wir werden in Kürze eine neue Hauptversion des SDK veröffentlichen, die die Paketgröße erheblich reduziert.

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

Unsere vorgefertigten CDN-Versionen zeigen sogar bessere Ergebnisse (nicht sicher, wie Bündelphobie Dinge misst)

ES6:  14.3535 kB
ES5:  15.6846 kB

Wie auch immer, ich wollte Sie wissen lassen, dass wir immer noch daran arbeiten, die Bundle-Größe weiter zu reduzieren, aber das sollte bereits ein großer Schritt in die richtige Richtung sein.

Hinweis zum Upgrade: Es ist ein großer Nachteil, da es viele interne Änderungen im SDK gibt. Auf Ihrer Seite sollten keine Codeänderungen erforderlich sein. Wir testen die neue Version derzeit selbst auf sentry.io, um zu sehen, wie sie sich verhält. Referenz: https://github.com/getsentry/sentry/pull/12492

Haftungsausschluss: Verwenden Sie 5.0.0-rc.x noch nicht in der Produktion, wie wir es tun 🙈

@HazAT danke, dass du das ernst nimmst! das ist ein großer Schritt nach vorne - ich mache mir jetzt schon viel weniger Gedanken darüber, dies einzusetzen :-)

@kamilogorek Nur aus Neugier, könntest du die letzte Version aus dem Zweig 3.x zum Vergleich hinzufügen?

Ich schließe dieses Thema ab jetzt, wir denken, dass die von uns eingeführte Reduzierung von v4 zu v5 ein Trend in die richtige Richtung ist. Wir werden weiterhin versuchen, ihn weiter zu reduzieren, und wir werden ihn sehr bewusst immer wieder erhöhen.

Als kurze Bemerkung möchten wir wirklich nur unsere "Bundle" -Größe vergleichen, da Ihre Laufleistung je nach Bundler, den Sie verwenden, variieren kann. Hier ist also die CDN-Bundle-Nummer, die wir versenden (ped):

| Paket | Ausführung | Größe in Bytes | Größe in kB | Verbindung |
|-----------------|---------|---------------|----- -------|-------------------------------------------------- ----------|
| rabe-js | 3.27.0 | 13741 Bytes | ~13,4kB | https://cdn.ravenjs.com/3.27.0/raven.min.js |
| @Sentry/Browser | 4.6.6 | 22607 Bytes | ~22,1kB | https://browser.sentry-cdn.com/4.6.6/bundle.min.js |
| @Sentry/Browser | 5.0.3 | 16059 Bytes | ~15,7kB | https://browser.sentry-cdn.com/5.0.3/bundle.min.js |

Mit v5 liefern und bauen wir auch esm , was bedeutet, wenn Sie einen Bundler verwenden, sollte dieser in der Lage sein, ungenutzte Codepfade zu baumeln.

Danke euch allen für eure Geduld 🙇

@HazAT @kamilogorek großartig!

@Limess Ist es heute noch relevant, dies zu verwenden: @sentry/browser/esm anstelle von @sentry/browser ?

Es wird wie import * as Sentry from "@sentry/browser/esm"; importiert und mit webpack -p gebündelt, aber ich sehe keinen Unterschied in den Bündelgrößen. Ich habe auch nur webpack.config.js ohne Plugins oder Loader.

@0xbkt Es macht keinen Unterschied in der Bündelgröße , zumindest jetzt nicht, wenn Rollup zum Bündeln von Apps verwendet wird.