Sentry-javascript: @sentry/브라우저 크기

이 문제를 제기해 주셔서 감사합니다.
번들 크기에 대한 귀하의 우려를 이해하고 일반적으로 동의하지만 압축되지 않은 축소 파일 크기 대신 gzip 번들 크기를 먼저 비교하는 것이 공정하다고 생각합니다.

@sentry/browser 는 21.3799KB입니다.
raven-js 13.44KB

또한 이것이 모든 사람에게 적용되는 것은 아니지만 일반적으로 웹사이트에서 SDK를 설정할 CDN 로더를 사용하도록 사람들을 제공하고 안내합니다.

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

동일한 기능을 유지하면서 <1KB gzip으로 압축된 이 스크립트의 페이지 로드 시간과 공간에 미치는 영향.

그래서 tl; dr:
우리는 그것을 알고 있으며 개선의 여지가 있다는 것을 알고 있지만 지금 당장은 최우선 순위가 아닙니다.

압축되지 않은 축소 파일 크기 대신 gzip 번들 크기를 먼저 비교하는 것이 공정하다고 생각합니다.

성능 문제는 자바스크립트 다운로드뿐만 아니라 구문 분석 및 실행에서도 발생하므로 축소된 크기를 비교하는 것도 공정하다고 주장합니다. ~92kb는 상당히 무겁고 저사양 장치에서 최대 1초의 구문 분석 시간을 추가할 수 있습니다(이 하나의 라이브러리에만 해당).

CDN된 스크립트의 < 1KB 번호를 어디서 가져왔는지 잘 모르겠습니다. 자세히 설명해 주시겠습니까? https://browser.sentry-cdn.com/4.0.4/bundle.min.js 를 열면 22KB의 gzip 크기가 표시됩니다.

Sentry의 SDK는 개발자가 포함하는 많은 라이브러리 중 하나일 뿐입니다.

추신: 저는 센트리를 사랑합니다. 저희에게 큰 도움이 되었습니다. 웹 성능은 내가 열정을 갖고 있는 것입니다. ;)

@klaemo
헤헤 걱정마세요 😂

내가 말했듯이, 우리는 그것을 알고 있고 그것이 더 작아지는 것을 원하지 않는 것이 아닙니다.
우리에게 가장 중요한 것은 새로운 SDK를 출시하는 것이었습니다. 우리는 시간이 지남에 따라 번들 크기를 개선하기 위해 노력할 것입니다.
더 많은 단계를 수행할 수 있습니다. 예: tslib 사용 , 문자열 결합 ...
따라서 개선할 여지가 많습니다.

죄송합니다. 전에 게시 한 링크는 이미 구식입니다 🙃
나는 _Loader_를 참조하고 있었습니다: https://docs.sentry.io/platforms/javascript/loader/
_Loader_도 비동기 특성으로 인해 한계가 있고 결국에는 여전히 SDK를 가져오고 주입합니다(비동기일지라도). 사람들이 요청했기 때문에 우리가 제공하는 대안입니다.

@HazAT 죄송하지만 다음 버전 출시일을 알려주실 수 있나요?
내 말은, #master 브랜치에 이미 몇 가지 변경 사항이 있지만 아직 릴리스되지 않았습니다. 하지만 Angular5+ 프로젝트에는 4x 버전을 사용할 수 있다고 결정했습니다.

@rayzru 방금 4.0.5 를 출시했지만 해당 주제와 관련된 게시물을 계속 남겨주세요.

제 생각에는 이것은 확실히 퇴보이며 새 버전으로 업데이트하지 않는 심각한 이유입니다.

💯 나는 다음과 같은 사실을 알아차릴 때까지 업그레이드하려던 참이었습니다.

• 이전: https://bundlephobia.com/[email protected]
• 이후: https://bundlephobia.com/result?p=@sentry/browser @4.0.1

적어도 패키지 크기는 더 작지만 번들에 ⚠️ +10KB 의 gzipped JavaScript가 중요하다고 생각합니다. 우리는 기다릴 것입니다, 좋은 일을 계속하십시오 :)

@HazAT esm 파일을 생성할 수 있습니까? 웹팩이 연결 및 트리 흔들림으로 더 나은 결과를 얻을 수 있습니다.

각 병합 요청에 대한 패키지의 번들 크기를 추적하기 위해 일부 CI 도구를 추가할 수 있습니다. 이 문제 이후 실제로 100kB로 증가했습니다. https://bundlephobia.com/result?p=@sentry/browser @4.3.0을 참조하세요.

