Cargo.toml: la forma del paquete
El manifiesto del core: los tres tipos de librería y por qué son tres, las dependencias de compilación frente a las normales, las features de Tauri y qué activa cada una, y cómo se fija una versión que todavía no es estable.
El manifiesto, comentado
[package]name = "mi-app"version = "0.1.0"edition = "2021"# La versión de aquí NO es la de la aplicación: la que ve el usuario y la que# compara el updater vive en tauri.conf.json. Se pueden sincronizar, y conviene.[lib]name = "mi_app_lib"crate-type = ["staticlib", "cdylib", "rlib"][build-dependencies]tauri-build = { version = "2", features = [] }[dependencies]tauri = { version = "2", features = [] }serde = { version = "1", features = ["derive"] }serde_json = "1"Los tres tipos de biblioteca
Es la línea más rara del fichero y tiene una explicación exacta: cada uno de los tres sirve a un destino distinto.
| tipo | qué produce | para quién |
|---|---|---|
staticlib |
una biblioteca estática (.a) |
iOS, que enlaza tu código dentro de la aplicación |
cdylib |
una biblioteca dinámica con interfaz de C (.so) |
Android, que la carga en tiempo de ejecución |
rlib |
la biblioteca nativa de Rust | tu propio main.rs, y tus pruebas |
Sin rlib, el binario de escritorio no puede depender de la librería y main.rs deja de compilar. Sin los otros dos, el proyecto de escritorio funciona perfectamente y la fase XIII se vuelve imposible sin tocar esto. Como no cuesta nada dejarlos, el asistente los pone siempre.
Dependencias de compilación frente a normales
[build-dependencies] no es lo mismo que [dependencies], y la diferencia importa:
- Una dependencia normal se compila para el destino y acaba dentro de tu binario.
- Una dependencia de compilación se compila para la máquina que compila y solo la usa
build.rs. No viaja en el binario.
tauri-build es de las segundas porque su trabajo ocurre antes de que exista el programa: leer la configuración, generar el manifiesto de permisos, incrustar los metadatos de Windows. Eso es el nivel 6.3.
La consecuencia práctica es que cuando compilas de forma cruzada —para otra arquitectura, o para móvil— las dos listas se compilan para plataformas distintas. Verlo escrito evita un desconcierto grande la primera vez que un error menciona el destino equivocado.
Las features de Tauri
Aquí es donde se decide cuánto pesa y cuánto puede hacer tu aplicación. Cargo permite que un paquete ofrezca partes opcionales, y Tauri las usa a fondo: features = [] significa que solo llevas el núcleo.
Las que más se activan:
| feature | qué habilita | coste |
|---|---|---|
tray-icon |
el icono de bandeja y su menú | en Linux arrastra la dependencia del indicador de aplicación |
image-png, image-ico |
cargar iconos en esos formatos en tiempo de ejecución | pequeño, y hace falta si el icono no es estático |
macos-private-api |
transparencia y efectos de material en macOS | incompatible con la Mac App Store. Nivel 12 y 76 |
devtools |
las herramientas de desarrollo en una compilación de producción | activo por defecto en desarrollo; activarlo en producción es una decisión |
protocol-asset |
el protocolo que sirve ficheros del disco a la webview | amplía la superficie. Nivel 31 |
Fijar una versión que aún no es estable
Parte del ecosistema alrededor de Tauri publica versiones candidatas durante mucho tiempo. tauri-specta, que genera los bindings del nivel 19, es el caso más habitual. Con esos paquetes, la regla de compatibilidad de Cargo no protege igual: antes de la versión 1.0, y entre candidatas, cualquier publicación puede traer cambios que rompen.
La forma de tratarlos es fijar la versión exacta y dejar dicho por qué:
# Fijado: no hay 2.x estable en el registro todavía, solo candidatas. Antes de# subirlo, comprobar que no salta a una 3.x con cambios que rompen.tauri-specta = "=2.0.0-rc.25"El signo igual delante desactiva la actualización automática dentro de la familia. Es más trabajo y es lo correcto cuando el paquete no promete compatibilidad todavía.