Cocoapods est considéré comme le gestionnaire de dépendances le plus populaire pour iOS. Au cours des dernières années, Apple a travaillé au développement de son gestionnaire de dépendance natif Swift Package Manager (SPM).Initialement, son utilisation n'était possible que pour les applications Swift ou terminaux côté serveur. SPM a été exécuté et modifié sur de telles applications, la communauté s'est familiarisée avec son travail et l'équipe Apple a reçu des bêta-testeurs.Avec la sortie de Xcode 11, SPM a commencé à entrer dans le monde du développement pour iOS. Maintenant, c'est déjà un outil à part entière qui peut être utilisé, mais jusqu'à présent avec des limites.Dans la version actuelle, SPM ne prend pas en charge les ressources (nous attendons SE-0271 ). Dans notre pays, chaque module est une dépendance atomique autosuffisante qui peut être connectée au projet, donc des ressources sont nécessaires (localisation, actifs).En attendant, nous pouvons préparer la migration: pour comprendre à quel point elle est difficile, si elle peut être automatisée et quels problèmes vous pouvez rencontrer.Pourquoi migrer de Cocoapods vers SPM?
- Nativité et intégration dans l'écosystème. Déjà, Xcode propose de créer ou d'ajouter un package SPM.
- Contrairement aux Cocoapods, il n'est plus nécessaire d'avoir un espace de travail pour travailler sur un projet de dépendance.
- Après avoir ajouté une nouvelle dépendance, vous n'avez pas besoin d'effectuer l'installation du pod et de reconstruire l'intégralité du projet.
- Il est pratique d'utiliser des dépendances locales: la structure des dossiers ne change pas, elle est reconstruite plus rapidement.
- SPM , Cocoapods, Ruby ( iOS-).
- Cocoapods Xcode Swift.
- Example : Xcode Package.swift .
- abstract_target: SPM .
- blame , .
- Ruby, .
?
Si votre projet comporte de nombreuses dépendances, le processus de migration ne peut pas être terminé en une journée. Le nombre de dépendances dans le Podfile n'est pas égal au nombre total de dépendances, car une dépendance peut être regroupée avec dix autres. Même si vous n'avez pas beaucoup de dépendances, mais que vous développez vos dépendances, il est possible, même dans des référentiels privés, de ne pas migrer rapidement. Heureusement, SPM s'entend bien avec les Cocoapods et le processus de migration peut être itéré. L'essentiel est de prendre en compte les nuances:- Il ne doit pas y avoir d'intersection entre les dépendances SPM et Cocoapods.
- La migration doit être intégrée dans le processus de développement des composants. Si le composant est en développement, une mise à niveau de version doit être effectuée pour les Cocoapods et SPM.
- Il ne devrait pas y avoir de difficultés pour l'équipe, ce qui signifie que vous devez implémenter l'installation de toutes les dépendances via une seule commande cli.
- La migration doit être intégrée au CD CI. Le projet doit être construit à la fois localement et sur des agents CI, dans toutes les configurations.
Où commencer?
Tout d'abord, nous collectons une liste complète de vos dépendances - elle est présentée dans Podfile.lock. Vous pouvez utiliser des utilitaires tels que SPMReady .
Ensuite, nous les regroupons par relation. Par exemple, presque tous les composants dépendent de SMENetwork, ce qui signifie que nous ne pourrons pas les migrer vers SPM jusqu'à ce que SMENetwork lui-même migre.Ensuite, nous sélectionnons un module, dont la plupart des modules dépendent - SMENetwork.Enfin, accédez au référentiel de ce module, archivez-le dans un dossier et créez un module à la racine de ce dossier.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
Par conséquent, nous obtenons le fichier Package.swift principal et les dossiers Sources et Tests. Si vous les aviez déjà, ils ne broyeront pas. Les fichiers SMENetwork.swift, SMENetworkTests.swift, XCTestManifests.swift, LinuxMain.swift ont été créés pour l'exemple d'opération de package, ils peuvent être supprimés.Le fichier Package.swift ressemble à ceci:
Voyons maintenant le fichier SMENetwork.podspec:
Comme vous pouvez le voir, les sources et les tests se trouvent dans d'autres dossiers. Transférez les fichiers et testez le projet d'exemple Cocoapods.
Nous ajoutons la plateforme de développement à Package.swift et transférons les dépendances à partir du fichier podspec ici. Nous nous assurons qu'ils prennent en charge SPM: vérifiez simplement qu'il existe un fichier Package.swift dans Github. S'il n'est pas là et qu'il n'y a même pas de RP avec lui, nous ferons un PR et aiderons la communauté Open-Source.
Pour SPM, vous n'avez pas besoin de créer un projet exemple: ouvrez simplement Package.swift dans Xcode et il téléchargera et connectera les dépendances, créera les cibles selon nos spécifications. Nous ne pouvons que courir.
Dans notre cas, presque tout a fonctionné hors de la boîte, à l'exception d'un endroit où l'importation Foundation a oublié: les développeurs iOS sont habitués au fait que UIKit et Foundation sont facultatifs, car cela fonctionne sans eux. Il est temps de désapprendre cette habitude.
Le package se compile, les tests se compilent, mais échouent.
Et là, nous rencontrons une limitation du manque de ressources dans Package, les tests sont basés sur les moks qui se trouvent dans json, nous attendons SE-0271 ...Total
Passer des Cocoapods à SPM est facile. Les étapes sont claires, mais le flux est monotone et nécessite une automatisation.Sans trop d'efforts, vous pouvez créer un package à partir du fichier .podspec et le valider dans le référentiel. Et le plus important - vous pouvez vous déplacer avec un projet, et l'autre restera sur Cocoapods. S'il le veut, bien sûr.