Migrando do Cocoapods para o Swift Package Manager



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.

All Articles