Sentry-javascript: @sentry/tamanho do navegador

Ei, obrigado por trazer isso à tona.
Embora entendamos e geralmente concordemos com suas preocupações sobre o tamanho do pacote, acho justo comparar primeiro os tamanhos do pacote gzip em vez do tamanho do arquivo minificado descompactado:

@sentry/browser é 21,3799 KB
raven-js 13,44 KB

Além disso, embora isso possa não ser aplicável a todos, fornecemos e geralmente orientamos as pessoas a usar nosso CDN Loader, que configurará o SDK para você em seu site.

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

A pegada e o impacto no tempo de carregamento da página deste script foi compactado em <1 KB, mantendo a mesma funcionalidade.

então tl;dr:
Estamos cientes disso, sabemos que há espaço para melhorias, mas não é prioridade no momento.

Acho justo comparar primeiro os tamanhos do pacote gzip em vez do tamanho do arquivo minificado descompactado:

Eu diria que também é justo comparar tamanhos reduzidos, pois os problemas de desempenho não surgem apenas do download de javascript, mas também da análise e execução. ~ 92kb é bastante robusto e pode adicionar até 1s de tempo de análise em dispositivos de baixo custo (apenas para esta biblioteca!).

Não tenho certeza de onde você tirou o número de < 1KB para o script CDN. Você poderia detalhar? Quando abro https://browser.sentry-cdn.com/4.0.4/bundle.min.js , vejo um tamanho compactado de 22 KB.

Você deve estar ciente de que o SDK do sentry é apenas uma das muitas bibliotecas que os desenvolvedores incluem.

PS: Eu amo sentinela, tem sido super útil para nós. O desempenho na Web é apenas algo pelo qual sou apaixonado. ;)

@klaemo
Hehe, não se preocupe 😅

Como eu disse, estamos cientes e não é como se não queremos que seja menor.
A prioridade mais alta para nós era enviar o novo SDK, trabalharemos para melhorar o tamanho do pacote ao longo do tempo.
Existem muitos outros passos que podemos tomar, por exemplo: use tslib , combine strings ...
Portanto, há muito espaço para melhorias.

Desculpe, o link que postei antes já está desatualizado 🙃
Eu estava me referindo ao _Loader_: https://docs.sentry.io/platforms/javascript/loader/
Embora o _Loader_ também tenha suas limitações devido à sua natureza assíncrona e no final, ele ainda busca e injeta o SDK (mesmo que seja assíncrono) é uma alternativa que oferecemos porque as pessoas pediram.

@HazAT Desculpe, pessoal, mas você pode fornecer a data de lançamento da próxima versão?
Quer dizer, já existem algumas mudanças no branch #master mas ainda não lançadas. Aquele que está decidindo se a versão 4x é utilizável para projetos Angular5+.

@rayzru Acabou de lançar 4.0.5 , mas por favor mantenha posts relacionados ao tópico.

Na minha opinião, isso é definitivamente uma regressão e o motivo sério para não atualizar para a nova versão.

💯 Eu estava prestes a atualizar até perceber que:

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

Pelo menos o tamanho do pacote é menor , mas acho que ⚠️ +10 KB de JavaScript gzipado em um pacote é significativo. Vamos esperar, continuem o bom trabalho :)

@HazAT Poderia ser possível gerar arquivos esm. Isso permitiria que o webpack tivesse melhores resultados com concatenação e trepidação de árvores.

Você pode querer adicionar alguma ferramenta de CI para rastrear o tamanho do pacote para cada solicitação de mesclagem. Desde que este problema cresceu para 100 kB, veja https://bundlephobia.com/result?p=@sentry/browser @4.3.0

Tente, por exemplo, https://github.com/siddharthkp/bundlesize

O orçamento de desempenho padrão para um ponto de entrada no Webpack é de 250 kb para garantir um desempenho decente em qualquer dispositivo e rede. 100 kb de Sentry ocupam bastante desse orçamento.

Por favor, mantenha-nos atualizados se a correção dessa regressão estiver no roteiro ou se a biblioteca continuar crescendo sem um orçamento de tamanho.

Somos clientes pagantes e investimos fortemente no Sentry tanto no backend, nativo e na web, mas uma atualização para mais de 3x o tamanho da biblioteca ([email protected] é 31 kB) não é algo que possamos justificar.

