Los generadores: add, icon y signer
Los tres subcomandos que escriben en tu proyecto. Qué toca cada uno exactamente, en qué orden hay que ejecutarlos, y el que hay que preparar antes de lanzar porque su salida no se puede volver a meter en la botella.
add: un plugin, cuatro ficheros
bun run tauri add dialogToca cuatro sitios, y merece la pena saber cuáles porque el cuarto es el que importa:
| fichero | qué le hace |
|---|---|
src-tauri/Cargo.toml |
añade la dependencia de Rust |
package.json |
añade el paquete de JavaScript, a la misma versión |
src-tauri/src/lib.rs |
inserta la llamada .plugin(...) en el builder |
src-tauri/capabilities/default.json |
concede el permiso por defecto del plugin |
Los tres primeros son mecánica. El cuarto es una decisión de seguridad que el subcomando toma por ti, y por eso la recomendación del nivel 8.3 se repite aquí: lee el diff del fichero de capabilities cada vez.
El permiso por defecto de un plugin suele ser razonable y casi nunca es el mínimo. El de diálogos, por ejemplo, concede abrir y guardar; si tu aplicación solo abre, hay un permiso más estrecho. permission ls los enumera.
icon: idempotente y destructivo a la vez
bun run tauri icon ./marca/logo.pngGenera el juego completo en src-tauri/icons/, sobrescribiendo lo que hubiera. Las dos propiedades conviven: se puede repetir tantas veces como quieras con el mismo resultado, y borra cualquier icono que hubieras retocado a mano.
De ahí la regla del nivel 8.2: la fuente de verdad es tu imagen original, versionada fuera del directorio de iconos, y el directorio de iconos es salida generada. Si alguna vez necesitas un icono distinto para una plataforma —cosa razonable, porque las convenciones de forma difieren— la salida no es editar el generado: es tener otra imagen de partida y una variante de configuración que apunte a ella.
Dos recordatorios del nivel 8.2, porque es donde más se falla:
- La imagen de partida, cuadrada y del orden de mil píxeles de lado.
- Sin esquinas redondeadas dibujadas: macOS aplica las suyas y quedan dobles.
signer generate: el que hay que preparar
bun run tauri signer generate -w ~/.tauri/mi-app.keyCrea un par de claves: la privada, que firma cada actualización, y la pública, que va en la configuración para que la aplicación instalada valide la firma.
El orden correcto es este, y no otro:
Por qué no se puede deshacer. Si la clave privada llega al historial del repositorio, borrarla del árbol no la quita del historial, y hay que asumir que alguien pudo copiarla. La única respuesta correcta es generar un par nuevo, cambiar la pública en la configuración y publicar una versión. Y ahí aparece el problema de verdad: las instalaciones que ya tienen la clave pública vieja no aceptarán actualizaciones firmadas con la nueva. Es decir, que un descuido de treinta segundos puede dejar a tus usuarios sin camino de actualización.
Esa asimetría —treinta segundos de descuido, un problema sin salida limpia— es la razón de que este subcomando tenga su propia sección.
Cuándo hacerlo a mano
Los generadores están para ahorrar trabajo mecánico, no para tomar decisiones. Hay tres casos en los que conviene no usarlos:
- Un plugin cuyo permiso por defecto es más ancho de lo que necesitas. Instálalo con el subcomando y después aprieta el permiso a mano, o instálalo a mano desde el principio.
- Iconos que difieren por plataforma. El generador produce un juego desde una imagen; si necesitas dos juegos, necesitas dos ejecuciones y una variante de configuración.
- Claves en un sistema de gestión de secretos serio. Si tu organización tiene un almacén de claves, generarlas ahí y no en tu portátil es mejor idea que generarlas aquí y subirlas.