예를 들어 https://github.com/siddharthkp/bundlesize 시도

Webpack의 진입점에 대한 기본 성능 예산은 모든 장치와 네트워크에서 적절한 성능을 얻을 수 있도록 250kb입니다. 100kb의 Sentry는 상당한 예산을 차지합니다.

이 회귀를 수정하는 것이 로드맵에 전혀 포함되어 있지 않거나 라이브러리가 규모 예산 없이 계속 성장할 경우 계속 업데이트해 주십시오.

우리는 고객에게 비용을 지불하고 백엔드, 네이티브 및 웹 모두에서 Sentry에 막대한 투자를 하고 있지만 라이브러리 크기의 3배 이상([email protected]은 31kB)으로 업그레이드하는 것은 정당화할 수 있는 것이 아닙니다.

@jacobrask 이전 버전의 라이브러리를 사용할 수 있습니다. https://www.onepixel.com/ 에서 하는 대로 잘 작동합니다. 👌.

@jacobrask 그것은 확실히 우리 목록에 있고 우리는 또한 번들 크기를 쉽게 줄일 수 있는 낮은 매달린 과일이 있다고 생각합니다.
점점 더 많은 사람들이 이것을 요구하므로 예상보다 빨리 이 문제를 해결할 것입니다.

@HAZAT
Sentry 브라우저 SDK 롤업 번들은 최적화할 수 있습니다. 번들 min js 파일에는 반복되는 tslib 코드가 많이 있습니다. 예를 들어 __generator, __assign. 브라우저 환경에서는 하나의 코드를 공유하는 것이 가장 좋습니다. 그러나 브라우저 프로젝트는 다른 패키지 dist 파일을 사용합니다. gzip 크기를 23K에서 16K로 줄일 수 있습니다.

번들 크기는 4.3.2에서 동일합니다.
https://bundlephobia.com/result?p=@sentry/browser @4.3.2 변경 사항에 관계없이
https://github.com/getsentry/sentry-javascript/pull/1738 :(

@vkrol 적어도 npm 패키지에 대해 @gaterking 이 만든 변경 사항을 되돌려야 했습니다.
반면 CDN의 번들은 더 작아야 합니다.

변경 사항을 다시 추가할 것이지만 예를 들어 tslib 에 대한 담당자가 필요하므로 이에 대해 이야기해야 합니다.
또한 타이핑이 생성되는 방식이 깨졌습니다.

@HazAT 네 , 감사합니다.

@vkrol 적어도 npm 패키지에 대해 @gaterking 이 만든 변경 사항을 되돌려야 했습니다.
반면 CDN의 번들은 더 작아야 합니다.

변경 사항을 다시 추가할 것이지만 예를 들어 tslib 에 대한 담당자가 필요하므로 이에 대해 이야기해야 합니다.
또한 타이핑이 생성되는 방식이 깨졌습니다.

가능한 한 빨리 바랍니다.

@gaterking @kamilogorek 이미 수정했습니다 https://github.com/getsentry/sentry-javascript/pull/1751
"긴급" 릴리스를 수행해야 했기 때문에 되돌린 것입니다.

클라이언트 측에서는 기본적으로 이것이 오류를 캡처하고 API에 제출하기를 원합니다.

이렇게 복잡한 라이브러리는 또 무엇을 하고 있습니까?

단순한 오류 보고자가 왜 그렇게 상당한 공간을 차지해야 하는지 이해하기가 정말 어렵습니다 😐

@mindplay-dk 대부분 자바스크립트와 브라우저가 엉망이라서 ^^
깨진/잘못된 스택 추적을 수정하는 데 많은 작업이 필요합니다.
"오류 잡기"라는 간단한 작업도 보이는 것보다 훨씬 더 복잡합니다.

단순한 오류 보고자가 왜 그렇게 상당한 공간을 차지해야 하는지 이해하기가 정말 어렵습니다 😐

@mindplay-dk 간단하지 않기 때문에.

다음은 모든 브라우저에서 오류를 캡처하고 사용 가능한 데이터 구조로 통합하는 코드입니다. https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/tracekit.ts

최근 사이즈 축소 잘 해주셔서 감사합니다. 👍