@jacobrask Você pode ficar com a versão mais antiga da biblioteca, é o que fazemos em https://www.onepixel.com/ , está funcionando bem 👌.

@jacobrask Definitivamente está em nossa lista e também achamos que existem algumas frutas fáceis onde podemos reduzir facilmente o tamanho do nosso pacote.
Mais e mais pessoas pedem isso, então provavelmente resolveremos isso mais cedo do que o esperado.

@HazAT
O pacote cumulativo do SDK do navegador Sentry pode ser otimizado. No arquivo bundle min js, há muitos códigos tslib repetidos. Como __generator, __assign. No env do navegador, é melhor compartilhar um código. Mas o projeto do navegador usa outro arquivo dist de pacotes. Talvez reduza o tamanho do gzip de 23K para 16K.

O tamanho do pacote é o mesmo em 4.3.2
https://bundlephobia.com/result?p=@sentry/browser @4.3.2 independentemente das alterações de
https://github.com/getsentry/sentry-javascript/pull/1738 :(

@vkrol Tivemos que reverter as alterações que o @gaterking fez, pelo menos para o pacote npm.
O pacote no CDN, por outro lado, deve ser menor.

Com certeza iremos re-adicionar as alterações, mas precisamos falar sobre isso, pois precisamos de um dep em tslib por exemplo.
Além disso, a forma como as tipagens foram geradas foi quebrada.

@HazAT OK, obrigado.

@vkrol Tivemos que reverter as alterações que o @gaterking fez, pelo menos para o pacote npm.
O pacote no CDN, por outro lado, deve ser menor.

Com certeza iremos re-adicionar as alterações, mas precisamos falar sobre isso, pois precisamos de um dep em tslib por exemplo.
Além disso, a forma como as tipagens foram geradas foi quebrada.

Espero o quanto antes.

@gaterking @kamilogorek Já corrigiu https://github.com/getsentry/sentry-javascript/pull/1751
Nós apenas tivemos que fazer um lançamento "urgente" e é por isso que o revertemos.

No lado do cliente, basicamente quero que isso capture erros e os envie para a API.

O que mais essa biblioteca está fazendo de tão complexo?

É realmente difícil entender por que um relator de erros mais simples precisa ter uma pegada tão substancial 😐

@mindplay-dk É principalmente porque JavaScript e navegadores são uma bagunça ^^
Precisamos consertar muito os rastreamentos de pilha quebrados/errados.
A simples tarefa de "apenas pegar erros" também é muito mais complexa do que parece.

É realmente difícil entender por que um relator de erros mais simples precisa ter uma pegada tão substancial 😐

@mindplay-dk porque não é simples.

Aqui está o código para apenas capturar erros em todos os navegadores e unificá-los em uma estrutura de dados utilizável: https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/tracekit.ts

Bem feito na recente redução de tamanho, muito apreciado. 👍

Uma rápida olhada no arquivo vinculado mostra o código para lidar com erros do Opera 10, isso ainda é necessário? O TraceKit também não leva em conta o (atualmente) aumento de tamanho de 2x do Raven, que já era grande.

Algumas sugestões:

• Remover md5
• Reduza o uso de async/await, ele compila mal para ES5. Compare https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/baseclient.ts#L307 -L378 com o código de saída (pesquise "processEvent" no pacote de produção). Esse arquivo inteiro se torna enorme no pacote de produção.

