De Tuist v3 a v4
Con el lanzamiento de Tuist 4, aprovechamos la oportunidad para introducir algunos cambios incompatibles en el proyecto, que creímos facilitarían su uso y mantenimiento a largo plazo. Este documento describe los cambios que deberás aplicar en tu proyecto para actualizar de Tuist 3 a Tuist 4.
Eliminada la gestión de versiones mediante tuistenv#
Antes de Tuist 4, el script de instalación instalaba una herramienta, tuistenv, que se renombraba a tuist durante la instalación. La herramienta se encargaba de instalar y activar versiones de Tuist, garantizando determinismo entre entornos. Con el objetivo de reducir la superficie de funcionalidades de Tuist, decidimos eliminar tuistenv en favor de Mise, una herramienta que realiza la misma tarea pero es más flexible y puede usarse con distintas herramientas. Si utilizabas tuistenv, tendrás que desinstalar la versión actual de Tuist ejecutando curl -Ls https://uninstall.tuist.io | bash y luego instalarla con el método de instalación que prefieras. Recomendamos encarecidamente usar Mise porque puede instalar y activar versiones de forma determinista entre entornos.
curl -Ls https://uninstall.tuist.io | bash
Si decides adoptar el determinismo que ofrece Mise en todos los ámbitos, te recomendamos consultar la documentación sobre cómo usar Mise en entornos de CI y proyectos de Xcode.
Ten en cuenta que aún puedes instalar Tuist mediante Homebrew, un gestor de paquetes popular para macOS. Puedes encontrar las instrucciones para instalar Tuist con Homebrew en la guía de instalación.
Eliminados los constructores init de los modelos ProjectDescription#
Con el objetivo de mejorar la legibilidad y expresividad de las API, decidimos eliminar los constructores init de todos los modelos ProjectDescription. Ahora cada modelo proporciona un constructor estático que puedes usar para crear instancias. Si utilizabas los constructores init, tendrás que actualizar tu proyecto para usar los constructores estáticos.
La convención de nomenclatura que seguimos consiste en usar el nombre del modelo como nombre del constructor estático. Por ejemplo, el constructor estático del modelo Target es Target.target.
Renombrado --no-cache a --no-binary-cache#
Dado que la opción --no-cache era ambigua, decidimos renombrarla a --no-binary-cache para dejar claro que hace referencia a la caché binaria. Si utilizabas la opción --no-cache, tendrás que actualizar tu proyecto para usar la opción --no-binary-cache.
Renombrado tuist fetch a tuist install#
Renombramos el comando tuist fetch a tuist install para alinearnos con la convención de la industria. Si utilizabas el comando tuist fetch, tendrás que actualizar tu proyecto para usar el comando tuist install.
Adoptar Package.swift como DSL para dependencias#
Antes de Tuist 4, podías definir dependencias en un archivo Dependencies.swift. Este formato propietario rompía la compatibilidad con herramientas como Dependabot o Renovatebot para actualizar dependencias automáticamente. Además, introducía indirecciones innecesarias para los usuarios. Por ello, decidimos adoptar Package.swift como la única forma de definir dependencias en Tuist. Si utilizabas el archivo Dependencies.swift, tendrás que mover el contenido de tu Tuist/Dependencies.swift a un Package.swift en la raíz y usar la directiva #if TUIST para configurar la integración. Puedes leer más sobre cómo integrar dependencias de Swift Package aquí
Renombrado tuist cache warm a tuist cache#
Por brevedad, decidimos renombrar el comando tuist cache warm a tuist cache. Si utilizabas el comando tuist cache warm, tendrás que actualizar tu proyecto para usar el comando tuist cache.
Renombrado tuist cache print-hashes a tuist cache --print-hashes#
Decidimos renombrar el comando tuist cache print-hashes a tuist cache --print-hashes para dejar claro que es una opción del comando tuist cache. Si utilizabas el comando tuist cache print-hashes, tendrás que actualizar tu proyecto para usar la opción tuist cache --print-hashes.
Eliminados los perfiles de caché#
Antes de Tuist 4, podías definir perfiles de caché en Tuist/Config.swift, que contenían una configuración para la caché. Decidimos eliminar esta funcionalidad porque podía generar confusión al usarla en el proceso de generación con un perfil distinto al utilizado para generar el proyecto. Además, podía llevar a los usuarios a usar un perfil de depuración para compilar una versión de producción de la app, lo que podría provocar resultados inesperados. En su lugar, introdujimos la opción --configuration, que puedes usar para especificar la configuración que deseas emplear al generar el proyecto. Si utilizabas perfiles de caché, tendrás que actualizar tu proyecto para usar la opción --configuration.
Eliminada --skip-cache en favor de argumentos#
Eliminamos la opción --skip-cache del comando generate y ahora controlas para qué targets se omite la caché binaria mediante argumentos. Si utilizabas la opción --skip-cache, tendrás que actualizar tu proyecto para usar los argumentos.
tuist generate --skip-cache Foo
tuist generate Foo
Eliminadas las capacidades de firma#
La firma ya está resuelta por herramientas de la comunidad como Fastlane y el propio Xcode, que lo hacen mucho mejor. Consideramos que la firma era un objetivo secundario para Tuist y que era mejor centrarse en las funcionalidades principales del proyecto. Si utilizabas las capacidades de firma de Tuist, que consistían en cifrar los certificados y los perfiles en el repositorio e instalarlos en los lugares adecuados durante la generación, quizá quieras replicar esa lógica en tus propios scripts que se ejecutan antes de la generación del proyecto. En particular:
- Un script que descifre los certificados y los perfiles usando una clave almacenada en el sistema de archivos o en una variable de entorno, e instale los certificados en el llavero y los perfiles de aprovisionamiento en el directorio
~/Library/MobileDevice/Provisioning\ Profiles. - Un script que pueda tomar perfiles y certificados existentes y cifrarlos.
La firma requiere que los certificados correctos estén presentes en el llavero y que los perfiles de aprovisionamiento estén en el directorio ~/Library/MobileDevice/Provisioning\ Profiles. Puedes usar la herramienta de línea de comandos security para instalar certificados en el llavero y el comando cp para copiar los perfiles de aprovisionamiento al directorio adecuado.
Eliminada la integración con Carthage mediante Dependencies.swift#
Antes de Tuist 4, las dependencias de Carthage podían definirse en un archivo Dependencies.swift, que los usuarios podían obtener ejecutando tuist fetch. También consideramos que esto era un objetivo secundario para Tuist, especialmente teniendo en cuenta un futuro donde Swift Package Manager sería la forma preferida de gestionar dependencias. Si utilizabas dependencias de Carthage, tendrás que usar Carthage directamente para descargar los frameworks y XCFrameworks precompilados al directorio estándar de Carthage y luego hacer referencia a esos binarios desde tus targets usando los casos TargetDependency.xcframework y TargetDependency.framework.
Algunos usuarios entendieron que eliminamos el soporte para Carthage. No fue así. El contrato entre Tuist y la salida de Carthage se basa en frameworks y XCFrameworks almacenados en el sistema. Lo único que ha cambiado es quién es responsable de obtener las dependencias. Antes era Tuist a través de Carthage, ahora es Carthage.
Eliminada la API TargetDependency.packagePlugin#
Antes de Tuist 4, podías definir una dependencia de plugin de paquete usando el caso TargetDependency.packagePlugin. Tras ver cómo Swift Package Manager introducía nuevos tipos de paquetes, decidimos iterar sobre la API hacia algo más flexible y preparado para el futuro. Si utilizabas TargetDependency.packagePlugin, tendrás que usar TargetDependency.package en su lugar y pasar el tipo de paquete que deseas utilizar como argumento.
Eliminadas las APIs obsoletas#
Eliminamos las APIs que estaban marcadas como obsoletas en Tuist 3. Si utilizabas alguna de las APIs obsoletas, tendrás que actualizar tu proyecto para usar las nuevas APIs.