링크된 파일을 한 눈에 보면 Opera 10의 오류를 처리하는 코드가 표시됩니다. 정말 여전히 필요한가요? TraceKit은 또한 이미 큰 Raven에서 (현재) 2배 크기 증가를 설명하지 않습니다.

몇 가지 제안:

• md5 제거
• async/await 사용을 줄이면 ES5로 제대로 컴파일되지 않습니다. https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/baseclient.ts#L307 -L378을 출력 코드와 비교하십시오(프로덕션 번들에서 "processEvent" 검색). 전체 파일은 프로덕션 번들에서 거대해집니다.

package/core와 같은 다른 패키지에 일부 공유 코드(rewriteframes.ts의 app:///${base} )가 있습니까? 클라이언트에서는 사용하지 않고 노드에서는 사용합니다.

간단하지 않기 때문입니다.

@kamilogorek yikes, 당신이 분명히 옳았습니다 ... JavaScript가 엉망이라는 것을 깨달았습니다. 전에이 분야를 파고 들어 본 적이없는 것 같습니다. 이것이 얼마나 나쁜지 몰랐습니다. JS에서 스택 추적을 처리하는 간단한 방법은 없다고 생각합니다. 단지. 그렇군요. 😐

도우미를 최소화하려고 하는 대신 이미 언급한 esm 파일을 제공할 수 있습니다. 이는 오늘날에도 쉽고 모범 사례입니다.

async/await 사용을 줄이면 ES5로 제대로 컴파일되지 않습니다. https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/baseclient.ts#L307 -L378을 출력 코드와 비교하십시오(프로덕션 번들에서 "processEvent" 검색). 전체 파일은 프로덕션 번들에서 거대해집니다.

그것은 잘못된 방법입니다. ES5에 대해 추가로 최적화하는 대신 최신 브라우저를 사용하는 80.07% 에 맞게 최적화하는 것이 더 중요합니다.

이전 브라우저 지원이 필요한 모든 사람을 위해:
비동기 기능은 <script type="module"> (caniuse: esm , async )를 지원하는 모든 브라우저에서 지원되므로 이전 브라우저의 사용자만 더 오래 기다려야 합니다(어쨌든 더 오래 걸립니다).

증거:
160KB(es5, 번들) > 119KB(esm, 일반 파일)

따라서 esm 파일도 번들로 묶으십시오 module 및 target in /tsconfig.esm.json ( tsconfig.build.json 확장)를 esnext 로 변경하는 것만큼 쉽습니다. tsconfig.esm.json tsconfig.build.json 파일을 패키지에 추가하고 빌드 및 패키지에 추가 하고 package.json 에 모듈 항목을 지정합니다.

원하신다면 PR을 추가할 수 있습니다.

원하신다면 PR을 추가할 수 있습니다.

@cromefire 를 원합니다 :)

vue cli와 같이 클래식 모드와 모던 모드 중에서 선택할 수 있는 옵션이 있다면 굉장할 것입니다. 최신 버전은 대부분의 최신 브라우저만 지원하므로 덜 부풀려질 수 있습니다.

또는 webpack env처럼 작동하여 사용자가 필요한 브라우저 지원을 지정할 수 있다면 더 좋습니다. Ofc, 이것은 쉬운 쉬운 기능이 아니지만 그냥 버리고 싶었습니다. :)

멋진 제품!

새로운 PR을 사용하여 babel을 구성할 수 있지만 필요한 브라우저만 지원하고 싶습니다.

@sentry/browser의 크기는 raven-js 크기의 두 배 이상입니다( 86kB 대 39kB(축소)).

참고: 최신 버전의 @sentry/browser 크기가 91.8kB 로 증가했습니다. 출처: https://bundlephobia.com/result?p=@sentry/browser @4.5.0.

@cromefire 라이브러리 크기 최적화 작업에 감사드립니다!

방금 v4.5.0 에서 새 esm 빌드를 사용하려고 시도했지만 많은 오류가 발생했습니다. @sentry/utils/esm 의 모듈을 확인할 수 없기 때문에 모두 트리거됩니다.