Existe algum código compartilhado ( app:///${base} em rewriteframes.ts) em outros pacotes, como package/core? Eles não são usados ​​pelo cliente, mas usados ​​pelo nó.

porque não é simples.

@kamilogorek caramba, você obviamente está certo... Percebi que JavaScript era uma bagunça - acho que nunca mergulhei nessa área antes, não percebi o quão ruim isso era. Eu acho que não há realmente uma maneira simples de lidar com rastreamentos de pilha em JS. Somente. Caramba. 😐

Em vez de apenas tentar minimizar os auxiliares, você pode fornecer os arquivos esm já mencionados, isso é fácil e até mesmo uma prática recomendada hoje.

Reduza o uso de async/await, ele compila mal para ES5. Compare https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/baseclient.ts#L307 -L378 com o código de saída (pesquise "processEvent" no pacote de produção). Esse arquivo inteiro se torna enorme no pacote de produção.

Esse é o caminho errado, em vez de otimizar ainda mais para o ES5, é mais importante otimizar para 80.07% que estão usando navegadores modernos.

Para todos que precisam de suporte a navegadores antigos:
As funções assíncronas são suportadas por qualquer navegador que suporte <script type="module"> (caniuse: esm , async ) para que apenas os usuários de navegadores mais antigos precisem esperar mais (de qualquer forma, leva mais tempo para eles)

Prova:
160 KB (es5, empacotado) > 119 KB (esm, arquivos simples)

Então, por favor, agrupe o arquivo esm (também), é tão fácil quanto alterar a configuração module e target em /tsconfig.esm.json (que estende tsconfig.build.json ) para esnext , adicionando arquivos tsconfig.esm.json semelhantes aos arquivos tsconfig.build.json aos pacotes, adicione-os à compilação e ao pacote e especifique uma entrada de módulo no package.json

Se você quiser, posso adicionar um PR para isso.

Se você quiser, posso adicionar um PR para isso.

Eu adoraria isso @cromefire :)

Seria incrível se houvesse uma opção para selecionar entre o modo clássico e moderno, como vue cli. Onde a versão moderna tem suporte apenas para a maioria dos navegadores modernos e, portanto, pode ser menos inchada.

Ou ainda melhor se pudesse funcionar como webpack env, para que o usuário pudesse especificar o suporte do navegador necessário. Ofc, esse não é um recurso fácil, mas só queria jogá-lo lá fora :)

Produto incrível!

Com esse novo PR você pode configurar o babel como quiser suportar apenas os navegadores que você precisa

O tamanho do @sentry/browser é duas vezes maior que o tamanho do raven-js: 86 kB vs 39 kB (minificado).

FYI: o tamanho da versão mais recente de @sentry/browser foi aumentado para 91,8 kB . Fonte: https://bundlephobia.com/result?p=@sentry/browser @4.5.0.

@cromefire Obrigado pelo seu trabalho com a otimização do tamanho da biblioteca!

Acabei de tentar usar a nova compilação esm da v4.5.0 , mas recebi muitos erros. Todos eles são acionados porque os módulos de @sentry/utils/esm não puderam ser resolvidos.

Na verdade, não encontrei as pastas em node_modules após um novo yarn install . (Veja captura de tela)

 ERRO em ./node_modules/@sentry/core/esm/baseclient.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/async' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/browser/esm/backend.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/is' em './node_modules/@sentry/browser/esm'

 ERRO em ./node_modules/@sentry/browser/esm/tracekit.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/is' em './node_modules/@sentry/browser/esm'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/is' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/is' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/pluggable/vue.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/is' em './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERRO em ./node_modules/@sentry/core/esm/baseclient.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/is' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/core/esm/dsn.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/is' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/is' em './node_modules/@sentry/core/esm/integrations'

 ERRO em ./node_modules/@sentry/core/esm/integrations/extraerrordata.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/is' em './node_modules/@sentry/core/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/globalhandlers.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/logger' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/logger' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/core/esm/baseclient.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/logger' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/core/esm/basebackend.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/logger' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/core/esm/sdk.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/logger' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/core/esm/integration.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/logger' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/core/esm/integrations/dedupe.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/logger' em './node_modules/@sentry/core/esm/integrations'

 ERRO em ./node_modules/@sentry/core/esm/integrations/sdkinformation.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/logger' em './node_modules/@sentry/core/esm/integrations'

 ERRO em ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/logger' em './node_modules/@sentry/core/esm/integrations'

 ERRO em ./node_modules/@sentry/hub/esm/hub.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/logger' em './node_modules/@sentry/hub/esm'

 ERRO em ./node_modules/@sentry/browser/esm/client.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/browser/esm'

 ERRO em ./node_modules/@sentry/browser/esm/tracekit.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/browser/esm'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/useragent.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/trycatch.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/pluggable/reportingobserver.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/pluggable/vue.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/pluggable/ember.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERRO em ./node_modules/@sentry/browser/esm/transports/beacon.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/browser/esm/transports'

 ERRO em ./node_modules/@sentry/browser/esm/transports/fetch.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/browser/esm/transports'

 ERRO em ./node_modules/@sentry/core/esm/baseclient.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/core/esm/integrations/dedupe.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/core/esm/integrations'

 ERRO em ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/core/esm/integrations'

 ERRO em ./node_modules/@sentry/hub/esm/scope.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/hub/esm'

 ERRO em ./node_modules/@sentry/hub/esm/hub.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/misc' em './node_modules/@sentry/hub/esm'

 ERRO em ./node_modules/@sentry/browser/esm/parsers.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/object' em './node_modules/@sentry/browser/esm'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/object' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/trycatch.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/object' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/helpers.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/object' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/core/esm/api.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/object' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/core/esm/basebackend.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/object' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/core/esm/dsn.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/object' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/hub/esm/scope.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/object' em './node_modules/@sentry/hub/esm'

 ERRO em ./node_modules/@sentry/core/esm/integrations/pluggable/rewriteframes.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/path' em './node_modules/@sentry/core/esm/integrations/pluggable'

 ERRO em ./node_modules/@sentry/browser/esm/parsers.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/string' em './node_modules/@sentry/browser/esm'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/string' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/core/esm/baseclient.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/string' em './node_modules/@sentry/core/esm'

 ERRO em ./node_modules/@sentry/core/esm/integrations/inboundfilters.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/string' em './node_modules/@sentry/core/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/backend.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/supports' em './node_modules/@sentry/browser/esm'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/supports' em './node_modules/@sentry/browser/esm/integrations'

 ERRO em ./node_modules/@sentry/browser/esm/integrations/pluggable/reportingobserver.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/supports' em './node_modules/@sentry/browser/esm/integrations/pluggable'

 ERRO em ./node_modules/@sentry/browser/esm/transports/fetch.js

 Módulo não encontrado: Erro: Não é possível resolver '@sentry/utils/esm/supports' em './node_modules/@sentry/browser/esm/transports'

