SDK Bundle Size Regression Guard

[Kingsman-99]

Description

As the SDK grows, accidental imports of heavy polyfills or unused Stellar SDK sub-modules can silently inflate the distributed bundle, harming browser-based dApp consumers who pay the cost at page load time. There is currently no CI enforcement of bundle size, meaning regressions are only discovered after reaching consumers. A size regression guard would measure the minified and gzipped ESM bundle on every pull request and fail the build if the size exceeds a threshold or grows by more than an allowed percentage relative to the main-branch baseline.

Technical Context

New script scripts/bundle-size-guard.ts executed via tsx. Uses esbuild (already a dev dependency) to produce a one-shot ESM bundle from src/index.ts, then zlib.gzip to measure compressed size. Baseline recorded in scripts/bundle-size-baseline.json. A new bundle:check npm script added to package.json. A companion bundle:update-baseline script regenerates the baseline file. Thresholds defined in scripts/bundle-size-config.ts.

Acceptance Criteria

• npm run bundle:check exits with code 0 when the bundle is within threshold and code 1 when it exceeds it, printing a human-readable size comparison
• The guard reports minified size, gzipped size, absolute delta, and percentage change from baseline, all written to bundle-size-report.json
• Changes smaller than a configurable minimum noise floor (default 1 KB gzipped) are ignored to prevent spurious CI failures on trivial edits
• npm run bundle:update-baseline overwrites bundle-size-baseline.json with current measurements; the script is guarded against accidental invocation outside CI by checking a BUNDLE_BASELINE_UPDATE=true env var
• Tests assert that the guard exits with the correct code for a bundle under threshold, exactly at threshold, and over threshold
• All CI checks (npm test, npm run build, ESLint/TypeScript) pass and the branch has no merge conflicts

---

[NoahJoseph-ux]

@NoahJoseph-ux has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

Hello Maintainer, I’ve thoroughly read through the requirements and understand the expected outcome. I’d be happy to take this on if you can assign it to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @NoahJoseph-ux to this issue.

[OlaGreat]

@OlaGreat has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

I'd like to take this on. I'm a software engineer with experience in blockchain, backend systems, and open-source contribution. I've reviewed the issue and I'm confident I can deliver a clean implementation with tests covering the acceptance criteria. Happy to follow the project's existing conventions.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @OlaGreat to this issue.

[boss572]

@boss572 has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

Hello maintainer please I will like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @boss572 to this issue.

[drips-wave]

Congratulations, @boss572! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on July 30, 2026.

🧑‍💻 @boss572: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