Cocoapods es considerado el administrador de dependencias más popular para iOS. En los últimos años, Apple ha estado trabajando en el desarrollo de su administrador de dependencia nativo Swift Package Manager (SPM).Inicialmente, su uso solo era posible para aplicaciones Swift o terminales del lado del servidor. SPM se ejecutó y modificó en tales aplicaciones, la comunidad se familiarizó con su trabajo y el equipo de Apple recibió beta testers.Con el lanzamiento de Xcode 11, SPM comenzó a entrar en el mundo del desarrollo para iOS. Ahora ya es una herramienta completa que se puede usar, pero hasta ahora con limitaciones.En la versión actual, SPM no admite recursos (estamos esperando SE-0271 ). En nuestro país, cada módulo es una dependencia atómica autosuficiente que se puede conectar al proyecto, por lo que se necesitan recursos (localización, activos).Mientras tanto, podemos prepararnos para la migración: para comprender lo difícil que es, si se puede automatizar y qué problemas puede encontrar.¿Por qué migrar de Cocoapods a SPM?
- Natividad e integración en el ecosistema. Ya, Xcode propone crear o agregar un paquete SPM.
- A diferencia de Cocoapods, ya no es necesario tener un espacio de trabajo para trabajar en un proyecto de dependencia.
- Después de agregar una nueva dependencia, no necesita hacer la instalación del pod y reconstruir todo el proyecto.
- Es conveniente utilizar dependencias locales: la estructura de la carpeta no cambia, se reconstruye más rápido.
- SPM , Cocoapods, Ruby ( iOS-).
- Cocoapods Xcode Swift.
- Example : Xcode Package.swift .
- abstract_target: SPM .
- blame , .
- Ruby, .
?
Si su proyecto tiene muchas dependencias, el proceso de migración no puede completarse en un día. El número de dependencias en el Podfile no es igual al número total de dependencias, ya que una dependencia puede venir con diez más. Incluso si no tiene muchas dependencias, pero desarrolla sus dependencias, es posible, incluso en repositorios privados, no migrar rápidamente. Afortunadamente, SPM se lleva bien con Cocoapods, y el proceso de migración se puede repetir. Lo principal es tener en cuenta los matices:- No debe haber intersecciones entre las dependencias SPM y Cocoapods.
- La migración debe integrarse en el proceso de desarrollo de componentes. Si el componente se está desarrollando, se debe realizar una actualización de versión tanto para Cocoapods como para SPM.
- No debería haber ninguna dificultad para el equipo, lo que significa que debe implementar la instalación de todas las dependencias a través de un solo comando cli.
- La migración debe estar integrada en el CD de CI. El proyecto debe construirse tanto localmente como en agentes de CI, en todas las configuraciones.
¿Dónde empezar?
En primer lugar, recopilamos una lista completa de sus dependencias, que se presenta en Podfile.lock. Puede usar utilidades como SPMReady .
A continuación, los agrupamos por relación. Por ejemplo, casi todos los componentes dependen de SMENetwork, lo que significa que no podremos migrarlos a SPM hasta que SMENetwork migre.Luego seleccionamos un módulo, del cual dependen la mayoría de los módulos: SMENetwork.Finalmente, vaya al repositorio de este módulo, verifíquelo en una carpeta y cree un módulo en la raíz de esta carpeta.git clone ssh://.../smenetwork.git Developer/SMENetwork
cd Developer/SMENetwork
swift package init
Creating library package: SMENetwork
Creating Package.swift
Creating Sources/
Creating Sources/SMENetwork/SMENetwork.swift
Creating Tests/
Creating Tests/LinuxMain.swift
Creating Tests/SMENetworkTests/
Creating Tests/SMENetworkTests/SMENetworkTests.swift
Creating Tests/SMENetworkTests/XCTestManifests.swift
Como resultado, obtenemos el archivo principal Package.swift y las carpetas Fuentes y Pruebas. Si ya los tenía, no se molerán. Los archivos SMENetwork.swift, SMENetworkTests.swift, XCTestManifests.swift, LinuxMain.swift se crearon para el ejemplo de operación del paquete, se pueden eliminar.El archivo Package.swift tiene este aspecto:
ahora veamos el archivo SMENetwork.podspec:
como puede ver, las fuentes y las pruebas están en otras carpetas. Transfiera los archivos y pruebe el proyecto de ejemplo Cocoapods.
Agregamos la plataforma de desarrollo a Package.swift y transferimos las dependencias del archivo podspec aquí. Nos aseguramos de que sean compatibles con SPM: solo verifique que haya un archivo Package.swift en Github. Si no está allí y ni siquiera hay un RP con él, haremos un RP y ayudaremos a la comunidad de código abierto.
Para SPM, no necesita crear un proyecto de ejemplo: simplemente abra Package.swift en Xcode y descargará y conectará las dependencias, creará los objetivos de acuerdo con nuestra especificación. Solo podemos correr.
En nuestro caso, casi todo salió de la caja, con la excepción de un lugar donde se olvidó la importación de Foundation: los desarrolladores de iOS están acostumbrados al hecho de que UIKit y Foundation son opcionales, porque funciona sin ellos. Es hora de desaprender este hábito.
El paquete se compila, las pruebas se compilan, pero fallan.
Y aquí nos encontramos con una limitación de la falta de recursos en Package, las pruebas se basan en los simulacros que se encuentran en json, estamos esperando SE-0271 ...Total
Cambiar de Cocoapods a SPM es fácil. Los pasos son claros, pero el flujo es monótono y requiere automatización.Sin mucho esfuerzo, puede crear un paquete desde el archivo .podspec y confirmarlo en el repositorio. Y lo más importante: puede moverse con un proyecto, y el otro permanecerá en Cocoapods. Si él quiere, por supuesto.