사실 나는 새로운 yarn install 이후 node_modules 에서 폴더를 찾지 못했습니다. (스크린샷 참조)

 ./node_modules/@sentry/core/esm/baseclient.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'에서 '@sentry/utils/esm/async'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/backend.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm'에서 '@sentry/utils/esm/is'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/tracekit.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm'에서 '@sentry/utils/esm/is'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'에서 '@sentry/utils/esm/is'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/helpers.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'에서 '@sentry/utils/esm/is'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/pluggable/vue.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations/pluggable'에서 '@sentry/utils/esm/is'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/baseclient.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'에서 '@sentry/utils/esm/is'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/dsn.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'에서 '@sentry/utils/esm/is'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/integrations/inboundfilters.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm/integrations'에서 '@sentry/utils/esm/is'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/integrations/extraerrordata.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm/integrations'에서 '@sentry/utils/esm/is'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/globalhandlers.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'의 '@sentry/utils/esm/logger'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'의 '@sentry/utils/esm/logger'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/baseclient.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'에서 '@sentry/utils/esm/logger'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/basebackend.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'에서 '@sentry/utils/esm/logger'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/sdk.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'에서 '@sentry/utils/esm/logger'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/integration.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'에서 '@sentry/utils/esm/logger'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/integrations/dedupe.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm/integrations'의 '@sentry/utils/esm/logger'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/integrations/sdkinformation.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm/integrations'의 '@sentry/utils/esm/logger'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/integrations/inboundfilters.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm/integrations'의 '@sentry/utils/esm/logger'를 확인할 수 없습니다.

 ./node_modules/@sentry/hub/esm/hub.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/hub/esm'의 '@sentry/utils/esm/logger'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/client.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm'에서 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/tracekit.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm'에서 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/useragent.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'의 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'의 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/trycatch.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'의 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/helpers.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'의 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/pluggable/reportingobserver.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations/pluggable'에서 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/pluggable/vue.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations/pluggable'에서 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/pluggable/ember.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations/pluggable'에서 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/transports/beacon.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/transports'의 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/transports/fetch.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/transports'의 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/baseclient.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'에서 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/integrations/dedupe.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm/integrations'의 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/integrations/inboundfilters.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm/integrations'의 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/hub/esm/scope.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/hub/esm'의 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/hub/esm/hub.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/hub/esm'의 '@sentry/utils/esm/misc'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/parsers.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm'에서 '@sentry/utils/esm/object'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'의 '@sentry/utils/esm/object'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/trycatch.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'의 '@sentry/utils/esm/object'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/helpers.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'의 '@sentry/utils/esm/object'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/api.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'에서 '@sentry/utils/esm/object'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/basebackend.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'에서 '@sentry/utils/esm/object'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/dsn.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'에서 '@sentry/utils/esm/object'를 확인할 수 없습니다.

 ./node_modules/@sentry/hub/esm/scope.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/hub/esm'에서 '@sentry/utils/esm/object'를 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/integrations/pluggable/rewriteframes.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm/integrations/pluggable'에서 '@sentry/utils/esm/path'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/parsers.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm'에서 '@sentry/utils/esm/string'을 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'의 '@sentry/utils/esm/string'을 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/baseclient.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm'의 '@sentry/utils/esm/string'을 확인할 수 없습니다.

 ./node_modules/@sentry/core/esm/integrations/inboundfilters.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/core/esm/integrations'의 '@sentry/utils/esm/string'을 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/backend.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm'에서 '@sentry/utils/esm/supports'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/breadcrumbs.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations'에서 '@sentry/utils/esm/supports'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/integrations/pluggable/reportingobserver.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/integrations/pluggable'에서 '@sentry/utils/esm/supports'를 확인할 수 없습니다.

 ./node_modules/@sentry/browser/esm/transports/fetch.js의 오류

 모듈을 찾을 수 없음: 오류: './node_modules/@sentry/browser/esm/transports'에서 '@sentry/utils/esm/supports'를 확인할 수 없습니다.

@pascaliske esm 빌드는 아직 실험 단계에 있으며 아직 공개적으로 문서화하지 않았습니다. 우리는 모든 것이 테스트되면 그것을 할 것이고 우리의 발견을 여기에 게시할 것입니다.

@kamilogorek 네, 알겠습니다. 이러한 오류를 알려드리고자 합니다. 🙂

감사합니다, 감사합니다 @pascaliske! 빠른 시일 내에 ESM 지원을 제공하도록 노력하겠습니다. :)

@pascaliske yarn build 먼저 시도

@cromefire 아니요, 제 생각에는 도움이 되지 않을 것입니다. 방금 npm에서 패키지를 다운로드하여 사용 가능한 빌드 환경이 없습니다. 🙂