@pacaliske esm build ainda está em fase de experimentação e ainda não documentamos publicamente. Faremos isso assim que tudo for testado e publicaremos nossas descobertas aqui.

@kamilogorek Sim, eu sei. Só queria que você soubesse desses erros. 🙂

Obrigado, obrigado @pascaliske! Tentaremos fornecer suporte ao ESM o mais rápido possível :)

@pascaliske tente yarn build primeiro

@cromefire Não, isso não vai ajudar, eu acho. Acabei de baixar o pacote do npm, então não há ambiente de compilação disponível. 🙂

Pesquisei um pouco no código-fonte e comparei @sentry/browser com @sentry/utils . Acho que este é o problema: packages/utils/tsconfig.build.json#L5 vs. packages/browser/tsconfig.build.json#L5 . É possível que a saída de compilação normal sobrescreva a saída de compilação esm? 🤔

Dentro da minha pasta node_modules, o pacote browser contém saída de compilação de normal e esm. Mas o pacote utils contém apenas a saída de compilação normal na pasta raiz.

Já está lançado?

Pesquisei um pouco no código-fonte e comparei @sentry/browser com @sentry/utils . Acho que este é o problema: packages/utils/tsconfig.build.json#L5 vs. packages/browser/tsconfig.build.json#L5 . É possível que a saída de compilação normal sobrescreva a saída de compilação esm? 🤔

Não, você tem que olhar para o esm tsconfig

vai ver amanhã

Olá a todos! Também estamos pesquisando alguns tamanhos de pacotes no Sentry e encontramos isso: https://github.com/getsentry/sentry-javascript/blob/master/packages/minimal/package.json#L20

Parece que está adicionando um pedaço de tamanho para muito poucas funções (distribuir e atribuir). Não estou super familiarizado com o Typescript, mas é necessário para isso em tempo de execução?

Também não está claro para mim por que @sentry/types precisa ser uma dependência _runtime_ e não localizada em devDependencies ...

@evocateur para todos os usuários de texto datilografado isso é necessário. Typescript otimiza tudo.
(mas pode ser necessário para os arquivos .d.ts )

@IanMitchell Não é usado para compilação esm, mas para normais

O bundle.js da versão 4.5.0 contém muitos códigos duplicados, como Severity, htmlElementAsString, htmlElementAsString, uuid4, parseUrl e assim por diante. Isso não pode ser pretendido!

