Is your feature request related to a problem? Please describe.
I'd like to automatically measure our packages' bundle size and report it onevery pull request, so we can catch size regressions and broken tree-shakingbefore they land.
Today we have no visibility into how a change affects bundle size, which is a first-order concern for browser libraries. Our packages also expose many independent subpath exports (@opentelemetry/browser-instrumentation has 7 ./experimental/* entries; @opentelemetry/browser-sdk has ., ./logs, ./traces, ./session), so it's easy to regress a size unnoticed or to break tree-shaking such that importing one feature pulls in the others. The roadmap (Distant Destinations → Bundle Size) also calls for measuring and publishing bundle size information, ideally automated in CI.
Describe the solution you'd like
Report bundle size on every pull request, covering these perspectives:
- Per-entry effective size — the gzip/brotli size a user actually pays when importing each public subpath export.
- Size diff vs. base branch — surface how a PR changes each entry's size, as a comment on the PR, so reviewers can catch regressions early.
- Tree-shaking effectiveness — verify that a partial import (
import { X }) stays small versus importing everything (*), enforcing our sideEffects: false guarantee.
- Dependency contribution — be able to inspect which dependencies dominate a bundle (e.g.
@opentelemetry/core, web-vitals, exporter-*-otlp-http) via size-limit --why locally.
Measure with size-limit (esbuild / preset-small-lib) — the de-facto standard (MobX, Material UI, Ant Design, PostCSS) — and report the results as a comment on each pull request using a first-party script, without adding a third-party GitHub Action. This keeps us consistent with our supply-chain policy (official actions only, SHA-pinned; zizmor/scorecard run in CI).
Describe alternatives you've considered
- Third-party PR-comment action (
andresz1/size-limit-action): less glue code, but adds a third-party Action we'd need to vet and SHA-pin.
- File-size watchers (
bundlewatch / bundlesize / preactjs/compressed-size-action): measure built dist files but don't model per-export tree-shaking, which matters for our many subpath exports.
- Enforce mode (fail CI on budget regression): preferred as a later follow-up; starting report-only avoids noisy failures before baselines settle.
Additional context
Out of scope for the initial work (possible follow-ups): enforce mode, time-based (parse/execute) budgets, and publishing a size dashboard / history over time.
I'd like to work on this myself. Happy to take feedback on the approach before I open a PR.
Is your feature request related to a problem? Please describe.
I'd like to automatically measure our packages' bundle size and report it onevery pull request, so we can catch size regressions and broken tree-shakingbefore they land.
Today we have no visibility into how a change affects bundle size, which is a first-order concern for browser libraries. Our packages also expose many independent subpath exports (
@opentelemetry/browser-instrumentationhas 7./experimental/*entries;@opentelemetry/browser-sdkhas.,./logs,./traces,./session), so it's easy to regress a size unnoticed or to break tree-shaking such that importing one feature pulls in the others. The roadmap (Distant Destinations → Bundle Size) also calls for measuring and publishing bundle size information, ideally automated in CI.Describe the solution you'd like
Report bundle size on every pull request, covering these perspectives:
import { X }) stays small versus importing everything (*), enforcing oursideEffects: falseguarantee.@opentelemetry/core,web-vitals,exporter-*-otlp-http) viasize-limit --whylocally.Measure with
size-limit(esbuild/preset-small-lib) — the de-facto standard (MobX, Material UI, Ant Design, PostCSS) — and report the results as a comment on each pull request using a first-party script, without adding a third-party GitHub Action. This keeps us consistent with our supply-chain policy (official actions only, SHA-pinned; zizmor/scorecard run in CI).Describe alternatives you've considered
andresz1/size-limit-action): less glue code, but adds a third-party Action we'd need to vet and SHA-pin.bundlewatch/bundlesize/preactjs/compressed-size-action): measure builtdistfiles but don't model per-export tree-shaking, which matters for our many subpath exports.Additional context
Out of scope for the initial work (possible follow-ups): enforce mode, time-based (parse/execute) budgets, and publishing a size dashboard / history over time.
I'd like to work on this myself. Happy to take feedback on the approach before I open a PR.