Bitácora

Sacar la biblioteca del binario

En 0.10 la capa de dominio salió del binario y pasó a un crate propio. El CLI depende ahora de ella como dependría cualquier otro consumidor, y la TUI también.

En 0.10 la capa de dominio salió del binario y pasó a un crate propio. El CLI depende ahora de ella como dependría cualquier otro consumidor, y la TUI también.

before 0.10 one crate cli.rs at 6.6k lines 97 tests 0.10 onwards torii (binary) torii tui next one torii-core — the domain layer vcs · platforms · workspace · config · auth 97 → 282 tests in the same release a surface you can call is a surface you can test without spawning a process

Por qué valía una release

Un CLI que es dueño de su propia lógica solo se puede probar ejecutándolo. Lanzas un proceso, le pasas argumentos, lees stdout y afirmas sobre un texto que existe para que lo lea una persona. Esos tests son lentos, se rompen cuando mejoras un mensaje, y no llegan a la mitad interesante del código.

El número de tests pasó de 97 a 282 en la misma release. Eso no es diligencia que aparece de golpe: es lo que ocurre cuando las operaciones se convierten en funciones que puedes llamar. Fixtures de parseo por plataforma, tests de cliente con httpmock que afirman sobre cabeceras de autenticación y mapeo de estados, tests de estado de la TUI, tests de despacho del CLI — nada de eso era alcanzable antes del split, y nada de eso necesitó un subproceso después.

Qué más salió de ahí

Los tres ficheros más grandes se partieron en la misma pasada. cli.rs tenía 6.600 líneas y pasó a ser una superficie de clap más veinticuatro módulos de dominio. El app.rs y el events.rs de la TUI pasaron a módulos por vista. El código de plataformas se reorganizó por plataforma en vez de por función, que es por lo que los siete directorios de cliente existen con la forma que tienen.

Y unos 415 puntos de error genéricos recibieron variantes precisas: Network, PlatformApi llevando el estado HTTP real, Auth, MalformedResponse, Subprocess, Fs, RepoState, Workspace, Unsupported y Usage. Antes de eso, muchísimos fallos llegaban como InvalidConfig, que es una mentira con cara de verdad: vas a revisar tu configuración, y tu configuración está bien.

El fallo que solo aparece con una frontera de biblioteca

torii log | head

Eso reventaba con failed printing to stdout: Broken pipe. head cierra la tubería en cuanto tiene sus diez líneas, la escritura falla, y la disposición por defecto de SIGPIPE en Rust convierte eso en un pánico en vez de en la salida silenciosa que hace cualquier otra herramienta de línea de comandos. El arreglo es una línea al arrancar —restaurar SIGPIPE a su valor por defecto— y es la clase de cosa que encuentras cuando empiezas a preguntarte qué hace el proceso y no solo qué devuelven las funciones.

Dos más de la misma release, ambas mundanas y ambas de las que hacen que una herramienta parezca sin terminar: torii rename movía un directorio en disco y luego fallaba al indexarlo, porque Index::add_path solo acepta ficheros; y torii save se colgaba para siempre sin TTY cuando el escáner encontraba algo, esperando un [y/N] que nadie podía contestar. Ahora falla rápido y nombra --yes.

Qué prepara

Una biblioteca, varios frontales. El CLI y la TUI son dos de ellos hoy. La aplicación gráfica del roadmap es el tercero, y la razón de que sea un trabajo plausible y no una reescritura es que hereda los snapshots, el escáner y los clientes de plataforma en vez de reimplementarlos.