fix: repair stellar-wallets-kit v2 and stellar-sdk v16 breaks from dependabot bumps#211
Merged
Merged
Conversation
…m dependabot bumps PRs #209/#210 bumped @creit.tech/stellar-wallets-kit (1.9.5->2.5.0) and @stellar/stellar-sdk (14.6.1->16.0.1) across major versions, silently breaking the frontend production build and the reindex script: - walletKit.js imported FreighterModule/WalletNetwork from the kit's root export, which v2 no longer provides (FreighterModule now lives under a submodule path, WalletNetwork was renamed to Networks). This broke `vite build`. - scripts/reindex.js imported SorobanRpc, removed in stellar-sdk v16 in favor of the `rpc` namespace already used elsewhere in the indexer. - Updated the accompanying test-scripts.js check to match. Verified: bimex-indexer vitest (38/38) + test:scripts, bimex-frontend vitest (124/124), eslint (0 errors), and vite build all pass.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
CI's "Contrato Soroban" job has been failing on main since the #209/#210 dependency bumps merged (in fact since before them): bimex/Cargo.lock was gitignored, so every CI run re-resolved dependencies from scratch. Since soroban-env-host 26.1.3 declares `ed25519-dalek = ">=2.0.0"` with no upper bound, the resolver started picking the newly published ed25519-dalek 3.0.0, whose rand_core trait bounds are incompatible with the ChaCha20Rng used in soroban-env-host's own testutils.rs, breaking `cargo test` entirely with an unrelated-looking trait error. Fix: force the whole graph onto ed25519-dalek 2.2.0 (`cargo update -p ed25519-dalek@3.0.0 --precise 2.2.0`) and commit the resulting Cargo.lock so builds are reproducible instead of drifting with upstream releases. Also regenerated the contract's test_snapshots/, which were stale since the soroban-sdk 25->26 bump (#196) and had never been refreshed because CI hadn't successfully run `cargo test` since. Verified: cargo test (64/64), cargo clippy -D warnings, and cargo audit --deny warnings all pass in bimex/.
The v1->v2 bump (#210) didn't just move exports around (fixed in the previous commit) — it turned StellarWalletsKit into an all-static class backed by module-level signal state, dropping the old per-instance API entirely. That silently broke wallet auto-reconnect at runtime even though the app built and rendered fine: - `new StellarWalletsKit(...)` no longer configures anything; use the static `StellarWalletsKit.init(...)` instead. - `kit.setWallet(id)` is now the static `StellarWalletsKit.setWallet(id)` (confirmed via a live TypeError: "walletKit.setWallet is not a function" while reproducing the E2E failure). - `kit.openModal({ onWalletSelected, onClosed })` was replaced by `StellarWalletsKit.authModal()`, which returns a promise resolving to `{ address }` directly instead of taking callbacks. - `kit.getAddress({ skipRequestAccess })` became `fetchAddress()` (no options) for a live lookup, since `getAddress()` now only returns the cached in-memory address. Root-caused by reproducing the failing Playwright golden-path spec locally against the mocked Freighter fixture, which surfaced the setWallet TypeError directly. Verified: bimex-frontend vitest (124/124) and all 25 Playwright E2E specs (golden-path, filtros, landing) pass locally against the mocked wallet fixtures.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Descripción
Los últimos dos merges a
main(#209chore(deps): bump indexer-dependenciesy #210chore(deps): bump frontend-dependencies, ambos de dependabot) subieron varias dependencias de versión mayor sin verificar compatibilidad. Dos de esos saltos rompían el build/scripts en silencio (los tests no lo detectaban porque no ejercitan esas rutas). Este PR corrige ambas roturas.Cambios
bimex-frontend/src/stellar/walletKit.js:@creit.tech/stellar-wallets-kitpasó de 1.9.5 a 2.5.0. En v2,FreighterModuleya no se exporta desde la raíz del paquete (ahora vive en@creit.tech/stellar-wallets-kit/modules/freighter) yWalletNetworkfue renombrado aNetworks. Esto rompíanpm run build(vite build) con erroresMISSING_EXPORT. También se corrigió la ruta del import dinámico del módulo de WalletConnect (modules/walletconnect.module→modules/wallet-connect).bimex-indexer/scripts/reindex.js:@stellar/stellar-sdkpasó de 14.6.1 a 16.0.1, donde el namespaceSorobanRpcfue eliminado en favor derpc(patrón ya usado enindex.jsyapi.js). El script rompía al ejecutarse.bimex-indexer/scripts/test-scripts.js: actualizado el check de humo que validaba (por texto) el import deSorobanRpcenreindex.js, para que valide el nuevo patrónrpc as StellarRpc.Verificación
npm run test:runpasa sin errores (frontend: 124/124)npx vitest runpasa sin errores (indexer: 38/38)node scripts/test-scripts.jspasa sin errores (indexer)npm run buildsin errores de compilación (frontend, antes fallaba conMISSING_EXPORT)npm run lintsin errores (frontend, 0 errores / warnings preexistentes no relacionados)cargo test(no aplica, no se tocó el contrato)Notas para el revisor
Los bumps de dependabot (#209/#210) pasaron CI porque los tests unitarios no ejercitan
vite builden producción niscripts/reindex.js. Vale la pena considerar añadir un chequeo de build en el workflow de CI de dependabot para detectar este tipo de rotura antes del merge automático.Generated by Claude Code