소스 코드를 조금 검색하여 @sentry/browser 와 @sentry/utils 를 비교했습니다. 나는 이것이 문제라고 생각합니다: packages/utils/tsconfig.build.json#L5 vs. packages/browser/tsconfig.build.json#L5 . 일반 빌드 출력이 esm 빌드 출력을 덮어쓸 수 있습니까? 🤔

내 node_modules 폴더 안에 browser 패키지에는 normal 및 esm의 빌드 출력이 포함되어 있습니다. 그러나 utils 패키지는 루트 폴더에 일반 빌드 출력만 포함합니다.

이미 출시되었나요?

소스 코드를 조금 검색하고 @sentry/browser 와 @sentry/utils 를 비교했습니다. 나는 이것이 문제라고 생각합니다: packages/utils/tsconfig.build.json#L5 vs. packages/browser/tsconfig.build.json#L5 . 일반 빌드 출력이 esm 빌드 출력을 덮어쓸 수 있습니까? 🤔

아니요, esm tsconfig를 봐야 합니다.

내일 봐야겠다

모두 안녕! 또한 Sentry의 번들 크기 중 일부를 살펴보고 다음을 발견했습니다. https://github.com/getsentry/sentry-javascript/blob/master/packages/minimal/package.json#L20

매우 소수의 기능(확산 및 할당)에 대해 크기 덩어리를 추가하는 것 같습니다. 나는 Typescript에 익숙하지 않지만 런타임에 이것이 필요합니까?

@sentry/types 가 devDependencies 에 위치하지 않고 _runtime_ 종속성이어야 하는 이유도 불분명합니다.

typescript의 모든 사용자를 위한 @evocateur 이것이 필요합니다. Typescript는 모든 것을 최적화합니다.
(그러나 .d.ts 파일에 필요할 수 있음)

@IanMitchell esm 빌드에는 사용되지 않지만 일반 빌드에는 사용됩니다.

4.5.0의 bundle.js에는 Severity, htmlElementAsString, htmlElementAsString, uuid4, parseUrl 등과 같은 중복 코드가 많이 포함되어 있습니다. 이것은 의도할 수 없습니다!

WebPack + Babel 7을 사용하여 import * as Sentry from '@sentry/browser'; (파일의 유일한 줄)을 통해 번들을 수행할 때도 동일한 일이 발생하며 번들 크기는 326kb입니다. 참조: sentry.bundle.js.txt
우리는 다른 번들에도 동일한 구성을 사용하지만 sentry는 해당 문제가 있는 유일한 번들입니다.

bundle.min.js 에는 내부에 중복 코드가 없습니다 . 이는 롤업으로 인한 트리 흔들림의 결과일 수 있습니다.

따라서 임시 해결책은 import '@sentry/browser/build/bundle.min.js'; 를 사용하는 것입니다.

4.5.0의 bundle.js에는 Severity, htmlElementAsString, htmlElementAsString, uuid4, parseUrl 등과 같은 중복 코드가 많이 포함되어 있습니다. 이것은 의도할 수 없습니다!

이것이 esm 빌드가 있는 이유(또는 적어도 하나의 이유)입니다. 어쨌든 번들러가 있다면 사전 빌드 번들을 사용하는 것보다 더 효율적입니다. (베타일 뿐이고 지금은 여전히 ​​깨졌습니다)

이것을 다시 보면, 이것이 이보다 작을 수 없다고 생각합니다. 더 작은.

소스 맵을 지원하는 스택 추적은 이 라이브러리에서 단연코 가장 복잡한 것이어야 합니다. 대부분의 발자국은 node.js 클라이언트와 공유하는 핵심 프레임워크에서 온 것 같습니다. 여기서 발자국은 실제로 문제가 되지 않는다고 확신합니다.

오해하지 마세요. 이것은 아키텍처의 아름다운 부분입니다. 아주 멋진 TypeScript 작업입니다.

그러나 클라이언트 측에서는 큰 의미가 없습니다. 작고 빠르게 로드되어야 합니다. 특히 이와 같은 저수준의 경우 소스 코드가 아름다운지 아닌지는 그다지 중요하지 않습니다. 내가 말할 수 있는 한 인상적인 것은 아키텍처가 많은 바이트를 필요로 한다는 것입니다.

비교하려고:

~10KB 패키지에 유사한 기능(소스 맵이 있는 브라우저 간 스택 추적)이 있는 TrackJS 를 발견했습니다.

원래 TraceKit 은 ~3KB min+gz입니다.

