Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Bridge commands duplicate signer construction and miss new signer types

Abierto
  • ¿Algo no está bien?
#794 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@palango ya está trabajando en esto.

Desde el 19/8/2026.

  • #795 de @palango — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
68/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
cli, developer-experience

Línea de trabajo

Comienza con BaseCommand.getWalletClient() en packages/cli/src/base.ts:229-308 y luego compara la construcción de la wallet en packages/cli/src/commands/bridge/deposit.ts, withdraw-prove.ts y withdraw-finalize.ts. Traza cómo cada comando omite BaseCommand.init() y vincula su cadena L1 y su transporte. El trabajo estará terminado cuando los tres comandos compartan la selección del signer con BaseCommand, conserven su comportamiento L1 y admitan los tipos de signer añadidos allí.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
43
Forks
36
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de celo-org/developer-tooling

Todos los issues de celo-org/developer-tooling

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.