O mesmo acontece quando eu faço um Bundle via import * as Sentry from '@sentry/browser'; (como a única linha do arquivo) usando WebPack + Babel 7, então o tamanho do bundle é 326kb. Consulte: sentry.bundle.js.txt
Também usamos a mesma configuração para nossos outros pacotes, mas o sentry é o único pacote com esse problema.

O bundle.min.js não tem código duplicado dentro de , o que pode ser resultado da trepidação da árvore com o rollup.

Então, uma solução temporária é usar import '@sentry/browser/build/bundle.min.js';

O bundle.js da versão 4.5.0 contém muitos códigos duplicados, como Severity, htmlElementAsString, htmlElementAsString, uuid4, parseUrl e assim por diante. Isso não pode ser pretendido!

É por isso (ou é pelo menos uma razão) que existe a construção esm . Se você tiver um bundler de qualquer maneira, é mais eficiente do que usar um bundle de pré-compilação. (É apenas beta e agora ainda está quebrado)

Olhando para isso novamente, e eu não acredito que isso não poderia ser menor. Muito pequeno.

Os rastreamentos de pilha com suporte ao mapa de origem devem ser de longe a coisa mais complexa nesta biblioteca - e não parece que é? Parece que a maior parte da pegada é da estrutura principal, que ele compartilha com o cliente node.js, onde tenho certeza que a pegada não é realmente uma preocupação.

Não me interpretem mal, esta é uma bela peça de arquitetura - muito bom trabalho TypeScript.

Mas do lado do cliente, isso não significa muito. Ele precisa ser pequeno e carregar rápido - especialmente para algo tão baixo quanto isso, não importa se o código-fonte é bonito ou não. Tanto quanto posso dizer, tudo o que é impressionante é que a arquitetura está custando muitos bytes no futuro.

Para comparação:

Me deparei com TrackJS , que possui recursos semelhantes (rastreamento de pilha entre navegadores com mapas de origem) em um pacote de ~ 10 KB.

O TraceKit original é ~3KB min+gz.

Eu encontrei esta biblioteca que pode fazer o bit do mapa de origem (no lado do cliente) em ~ 8 KB min + gz ou ~ 10 KB com polyfills x-browser.

Além disso, é uma questão de coletar alguns bits de informações do navegador, agrupar no formato JSON esperado e publicá-lo - o que não deve ser mais do que alguns KB min+gz. Deveria?

Eu sinto que isso é muito mais arquitetura do que a maioria das pessoas precisa. Se eu precisar de algum suporte de plug-in, talvez precise de um gancho simples que me permita inserir informações na postagem JSON, mas é isso.

Eu sei que é comum implantar megabytes de JS hoje em dia, mas temos políticas de conteúdo rígidas no trabalho, para garantir o envio de projetos que carregam rapidamente em dispositivos móveis, e não posso justificar gastar mais da metade do nosso orçamento de JS em erros. logging - talvez 10% no máximo, então algo como ~ 15-20 KB parece razoável.

Adoro seu produto, mas não consigo implantar esse cliente 😐

Para algo assim, pode ser uma boa ideia delegar o rastreamento de pilha e a análise do mapa de origem ao servidor, onde o tamanho é irrelevante

Para algo assim, pode ser uma boa ideia delegar o rastreamento de pilha e a análise do mapa de origem ao servidor, onde o tamanho é irrelevante

@cromefire ideia interessante. Gostaria de saber se é isso que, por exemplo, TrackJS faz para manter o tamanho baixo? (O cliente deles é proprietário - apenas a fonte minificada está disponível, então é difícil dizer o que eles fazem. Suponha que eu pudesse instalá-lo e ver o que viaja pelo fio ...)

Aqui está um pacote mais simples para resolver mapas de origem no navegador: source-map-resolve em ~ 2 KB min + gz ... navegadores modernos que não precisam de polyfills.

isso é sem polyfills

Polyfills não deveriam estar na compilação esm , então isso também poderia funcionar, mas no bachend seria ainda menos

A compilação do 4.5.1 agora. Ainda não documentado, pois queremos garantir que seja testado em batalha, mas até agora tudo bem. Eu verifiquei a compilação regular do webpack com o babel loader e funciona como um encanto.

Além disso, é uma questão de coletar alguns bits de informações do navegador, agrupar no formato JSON esperado e publicá-lo - o que não deve ser mais do que alguns KB min+gz. Deveria?

