buffer polyfill is used directly but not declared as a project dependency
src/main.tsx explicitly does import { Buffer } from 'buffer' and polyfills window.Buffer for the Stellar SDK, but buffer does not appear in package.json's dependencies — it's only present in package-lock.json as a transitive dependency (currently pulled in indirectly, likely via @stellar/stellar-sdk).
If that transitive chain ever changes (an SDK upgrade, a lockfile regeneration), the app will fail to build/run with a confusing "module not found" error. Add buffer as an explicit direct dependency to pin this intentional usage.
Additional Notes
Precision on blast radius: Buffer (via this polyfill) is a load-bearing global for the entire Stellar SDK surface used throughout the app — src/lib/stellar.ts, src/context/WalletContext.tsx's signTransaction, and any XDR encode/decode path (transaction building in useSendPayment, useBatchPayment, useEscrows, useSubscriptions) all transitively depend on window.Buffer existing before their code runs. Because main.tsx sets this up at the top of the module before ReactDOM.render, a missing/broken polyfill wouldn't fail loudly at import time in dev (Vite's dependency pre-bundling currently resolves buffer from wherever it happens to sit in node_modules) — it would only surface the moment someone runs npm ci against a regenerated lockfile that happens to change the transitive resolution path, likely in CI or a fresh clone, which is exactly the kind of failure that's hard to reproduce and debug for whoever hits it first.
Implementation sketch: run npm install buffer@<version currently resolved in package-lock.json> to add it as an explicit dependencies entry (not devDependencies, since it's needed at runtime in the browser bundle, not just for tooling); confirm the version matches (or is compatible with) whatever @stellar/stellar-sdk's own buffer peer/dependency expects, to avoid two different buffer versions being bundled if Vite's dedupe doesn't collapse them; double check vite.config.ts for any existing resolve.alias/optimizeDeps entries related to buffer/process/other Node polyfills (Stellar SDK usage commonly also needs a process shim) and note whether those are similarly undeclared.
Edge cases: a fresh npm install (no lockfile) instead of npm ci could resolve a different transitive buffer version than what's pinned in package-lock.json today — worth checking whether pinning an explicit version here changes app behavior at all (it shouldn't, if the polyfill surface used is small, but worth a smoke test); confirm the polyfill is applied before any other module that might construct XDR/Buffer-backed objects at module-eval time (import order matters for a global polyfill like this).
Testing strategy: this is best verified with a build-time check rather than a unit test — add a CI step (or extend the one proposed in the test-runner issue, #1) that runs npm ci from a clean node_modules and asserts the production build (npm run build) succeeds, which would have caught this class of problem; optionally, a smoke test that imports and calls a Stellar SDK function requiring Buffer (e.g. building a minimal TransactionBuilder) in the jsdom test environment once the test runner from issue #1 exists, to confirm the polyfill works outside the browser's native module resolution too.
buffer polyfill is used directly but not declared as a project dependency
src/main.tsxexplicitly doesimport { Buffer } from 'buffer'and polyfillswindow.Bufferfor the Stellar SDK, butbufferdoes not appear inpackage.json'sdependencies— it's only present inpackage-lock.jsonas a transitive dependency (currently pulled in indirectly, likely via@stellar/stellar-sdk).If that transitive chain ever changes (an SDK upgrade, a lockfile regeneration), the app will fail to build/run with a confusing "module not found" error. Add
bufferas an explicit direct dependency to pin this intentional usage.Additional Notes
Precision on blast radius:
Buffer(via this polyfill) is a load-bearing global for the entire Stellar SDK surface used throughout the app —src/lib/stellar.ts,src/context/WalletContext.tsx'ssignTransaction, and any XDR encode/decode path (transaction building inuseSendPayment,useBatchPayment,useEscrows,useSubscriptions) all transitively depend onwindow.Bufferexisting before their code runs. Becausemain.tsxsets this up at the top of the module beforeReactDOM.render, a missing/broken polyfill wouldn't fail loudly atimporttime in dev (Vite's dependency pre-bundling currently resolvesbufferfrom wherever it happens to sit innode_modules) — it would only surface the moment someone runsnpm ciagainst a regenerated lockfile that happens to change the transitive resolution path, likely in CI or a fresh clone, which is exactly the kind of failure that's hard to reproduce and debug for whoever hits it first.Implementation sketch: run
npm install buffer@<version currently resolved in package-lock.json>to add it as an explicitdependenciesentry (notdevDependencies, since it's needed at runtime in the browser bundle, not just for tooling); confirm the version matches (or is compatible with) whatever@stellar/stellar-sdk's ownbufferpeer/dependency expects, to avoid two differentbufferversions being bundled if Vite's dedupe doesn't collapse them; double checkvite.config.tsfor any existingresolve.alias/optimizeDepsentries related tobuffer/process/other Node polyfills (Stellar SDK usage commonly also needs aprocessshim) and note whether those are similarly undeclared.Edge cases: a fresh
npm install(no lockfile) instead ofnpm cicould resolve a different transitivebufferversion than what's pinned inpackage-lock.jsontoday — worth checking whether pinning an explicit version here changes app behavior at all (it shouldn't, if the polyfill surface used is small, but worth a smoke test); confirm the polyfill is applied before any other module that might construct XDR/Buffer-backed objects at module-eval time (import order matters for a global polyfill like this).Testing strategy: this is best verified with a build-time check rather than a unit test — add a CI step (or extend the one proposed in the test-runner issue, #1) that runs
npm cifrom a cleannode_modulesand asserts the production build (npm run build) succeeds, which would have caught this class of problem; optionally, a smoke test that imports and calls a Stellar SDK function requiringBuffer(e.g. building a minimalTransactionBuilder) in the jsdom test environment once the test runner from issue #1 exists, to confirm the polyfill works outside the browser's native module resolution too.