Cocoapods é considerado o gerenciador de dependência mais popular para iOS. Nos últimos anos, a Apple tem trabalhado no desenvolvimento de seu gerenciador de dependência nativo Swift Package Manager (SPM).Inicialmente, seu uso era possível apenas para aplicativos Swift ou de terminal do lado do servidor. O SPM foi executado e modificado nesses aplicativos, a comunidade se familiarizou com seu trabalho e a equipe da Apple recebeu testadores beta.Com o lançamento do Xcode 11, o SPM começou a entrar no mundo do desenvolvimento para iOS. Agora já é uma ferramenta completa que pode ser usada, mas até agora com limitações.Na versão atual, o SPM não suporta recursos (estamos aguardando o SE-0271 ). Em nosso país, cada módulo é uma dependência auto-suficiente atômica que pode ser conectada ao projeto, portanto, são necessários recursos (localização, ativos).Enquanto isso, podemos nos preparar para a migração: para entender como é difícil, se pode ser automatizado e quais problemas você pode encontrar.Por que migrar do Cocoapods para o SPM?
- Natividade e integração no ecossistema. O Xcode já está propondo criar ou adicionar um pacote SPM.
- Ao contrário dos Cocoapods, não é mais necessário ter um espaço de trabalho para trabalhar em um projeto de dependência.
- Depois de adicionar uma nova dependência, você não precisa instalar o pod e reconstruir todo o projeto.
- É conveniente usar dependências locais: a estrutura da pasta não muda, é reconstruída mais rapidamente.
- SPM , Cocoapods, Ruby ( iOS-).
- Cocoapods Xcode Swift.
- Example : Xcode Package.swift .
- abstract_target: SPM .
- blame , .
- Ruby, .
?
Se o seu projeto tiver muitas dependências, o processo de migração não poderá ser concluído em um dia. O número de dependências no Podfile não é igual ao número total de dependências, pois uma dependência pode vir com mais dez. Mesmo se você não tiver muitas dependências, mas desenvolver suas dependências, é possível, mesmo em repositórios particulares, não migrar rapidamente. Felizmente, o SPM se dá bem com os Cocoapods, e o processo de migração pode ser iterado. O principal é levar em conta as nuances:- Não deve haver interseções entre as dependências SPM e Cocoapods.
- A migração deve ser integrada ao processo de desenvolvimento de componentes. Se o componente estiver em desenvolvimento, uma atualização de versão deve ser realizada para os Cocoapods e o SPM.
- Não deve haver dificuldades para a equipe, o que significa que você precisa implementar a instalação de todas as dependências por meio de um único comando cli.
- A migração deve ser incorporada ao CD do IC. O projeto deve ser construído localmente e em agentes de IC, em todas as configurações.
Por onde começar?
Primeiro, coletamos uma lista completa de suas dependências - é apresentada em Podfile.lock. Você pode usar utilitários como o SPMReady .
Em seguida, agrupamos-os por relacionamento. Por exemplo, quase todos os componentes dependem do SMENetwork, o que significa que não poderemos migrá-los para o SPM até que o próprio SMENetwork migre.Em seguida, selecionamos um módulo, do qual a maioria dos módulos depende - SMENetwork.Por fim, vá para o repositório deste módulo, verifique-o em uma pasta e crie um módulo na raiz desta pasta.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, obtemos o arquivo Package.swift principal e as pastas Fontes e Testes. Se você já os teve, eles não trituram. Os arquivos SMENetwork.swift, SMENetworkTests.swift, XCTestManifests.swift, LinuxMain.swift foram criados para o exemplo de operação Package, eles podem ser excluídos.O arquivo Package.swift se parece com o seguinte:
Agora, vejamos o arquivo SMENetwork.podspec:
Como você pode ver, Fontes e testes estão em outras pastas. Transfira os arquivos e teste o projeto Cocoapods Example.
Adicionamos a plataforma de desenvolvimento ao Package.swift e transferimos as dependências do arquivo podspec aqui. Garantimos que eles suportam o SPM: verifique se há um arquivo Package.swift no Github. Se ele não estiver lá e nem houver um PR com ele, faremos um PR e ajudaremos a comunidade de código aberto.
Para o SPM, você não precisa criar um projeto de Exemplo: basta abrir o Package.swift no Xcode e ele fará o download e conectará as dependências, criará os destinos de acordo com nossa especificação. Nós podemos apenas correr.
No nosso caso, quase tudo funcionou imediatamente, com exceção de um lugar onde o Import Foundation esqueceu: os desenvolvedores do iOS estão acostumados ao fato de que o UIKit e o Foundation são opcionais, porque funciona sem eles. É hora de desaprender esse hábito.
Compilação de pacotes, compilação de testes, mas falha.
E aqui encontramos uma limitação da falta de recursos no Package, os testes são baseados nos moks que estão no json, estamos aguardando o SE-0271 ...Total
Mudar de Cocoapods para SPM é fácil. As etapas são claras, mas o fluxo é monótono e requer automação.Sem muito esforço, você pode criar um pacote a partir do arquivo .podspec e enviá-lo para o repositório. E o mais importante - você pode avançar com um projeto e o outro permanecerá no Cocoapods. Se ele quiser, é claro.