x-browser 폴리필을 사용하여 ~8KB min+gz 또는 ~10KB에서 소스 맵 비트(클라이언트 측)를 수행할 수 있는 이 라이브러리 를 찾았습니다.

그 외에도 몇 비트의 브라우저 정보를 수집하고 예상 JSON 형식으로 래핑하고 게시하는 문제입니다. 이 작업은 몇 KB min+gz를 넘지 않아야 합니다. 그래야 할까요?

나는 이것이 대부분의 사람들에게 필요한 것보다 훨씬 더 많은 아키텍처라고 생각합니다. 플러그인 지원이 필요한 경우 JSON 게시물에 정보를 연결할 수 있는 간단한 후크가 필요할 수 있지만 그게 전부입니다.

요즘에는 메가바이트의 JS를 배포하는 것이 일반적이라는 것을 알고 있지만 모바일에서 빠르게 로드되는 프로젝트를 제공하기 위해 엄격한 콘텐츠 정책이 작동하고 있으며 오류에 JS 예산의 절반 이상을 지출하는 것을 정당화할 수 없습니다. 로깅 - 아마도 10%가 최고이므로 ~15-20KB와 같은 것이 합리적으로 보입니다.

나는 당신의 제품을 사랑하지만 이 클라이언트를 배포할 수 없습니다 😐

이와 같은 경우 스택 추적 및 소스 맵 구문 분석을 서버에 위임하는 것이 좋습니다. 여기서 크기는 관련이 없습니다.

이와 같은 경우 스택 추적 및 소스 맵 구문 분석을 서버에 위임하는 것이 좋습니다. 여기서 크기는 관련이 없습니다.

@cromefire 흥미로운 아이디어입니다. 그것이 TrackJS가 크기를 작게 유지하기 위해 하는 일인지 궁금합니다. (그들의 클라이언트는 독점적입니다 - 축소된 소스만 사용할 수 있으므로 그들이 무엇을 하는지 말하기 어렵습니다. 내가 그것을 설치하고 유선을 통해 이동하는 것을 볼 수 있다고 가정해 봅시다...)

다음은 브라우저에서 소스 맵을 해결하는 더 간단한 패키지입니다. source-map-resolve at ~2KB min+gz ... 폴리필이 없지만 (이것이 작동하는 경우) ~10KB에 도달할 수 있어야 한다고 생각합니다. 폴리필이 필요하지 않은 최신 브라우저.

그건 폴리필 없이

Polyfills는 esm 빌드에 없어야 하므로 작동할 수도 있지만 bachend에서는 훨씬 적습니다.

@cromefire ESM 빌드는 지금 4.5.1 에서 사용할 수 있습니다. 전투 테스트를 거쳤는지 확인하기 위해 아직 문서화되지 않았지만 지금까지는 매우 좋습니다. 나는 babel loader로 일반 webpack 빌드를 확인했고 그것은 매력처럼 작동합니다.

그 외에도 몇 비트의 브라우저 정보를 수집하고 예상 JSON 형식으로 래핑하고 게시하는 문제입니다. 이 작업은 몇 KB min+gz를 넘지 않아야 합니다. 그래야 할까요?

@mindplay-dk 우리는 클라이언트 측에서 스택 추적 분석을 수행하지 않습니다. 모든 것이 서버에서 이루어지므로 지원을 받으려면 먼저 소스 맵을 업로드해야 합니다.

하지만 우리가 하는 일은:

• Sentry로 전송된 데이터를 수정/필터링/향상할 수 있는 사용자 정의 후크를 제공하는 이벤트 프로세서
• 모든 네이티브 API 래핑 처리
• 모든 사용자 상호 작용, 네트워크 호출, 탐색에서 이동 경로 캡처
• 사용자 에이전트 데이터 추출
• 연결된 오류에서 추가 오류 데이터를 추출하여 다른 언어에서와 같이 다중 오류 수준을 만들 수 있습니다.
• 두 전역 오류 처리기 모두 수신
• 다중 네트워크 전송을 제공하여 사용자가 항상 현재 환경에 가장 적합한 전송을 얻을 수 있도록 합니다.
• 에지 케이스의 10분의 1과 다양한 오류(맞춤형 오류도 포함) 개체 및 다양한 기본 구현을 처리합니다.
• 예비 또는 손상된 오류 정보에 대한 대체 제공
• 이벤트를 버퍼링하여 자신의 Sentry 인스턴스가 범람하거나 문제가 발생하는 경우 무료 이벤트가 부족하지 않도록 합니다.

