Спасибо. Была бы необходимость, реализация не заставит ждать ?
У Cocoapods насколько помню в подспеках можно указывать лицензию, благодаря этому можно с небольшими усилиями написать даже свой парсер. А вот у SPM такого свойства нет, ничего лишнего, только код ?
Да, часть модулей находится в выделенных репозиториях. Это необходимо для переиспользования библиотек между приложениями. Да к сожалению мультирепа дает неудобства в виде контроля версионирования, но это палка с двумя концами, где на втором конце это контроль кода и разделение на домены. Поэтому тут нельзя дать однозначно верного ответа, к сожалению “depends on”. Если только одно приложение, то конечно проще будет использовать монорепу.
Мы не выносим все модули в отдельные репозитории, но оставляем такую возможность в будущем. По поводу того что поды заведутся в монорепе легко - да. В целом это простая альтернатива для модульности по сравнению с модулями на хкод проектах. На самом деле и SPM хорошо работает в монорепе, только есть другие проблемы, с которыми мы как раз и сталкивались.
По поводу Bazel и прочих, нет не пробовал, даже на маленьком тестовом проекте. Возможно углубившись подумаем над переходом, но что-то подобное должно произойти в будущем, либо SPM станет настолько же крутым ?.
Для сокращения времени сборки думаю можно использовать любой из менеджеров который позволяет использовать скомпилированные библиотеки, то биш бинари. А для быстрых локальных правок должна быть возможность переключения между использованием готового бинаря и компилируемого локального кода. Как конкретно это можно сделать пока не знаю, но навскидку кажется выполнимой задачей.
Также для косвенного сокращения чистой сборки можно не держать одно большое приложение. Как я писал в статье у нас деление на продуктовые модули и для каждого модуля есть свое демо приложение, которое компилируется гораздо быстрее в тестовом энвайроменте. Чаще всего мы ведем разработку в них, нежели в основном приложении, но да, проблема скорости компиляции всего приложения никуда не уходит ?
Спасибо. Была бы необходимость, реализация не заставит ждать ?
У Cocoapods насколько помню в подспеках можно указывать лицензию, благодаря этому можно с небольшими усилиями написать даже свой парсер. А вот у SPM такого свойства нет, ничего лишнего, только код ?
Да, часть модулей находится в выделенных репозиториях. Это необходимо для переиспользования библиотек между приложениями. Да к сожалению мультирепа дает неудобства в виде контроля версионирования, но это палка с двумя концами, где на втором конце это контроль кода и разделение на домены. Поэтому тут нельзя дать однозначно верного ответа, к сожалению “depends on”. Если только одно приложение, то конечно проще будет использовать монорепу.
Мы не выносим все модули в отдельные репозитории, но оставляем такую возможность в будущем. По поводу того что поды заведутся в монорепе легко - да. В целом это простая альтернатива для модульности по сравнению с модулями на хкод проектах. На самом деле и SPM хорошо работает в монорепе, только есть другие проблемы, с которыми мы как раз и сталкивались.
По поводу Bazel и прочих, нет не пробовал, даже на маленьком тестовом проекте. Возможно углубившись подумаем над переходом, но что-то подобное должно произойти в будущем, либо SPM станет настолько же крутым ?.
Для сокращения времени сборки думаю можно использовать любой из менеджеров который позволяет использовать скомпилированные библиотеки, то биш бинари. А для быстрых локальных правок должна быть возможность переключения между использованием готового бинаря и компилируемого локального кода. Как конкретно это можно сделать пока не знаю, но навскидку кажется выполнимой задачей.
Также для косвенного сокращения чистой сборки можно не держать одно большое приложение. Как я писал в статье у нас деление на продуктовые модули и для каждого модуля есть свое демо приложение, которое компилируется гораздо быстрее в тестовом энвайроменте. Чаще всего мы ведем разработку в них, нежели в основном приложении, но да, проблема скорости компиляции всего приложения никуда не уходит ?
Сейчас нет, но в скором времени будем пробовать переходить, и если столкнемся с кучей проблем напишем статью об этом ?
Обычные macmini. В офисе, настраивали силами разработчиков. На данный момент 2 машинки и еще пара штук на подходе.