От Tuist v3 к v4

С выходом Tuist 4 мы воспользовались возможностью внести в проект некоторые изменения, которые, по нашему мнению, облегчат его использование и поддержку в долгосрочной перспективе. В этом документе описаны изменения, которые необходимо внести в ваш проект для перехода с Tuist 3 на Tuist 4.

Отменено управление версиями через tuistenv

До Tuist 4 сценарий установки устанавливал инструмент tuistenv, который во время установки переименовывался в tuist. Этот инструмент занимался установкой и активацией версий Tuist, обеспечивая детерминизм в разных средах. С целью сокращения функциональной поверхности Tuist мы решили отказаться от tuistenv в пользу Mise, инструмента, который выполняет ту же работу, но является более гибким и может быть использован в различных инструментах. Если вы использовали tuistenv, вам придется удалить текущую версию Tuist, выполнив curl -Ls https://uninstall.tuist.io | bash, а затем установить ее, используя выбранный вами метод установки. Мы настоятельно рекомендуем использовать Mise, поскольку он способен устанавливать и активировать версии детерминированно в разных средах.

Uninstall tuistenv

curl -Ls https://uninstall.tuist.io | bash

MISE в CI ENVIRONMENTS и XCODE PROJECTS

Если вы решили использовать детерминизм, который привносит Mise, мы рекомендуем ознакомиться с документацией по использованию Mise в CI-средах и Xcode-проектах.

::: инфо HOMEBREW IS SUPPORTED

Обратите внимание, что вы все еще можете установить Tuist с помощью Homebrew - популярного менеджера пакетов для macOS. Инструкции по установке Tuist с помощью Homebrew вы найдете в руководстве по установке

.

:::

Dropped init constructors from ProjectDescription models

С целью улучшения читабельности и выразительности API мы решили удалить конструкторы init из всех моделей ProjectDescription. Теперь каждая модель предоставляет статический конструктор, который вы можете использовать для создания экземпляров моделей. Если вы использовали конструкторы init, вам придется обновить свой проект, чтобы использовать вместо них статические конструкторы.

NAMING CONVENTION

В качестве имени статического конструктора мы используем имя модели. Например, статический конструктор для модели Target имеет имя Target.target.

Переименовали --no-cache в --no-binary-cache

Поскольку флаг --no-cache был неоднозначным, мы решили переименовать его в --no-binary-cache, чтобы было понятно, что он относится к двоичному кэшу. Если вы использовали флаг --no-cache, вам придется обновить свой проект, чтобы вместо него использовать флаг --no-binary-cache.

Переименовать tuist fetch в tuist install

Мы переименовали команду tuist fetch в tuist install, чтобы привести ее в соответствие с отраслевой конвенцией. Если вы использовали команду tuist fetch, вам придется обновить свой проект, чтобы вместо нее использовать команду tuist install.