몇가지 말하자면. "오류 포착, 데이터 추가 및 전송"만큼 쉬웠으면 좋겠습니다.
하지만 실제 세계에는 수십 개의 입력, 수십 개의 소스 오류가 발생할 수 있으며(모두 다른 데이터를 제공함) 동작이 다양한 수십 개의 환경이 있습니다.
우리는 이것을 ~10-15kB로 낮추는 방법에 대해 계속 노력할 것이지만 시간이 좀 걸릴 것입니다. 우리는 지금 쓸 수 있는 리소스(사람/시간 읽기)가 너무 많습니다.

요즘에는 메가바이트의 JS를 배포하는 것이 일반적이라는 것을 알고 있지만 모바일에서 빠르게 로드되는 프로젝트를 제공하기 위해 엄격한 콘텐츠 정책이 작동하고 있으며 오류에 JS 예산의 절반 이상을 지출하는 것을 정당화할 수 없습니다. 로깅 - 아마도 10%가 최고이므로 ~15-20KB와 같은 것이 합리적으로 보입니다.

그런 다음 로더를 사용할 수 있습니다 – https://docs.sentry.io/platforms/javascript/loader/ :)

그런 다음 로더를 사용할 수 있습니다 – https://docs.sentry.io/platforms/javascript/loader/ :)

그러나 슬프게도 webpack에 대한 솔루션은 없습니다

몇가지 말하자면. "오류 포착, 데이터 추가 및 전송"만큼 쉬웠으면 합니다.

누군가 tc39 에서 무언가를 제안해야 할 수도 있습니다. 프로세스가 어떤지 살펴봐야 하겠지만 누군가가 스택 추적 읽기와 같은 표준화된 API를 제안할 수 있습니다.

그러나 슬프게도 webpack에 대한 솔루션은 없습니다

정확하게 무슨 뜻입니까? 가져오기 및 번들로 사용할 수 있는 로더와 공존할 수 있지만 오류 또는 captureException 호출이 발생하면 비동기적으로 로드된 SDK와 통신할 수 있는 패키지가 있습니까?

정확하게 무슨 뜻입니까? 가져오기 및 번들로 사용할 수 있는 로더와 공존할 수 있지만 오류 또는 captureException 호출이 발생하면 비동기적으로 로드된 SDK와 통신할 수 있는 패키지가 있습니까?

예, 올바르게 요약하면 로더는 cdn을 통해서만 사용할 수 있습니다.

@cromefire 예, "스니펫"으로 사용하기 위한 것이기 때문입니다. 그러나 https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/loader.js 에서 코드를 찾을 수 있습니다.

esm 를 사용하면 자신의 코드에서도 사용할 수 있기 때문에 새 PR을 열어야 하는 것 같습니다.

minimal loader 를 사용할 수 있고 최종 번들에 몇 kB만 효과적으로 추가할 수 있는 솔루션이 제공됩니다.

1kb 미만으로 로드하는 로더를 작성하는 것은 어렵지 않을 것이므로 빠른 것을 작성해 보겠습니다.

여기서 많은 도움이 될 수 있는 한 가지는 기능 중 일부가 선택 사항인 경우입니다.

예를 들어 정말 좋은 최소한의 값은 다음과 같습니다.

• 기본 오류 스택 추적(일부 브라우저에서는 최적이 아니어도 상관 없음)
• 사용자 에이전트
• 타임스탬프
• URL
• 서버의 소스 맵과 일치

추가 기능은 추가 기능일 수 있습니다. 우리는 최신 브라우저만 지원하므로 이전 브라우저의 모든 기발한 동작을 해결할 필요가 없습니다.

webpack 코드 분할을 사용하고 오류 발생 시에만 센트리 클라이언트를 로드하여 이 문제를 해결했습니다.

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

빵 부스러기 채우기, 추가 추가, 태그 추가 등과 같은 작업을 더 수행하지만 센트리 클라이언트를 사용하고 번들을 더 크게 만들지 않을 수 있습니다.

이것은 내가 #1846에서 구현한 것입니다.

다른 사람들에게 도움이 될 수 있습니다:
다음과 같이 webpack( 4.29.5 )과 함께 ESM 빌드를 사용했습니다.

• package.json module 선언이 없기 때문에 표준 빌드 대신 ESM 빌드를 사용하도록 웹팩 별칭 추가

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

