Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Bridge commands duplicate signer construction and miss new signer types

Aperta
  • Qualcosa non va?
#794 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@palango ci sta già lavorando.

Dal 19/8/2026.

  • #795 di @palango — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
68/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
cli, developer-experience

Direzione di ricerca

Inizia da BaseCommand.getWalletClient() in packages/cli/src/base.ts:229-308, quindi confronta la costruzione del wallet in packages/cli/src/commands/bridge/deposit.ts, withdraw-prove.ts e withdraw-finalize.ts. Traccia il modo in cui ogni comando salta BaseCommand.init() e associa la propria chain L1 e il proprio transport. Il lavoro è completato quando i tre comandi condividono la selezione del signer con BaseCommand, mantenendo il loro comportamento L1 e supportando i tipi di signer aggiunti lì.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Three bridge commands bypass BaseCommand's wallet construction and reimplement it, so any signer type added to BaseCommand silently does not work for them.

Detail

packages/cli/src/commands/bridge/deposit.ts, withdraw-prove.ts and withdraw-finalize.ts each declare async init() {} to skip BaseCommand.init(), then build their own wallet client in a private getL1WalletClient(). That method re-implements the --useLedger / --privateKey branching already present in BaseCommand.getWalletClient() (packages/cli/src/base.ts:229-308):

// packages/cli/src/commands/bridge/deposit.ts:149-162
} else if (res.flags.privateKey) {
  const account = privateKeyToAccount(ensureLeading0x(res.flags.privateKey))
  if (res.flags.from && !isAddressEqual(res.flags.from, account.address)) { ... }
  return createWalletClient({ account, chain: config.l1Chain, transport: http(l1RpcUrl) })
}

The duplication is understandable — these commands sign against L1, not the L2 chain --node points at, so they need a different chain and transport. But the signer selection logic is identical and has been copied rather than shared.

Why it matters

The branching is an exhaustive if/else if over signer types. Any signer added to BaseCommand — a keystore option, a new HSM, anything — works everywhere except these three commands, with no compile-time error and no runtime warning. The user just silently gets a different (or no) signer.

Suggested fix

Extract signer selection from chain/transport binding in BaseCommand, so a command can ask for "the configured signer, bound to this chain and transport". The bridge commands then pass their L1 chain and transport into the shared helper instead of re-deriving the account. That collapses three copies into one and makes new signer types work everywhere by construction.

Context

Found while scoping a --keystore option (like cast --keystore). That work is deliberately scoped to BaseCommand and will not cover the bridge commands, so --keystore will not work with bridge:deposit, bridge:withdraw-prove or bridge:withdraw-finalize until this is addressed.

Lingua principale
TypeScript
Stelle
43
Fork
36
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di celo-org/developer-tooling

Tutte le issue di celo-org/developer-tooling

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.