@mindplay-dk, não realizamos nenhuma resolução de rastreamento de pilha no lado do cliente. Tudo é feito no servidor, é por isso que você precisa fazer upload de mapas de origem em primeiro lugar para obter suporte para eles.

Mas o que fazemos é:

• processadores de eventos para fornecer ganchos personalizados que permitem modificar/filtrar/aprimorar dados enviados ao Sentry
• cuidar de todo o encapsulamento de API nativa
• capturar migalhas de todas as interações do usuário, chamadas de rede, navegações
• extrair dados do agente do usuário
• extraia dados de erro adicionais de erros vinculados, para que você possa criar vários níveis de erro, como em outros idiomas
• ouça os dois manipuladores de erros globais
• fornecer vários transportes de rede, para que o usuário sempre obtenha o melhor para seu ambiente atual
• cuidar de décimos de casos de borda e vários objetos de erro (mesmo personalizados) e várias implementações nativas
• fornecer substitutos para informações de erro sobressalentes ou quebradas
• eventos de buffer para que você não inunde sua própria instância do Sentry ou fique sem eventos gratuitos se algo der errado

Só para citar alguns. Eu realmente gostaria que fosse tão fácil quanto "capturar o erro, adicionar alguns dados e enviá-lo".
No mundo real, porém, existem dezenas de entradas, dezenas de fontes de erro podem vir (que fornecem dados diferentes) e dezenas de ambientes que variam em comportamento.
Definitivamente continuaremos trabalhando em como reduzir isso para ~10-15kB, mas levará algum tempo. Nós só temos tantos recursos (leia pessoas/tempo) que podemos gastar agora.

Eu sei que é comum implantar megabytes de JS hoje em dia, mas temos políticas de conteúdo rígidas no trabalho, para garantir o envio de projetos que carregam rapidamente em dispositivos móveis, e não posso justificar gastar mais da metade do nosso orçamento de JS em erros. logging - talvez 10% no máximo, então algo como ~ 15-20 KB parece razoável.

Você pode usar nosso carregador então – https://docs.sentry.io/platforms/javascript/loader/ :)

Você pode usar nosso carregador então – https://docs.sentry.io/platforms/javascript/loader/ :)

Mas infelizmente não há solução para o webpack

Só para citar alguns. Eu realmente gostaria que fosse tão fácil quanto "capturar o erro, adicionar alguns dados e enviá-lo".

Talvez alguém deva propor algo em tc39 . Eu teria que ver como é o processo, mas talvez alguém pudesse propor uma API padronizada para leitura de stacktrace

Mas infelizmente não há solução para o webpack

O que você quer dizer exatamente? Ter um pacote que pode coexistir com o carregador, que pode ser importado e agrupado, mas se comunicar com o SDK carregado de forma assíncrona quando ocorrer um erro ou uma chamada captureException?

O que você quer dizer exatamente? Ter um pacote que pode coexistir com o carregador, que pode ser importado e agrupado, mas se comunicar com o SDK carregado de forma assíncrona quando ocorrer um erro ou uma chamada captureException?

Sim, se eu recapitular corretamente, o carregador só está disponível através de um cdn

@cromefire sim, porque deve ser usado como um "snippet". No entanto, você pode encontrar o código aqui https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/loader.js

Parece que eu tenho que abrir um novo PR, porque com esm isso também seria utilizável a partir do seu próprio código

Temos uma solução que permitirá que você use loader junto com minimal e adicionará efetivamente apenas alguns kB ao seu pacote final.

Não deve ser difícil escrever um carregador que carregue isso em menos de 1kb, então por que não, vou tentar escrever um rápido

Uma coisa que pode ajudar muito aqui é se algumas das funcionalidades são opcionais.

Por exemplo, um mínimo realmente bom poderia ser:

• rastreamento de pilha de erro nativo (não se importe que não seja ideal em alguns navegadores)
• agente de usuário
• carimbo de data/hora
• URL
• corresponder com mapas de origem no servidor

Quaisquer funcionalidades adicionais podem ser apenas um complemento. Oferecemos suporte apenas a navegadores modernos, portanto, não precisamos contornar todo o comportamento peculiar dos navegadores antigos.