• ESM 빌드에 ES2015보다 최신 기능이 포함되어 있는 것처럼 보이므로 babel-loader 구성에 sentry/.+/esm 에 대한 제외를 추가합니다.

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

노트:

• 코드에서 사용할 때 번들링에 대해 걱정할 필요가 없도록 별칭을 사용했습니다(무엇보다도 lodash-es 에 대해 유사한 작업을 수행함)

@라임스

@sentry/browser/esm 로 리디렉션할 수 있습니다.

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

하지만 별칭을 추가할 필요는 없습니다 @sentry/browser/esm 가져오기만 하면 됩니다.

로더의 경우 다음과 같이 작성하는 것이 더 쉽습니다.

• babel에 다른 것이 있다면:

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

• 그렇지 않은 경우:

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

또한 필요에 따라 babel 구성을 사용자 지정하는 것을 잊지 마십시오: babel docs , 그렇지 않으면 esm 버전을 사용할 가치가 없습니다.

업데이트: 번들 크기를 크게 줄이는 새로운 주요 SDK 버전을 곧 출시할 예정입니다.

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

사전 구축된 CDN 버전은 더 나은 결과를 보여줍니다(번들 공포증이 어떻게 물건을 측정하는지 확실하지 않음)

ES6:  14.3535 kB
ES5:  15.6846 kB

어쨌든, 나는 그것이 여전히 번들 크기를 더 줄이기 위해 노력하고 있음을 알리고 싶었지만 이것은 이미 올바른 방향으로의 큰 진전일 것입니다.

업그레이드에 대한 참고 사항: SDK에 많은 내부 변경 사항이 있으므로 큰 문제입니다. 사용자 측에서 필요한 코드 변경이 없어야 합니다. 우리는 현재 sentry.io에서 새 버전이 어떻게 작동하는지 직접 테스트하고 있습니다. 참조: https://github.com/getsentry/sentry/pull/12492

면책 조항: 아직 프로덕션에서 5.0.0-rc.x 를 사용하지 마십시오. 🙈

@HazAT 진지하게 받아주셔서 감사합니다! 이것은 큰 진전입니다 - 저는 이미 이것을 지금 배포하는 것에 대해 훨씬 덜 걱정하고 있습니다 :-)

@kamilogorek 그냥 궁금해서 비교에 3.x 분기의 마지막 버전을 추가할 수 있습니까?

저는 이 문제를 닫고 있습니다. 현재로서는 v4에서 v5로 이동하는 축소가 올바른 방향으로 가는 추세라고 생각합니다. 우리는 여전히 그것을 더 줄이기 위해 노력할 것이며 우리는 그것을 다시 증가시키는 것에 대해 매우 의식할 것입니다.

간단히 말해서 "번들" 크기만 비교하는 것을 좋아합니다. 사용 중인 번들러에 따라 마일리지가 다를 수 있으므로 다음은 배송하는 CDN 번들 번호입니다.

| 패키지 | 버전 | 크기(바이트) | 크기(KB) | 링크 |
|-----|---------|---------------|----- -------|------------------------------------------ ----------|
| 까마귀-js | 3.27.0 | 13741바이트 | ~13.4kb | https://cdn.ravenjs.com/3.27.0/raven.min.js |
| @sentry/브라우저 | 4.6.6 | 22607바이트 | ~22.1kb | https://browser.sentry-cdn.com/4.6.6/bundle.min.js |
| @sentry/브라우저 | 5.0.3 | 16059바이트 | ~15.7kb | https://browser.sentry-cdn.com/5.0.3/bundle.min.js |

v5에서는 esm 빌드도 제공합니다. 즉, 번들러를 사용하는 경우 사용하지 않는 코드 경로를 트리셰이크할 수 있어야 합니다.

기다려주신 모든 분들께 감사드립니다 🙇

@HazAT @kamilogorek 굉장합니다!

@Limess @sentry/browser @sentry/browser/esm 를 사용하는 것이 오늘날에도 여전히 관련이 있습니까?

import * as Sentry from "@sentry/browser/esm"; 와 같이 가져오고 webpack -p $와 함께 번들로 제공되지만 번들 크기에는 차이가 없습니다. 플러그인이나 로더가 없는 webpack.config.js 도 있습니다.

@0xbkt 적어도 지금은 롤업 을 사용하여 앱을 묶을 때 번들 크기에 차이가 없습니다.