[Принять Package.swift в качестве DSL для зависимостей] (https://github.com/tuist/tuist/pull/5862)

До появления Tuist 4 вы могли определять зависимости в файле Dependencies.swift. Этот проприетарный формат нарушал поддержку автоматического обновления зависимостей в таких инструментах, как Dependabot или Renovatebot. Кроме того, он вводил ненужные перенаправления для пользователей. Поэтому мы решили принять Package.swift в качестве единственного способа определения зависимостей в Tuist. Если вы использовали файл Dependencies.swift, вам придется перенести содержимое файла Tuist/Dependencies.swift в корневой файл Package.swift и использовать директиву #if TUIST для настройки интеграции. Подробнее о том, как интегрировать зависимости Swift Package

, вы можете прочитать здесь

Переименование tuist cache warm в tuist cache

Для краткости мы решили переименовать команду tuist cache warm в tuist cache. Если вы использовали команду tuist cache warm, вам придется обновить свой проект, чтобы вместо нее использовать команду tuist cache.

Переименовали tuist cache print-hashes в tuist cache --print-hashes

Мы решили переименовать команду tuist cache print-hashes в tuist cache --print-hashes, чтобы было понятно, что это флаг команды tuist cache. Если вы использовали команду tuist cache print-hashes, вам придется обновить свой проект, чтобы вместо нее использовать флаг tuist cache --print-hashes.

Удаленные профили кэширования

До появления Tuist 4 вы могли определять профили кэширования в файле Tuist/Config.swift, который содержал конфигурацию для кэша. Мы решили убрать эту возможность, потому что она могла привести к путанице при использовании в процессе генерации профиля, отличного от того, который был использован при генерации проекта. Кроме того, это могло привести к тому, что пользователи могли использовать отладочный профиль для сборки релизной версии приложения, что могло привести к неожиданным результатам. Вместо этого мы ввели опцию --configuration, с помощью которой вы можете указать конфигурацию, которую хотите использовать при генерации проекта. Если вы использовали профили кэширования, вам придется обновить свой проект, чтобы вместо них использовать опцию --configuration.

Удалено --skip-cache в пользу аргументов

Мы удалили флаг --skip-cache из команды generate в пользу управления тем, для каких целей следует пропускать бинарный кэш, с помощью аргументов. Если вы использовали флаг --skip-cache, вам придется обновить свой проект, чтобы использовать аргументы вместо него.

Before

tuist generate --skip-cache Foo

After

tuist generate Foo

Dropped signing capabilities

Проблема подписи уже решена такими инструментами сообщества, как Fastlane и сам Xcode, которые справляются с этой задачей гораздо лучше. Мы посчитали, что подписывать сертификаты для Tuist - это нецелевая задача, и лучше сосредоточиться на основных возможностях проекта. Если вы использовали возможности подписи Tuist, которые заключались в шифровании сертификатов и профилей в репозитории и установке их в нужные места во время генерации, вы можете захотеть повторить эту логику в своих собственных скриптах, запускаемых перед генерацией проекта. В частности:

• Сценарий, который расшифровывает сертификаты и профили с помощью ключа, хранящегося либо в файловой системе, либо в переменной окружения, и устанавливает сертификаты в связку ключей, а профили инициализации - в каталог ~/Library/MobileDevice/Provisioning\ Profiles.
• Сценарий, который может взять существующие профили и сертификаты и зашифровать их.

::: РЕКОМЕНДАЦИИ ПО ПОДПИСКЕ

Подписание требует наличия нужных сертификатов в связке ключей и профилей инициализации в каталоге ~/Library/MobileDevice/Provisioning\ Profiles. Для установки сертификатов в связку ключей можно использовать инструмент командной строки security, а для копирования профилей предоставления в нужный каталог - команду cp.

:::

Убрали интеграцию Карфагена через Dependencies.swift

До Tuist 4 зависимости Carthage можно было определить в файле Dependencies.swift, который пользователи могли получить, выполнив команду tuist fetch. Мы также посчитали, что это является растяжимой целью для Tuist, особенно учитывая будущее, в котором Swift Package Manager будет предпочтительным способом управления зависимостями. Если вы использовали зависимости Carthage, вам придется использовать Carthage непосредственно для извлечения предварительно скомпилированных фреймворков и XCFrameworks в стандартный каталог Carthage, а затем ссылаться на эти двоичные файлы из ваших тегов, используя случаи TargetDependency.xcframework и TargetDependency.framework.

::: инфо КАРТАЖ ОСТАЕТСЯ ПОДДЕРЖКОЙ

Некоторые пользователи поняли, что мы отказались от поддержки Carthage. Это не так. Контракт между Tuist и выходом Carthage распространяется на фреймворки, хранящиеся в системе, и XCFrameworks. Единственное, что изменилось, - это то, кто отвечает за получение зависимостей. Раньше это был Tuist через Carthage, теперь - Carthage.

:::

Удален TargetDependency.packagePlugin API

До появления Tuist 4 вы могли определить зависимость от плагина пакета, используя случай TargetDependency.packagePlugin. После того как в менеджере пакетов Swift появились новые типы пакетов, мы решили доработать API до более гибкого и перспективного. Если вы использовали TargetDependency.packagePlugin, то вместо этого вам придется использовать TargetDependency.package, а в качестве аргумента передать тип пакета, который вы хотите использовать.

Dropped deprecated APIs

Мы удалили API, которые были помечены как устаревшие в Tuist 3. Если вы использовали какой-либо из устаревших API, вам придется обновить свой проект, чтобы использовать новые API.