Resolvemos isso usando a divisão de código do webpack e carregamos o cliente sentry apenas em caso de erro.

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

Fazemos mais algumas coisas como preencher breadcrumbs, adicionar extras, adicionar tags, etc., mas é possível usar o sentry client e não aumentar o seu pacote.

Isso é um pouco o que eu implementei em # 1846

Pode ser útil para outras pessoas:
Eu usei a compilação ESM com webpack ( 4.29.5 ) por:

• adicionando um alias de webpack para usar a compilação ESM em vez da compilação padrão, pois não há declaração module em 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',
        ),
    }

• adicione uma exclusão para sentry/.+/esm à nossa configuração babel-loader , pois parece que a compilação do ESM inclui recursos mais recentes que o 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 aliases para não precisarmos nos preocupar com o empacotamento ao usá-lo no código (fazemos semelhante para lodash-es entre outras coisas)

@Limess

Você pode simplesmente redirecionar para @sentry/browser/esm :

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

Mas você não precisa adicionar um alias, basta importar @sentry/browser/esm

Para o loader é mais fácil escrevê-lo assim:

• Se você tiver outras coisas em babel:

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

• Se você não:

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

Lembre-se também de personalizar a configuração do babel para suas necessidades: babel docs , senão não vale a pena usar a versão esm

Atualização: em breve lançaremos uma nova versão principal do SDK, que reduz significativamente o tamanho do pacote.

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

Nossas versões de CDN pré-construídas mostram resultados ainda melhores (não tenho certeza de como o bundlephobia mede as coisas)

ES6:  14.3535 kB
ES5:  15.6846 kB

De qualquer forma, eu queria que você soubesse que ainda estamos trabalhando para reduzir ainda mais o tamanho do pacote, mas isso já deve ser um grande passo na direção certa.

Observação sobre a atualização: é um grande obstáculo, pois há muitas mudanças internas no SDK. Não deve haver nenhuma alteração de código necessária do seu lado. No momento, estamos testando a nova versão no sentry.io para ver como ela se comporta. ref: https://github.com/getsentry/sentry/pull/12492

Isenção de responsabilidade: Não use 5.0.0-rc.x na produção ainda como fazemos 🙈

@HazAT obrigado por levar isso a sério! este é um grande passo à frente - já estou muito menos preocupado em implantar isso agora :-)

@kamilogorek Só por curiosidade, você poderia adicionar à comparação a última versão do branch 3.x ?

Estou encerrando esta questão, a partir de agora, achamos que a redução que introduzimos passando da v4 para a v5 é uma tendência na direção certa. Ainda tentaremos reduzi-lo ainda mais e estaremos muito conscientes de aumentá-lo novamente.

Como uma observação rápida, nós realmente gostamos apenas de comparar o tamanho do nosso "pacote", pois dependendo de qual bundler você está usando, sua milhagem pode variar, então aqui está o número do pacote CDN que enviamos (ped):

| Pacote | Versão | Tamanho em Bytes | Tamanho em kB | Ligação |
|-----------------|---------|---------------|----- -------|------------------------------------------ ----------|
| corvo-js | 3.27.0 | 13741 Bytes | ~13,4kB | https://cdn.ravenjs.com/3.27.0/raven.min.js |
| @sentry/navegador | 4.6.6 | 22607 Bytes | ~22,1kB | https://browser.sentry-cdn.com/4.6.6/bundle.min.js |
| @sentry/navegador | 5.0.3 | 16059 Bytes | ~15,7kB | https://browser.sentry-cdn.com/5.0.3/bundle.min.js |

Com a v5, nós também enviamos e esm compilamos, o que significa que se você estiver usando um empacotador, ele deve ser capaz de fazer o treeshake de caminhos de código não utilizados.

Obrigado a todos pela paciência 🙇

@HazAT @kamilogorek incrível!

@Limess Ainda é relevante usar isso hoje: @sentry/browser/esm em vez de @sentry/browser ?

É importado como import * as Sentry from "@sentry/browser/esm"; e empacotado com webpack -p mas não vejo diferença nos tamanhos dos pacotes. Eu também tenho um webpack.config.js sem plugins ou carregadores.

@0xbkt Não faz diferença no tamanho do pacote, pelo menos agora ao usar o rollup para agrupar o aplicativo.