Комментарии 5
Я правильно понял, что у вас разные модули iOS-приложения лежат в разных git-репозиториях?
Если да, то плюсов у этого решения не то что бы много, зато неудобств столько, что борьба с ними занимает полстатьи. В монорепозитории как минимум можно было бы не думать о версионировании, а Cocoapods бы завёлся с первой попытки.
Однако, тут возникают свои проблемы - Cocoapods (как и SPM и даже Carthage) плохо умеет в кэширование модулей между машинами разработчиков, поэтому начиная с определенного размера приложения и команды они перестают скейлится (из-за времени чистой сборки). Я видел, что в такой ситуации обычно переходят на более высокоуровневые сборочные системы (Buck, Bazel, Tuist). Не рассматривали такие?
Да, часть модулей находится в выделенных репозиториях. Это необходимо для переиспользования библиотек между приложениями. Да к сожалению мультирепа дает неудобства в виде контроля версионирования, но это палка с двумя концами, где на втором конце это контроль кода и разделение на домены. Поэтому тут нельзя дать однозначно верного ответа, к сожалению “depends on”. Если только одно приложение, то конечно проще будет использовать монорепу.
Мы не выносим все модули в отдельные репозитории, но оставляем такую возможность в будущем. По поводу того что поды заведутся в монорепе легко - да. В целом это простая альтернатива для модульности по сравнению с модулями на хкод проектах. На самом деле и SPM хорошо работает в монорепе, только есть другие проблемы, с которыми мы как раз и сталкивались.
По поводу Bazel и прочих, нет не пробовал, даже на маленьком тестовом проекте. Возможно углубившись подумаем над переходом, но что-то подобное должно произойти в будущем, либо SPM станет настолько же крутым 😁.
Для сокращения времени сборки думаю можно использовать любой из менеджеров который позволяет использовать скомпилированные библиотеки, то биш бинари. А для быстрых локальных правок должна быть возможность переключения между использованием готового бинаря и компилируемого локального кода. Как конкретно это можно сделать пока не знаю, но навскидку кажется выполнимой задачей.
Также для косвенного сокращения чистой сборки можно не держать одно большое приложение. Как я писал в статье у нас деление на продуктовые модули и для каждого модуля есть свое демо приложение, которое компилируется гораздо быстрее в тестовом энвайроменте. Чаще всего мы ведем разработку в них, нежели в основном приложении, но да, проблема скорости компиляции всего приложения никуда не уходит 🙂
Прочитал всю статью с интересом. Напомнило мне времена когда многие начинали использовать swift 2.0 (ведь модно!) но на практике баги были в самом языке. :) что-то подобное например прикрутить будет в spm не так легко, как в подах: https://habr.com/ru/post/674550/
Спасибо. Была бы необходимость, реализация не заставит ждать 😄
У Cocoapods насколько помню в подспеках можно указывать лицензию, благодаря этому можно с небольшими усилиями написать даже свой парсер. А вот у SPM такого свойства нет, ничего лишнего, только код 🙂
Кажется, что одно из перечисленных приложений (или даже оба) должно справиться с этим:
1. https://github.com/nicklockwood/Tribute
2. https://github.com/carloe/LicenseGenerator-iOS
Приключение на 5 минут: как мы переводили все зависимости на SPM