Dónde vive el paso de regenerar

Las tres alternativas

Los tres inconvenientes de exportar al arrancar

Hace falta abrir la ventana. Cambias un comando, quieres el binding actualizado, y tienes que lanzar la aplicación entera: compilar, arrancar el frontend, abrir la webview. Para un cambio de una firma es desproporcionado.

No se puede en integración continua. Un trabajo que quiera comprobar que el fichero está al día necesitaría un entorno gráfico. Y sin esa comprobación, un fichero viejo llega a la rama principal sin que nadie lo note.

Escribe desde el binario de producción si te descuidas. El ejemplo lleva la condición de depuración, y si alguien la quita —o la olvida al copiar— la aplicación instalada intenta escribir un fichero en una ruta relativa del ordenador del usuario. En el mejor caso falla en silencio.

La prueba

// bindings.rs — el builder, en una función para poder usarlo dos vecesuse tauri_specta::{collect_commands, Builder};pub fn builder() -> Builder<tauri::Wry> {    Builder::<tauri::Wry>::new().commands(collect_commands![        crate::proyectos::comandos::cargar_proyecto,        crate::proyectos::comandos::guardar_proyecto,    ])}#[cfg(test)]mod export {    #[test]    fn export_bindings() {        super::builder()            .export(specta_typescript::Typescript::default(), "../src/lib/bindings.ts")            .expect("no se pudo exportar el binding");    }}

// lib.rs — usa el mismo builder, sin exportar nadapub fn run() {    tauri::Builder::default()        .invoke_handler(bindings::builder().invoke_handler())        .run(tauri::generate_context!())        .expect("error al arrancar la aplicación");}

Y regenerar pasa a ser:

cd src-tauri && cargo test export_bindings

Segundos, sin ventana, y en un comando que cualquiera puede ejecutar. Además queda escrito en un sitio que se lee: quien abra el fichero de bindings y se pregunte cómo se regenera, encuentra la prueba buscando su nombre.

El paso que detecta el fichero viejo

Con la exportación en una prueba, la comprobación de integración continua es de dos líneas:

cargo test export_bindings          # regeneragit diff --exit-code src/lib/bindings.ts   # falla si cambió

Si alguien tocó una firma y no regeneró, el fichero cambia al ejecutar la prueba, el diff no está limpio, y el trabajo falla con un mensaje que se entiende. Sin ese paso, la generación de bindings sigue teniendo el mismo problema que quería resolver: un contrato que puede quedarse viejo sin que nadie se entere.

Es la pieza que convierte el sistema en una garantía en vez de una comodidad, y cuesta dos líneas.