# От Tuist v3 к v4 {#from-tuist-v3-to-v4}
С выходом [Tuist 4](https://github.com/tuist/tuist/releases/tag/4.0.0) мы
воспользовались возможностью внести в проект некоторые изменения, которые, по
нашему мнению, облегчат его использование и поддержку в долгосрочной
перспективе. В этом документе описаны изменения, которые необходимо внести в ваш
проект для перехода с Tuist 3 на Tuist 4.
### Отменено управление версиями через `tuistenv` {#dropped-version-management-through-tuistenv}
До Tuist 4 сценарий установки устанавливал инструмент `tuistenv`, который во
время установки переименовывался в `tuist`. Этот инструмент занимался установкой
и активацией версий Tuist, обеспечивая детерминизм в разных средах. С целью
сокращения функциональной поверхности Tuist мы решили отказаться от `tuistenv` в
пользу [Mise](https://mise.jdx.dev/), инструмента, который выполняет ту же
работу, но является более гибким и может быть использован в различных
инструментах. Если вы использовали `tuistenv`, вам придется удалить текущую
версию Tuist, выполнив `curl -Ls https://uninstall.tuist.io | bash`, а затем
установить ее, используя выбранный вами метод установки. Мы настоятельно
рекомендуем использовать Mise, поскольку он способен устанавливать и
активировать версии детерминированно в разных средах.
::: code-group
```bash [Uninstall tuistenv]
curl -Ls https://uninstall.tuist.io | bash
```
:::
::: предупреждение MISE в CI ENVIRONMENTS и XCODE PROJECTS
Если вы решили использовать детерминизм, который привносит Mise, мы рекомендуем
ознакомиться с документацией по использованию Mise в
[CI-средах](https://mise.jdx.dev/continuous-integration.html) и
[Xcode-проектах](https://mise.jdx.dev/ide-integration.html#xcode).
:::
::: инфо HOMEBREW IS SUPPORTED
Обратите внимание, что вы все еще можете установить Tuist с помощью Homebrew -
популярного менеджера пакетов для macOS. Инструкции по установке Tuist с помощью
Homebrew вы найдете в руководстве по установке
.
:::
### Удалены конструкторы `unit` из моделей `ProjectDescription` {#dropped-init-constructors-from-projectdescription-models}
С целью улучшения читабельности и выразительности API мы решили удалить
конструкторы `init` из всех моделей `ProjectDescription`. Теперь каждая модель
предоставляет статический конструктор, который вы можете использовать для
создания экземпляров моделей. Если вы использовали конструкторы `init`, вам
придется обновить свой проект, чтобы использовать вместо них статические
конструкторы.
::: tip NAMING CONVENTION
В качестве имени статического конструктора мы используем имя модели. Например,
статический конструктор для модели `Target` имеет имя `Target.target`.
:::
### Переименовали `--no-cache` в `--no-binary-cache` {#renamed-nocache-to-nobinarycache}
Поскольку флаг `--no-cache` был неоднозначным, мы решили переименовать его в
`--no-binary-cache`, чтобы было понятно, что он относится к двоичному кэшу. Если
вы использовали флаг `--no-cache`, вам придется обновить свой проект, чтобы
вместо него использовать флаг `--no-binary-cache`.
### Переименовать `tuist fetch` в `tuist install` {#renamed-tuist-fetch-to-tuist-install}
Мы переименовали команду `tuist fetch` в `tuist install`, чтобы привести ее в
соответствие с отраслевой конвенцией. Если вы использовали команду `tuist
fetch`, вам придется обновить свой проект, чтобы вместо нее использовать команду
`tuist install`.
### [Принять `Package.swift` в качестве DSL для зависимостей] (https://github.com/tuist/tuist/pull/5862) {#adopt-packageswift-as-the-dsl-for-dependencieshttpsgithubcomtuisttuistpull5862}
До появления Tuist 4 вы могли определять зависимости в файле
`Dependencies.swift`. Этот проприетарный формат нарушал поддержку
автоматического обновления зависимостей в таких инструментах, как
[Dependabot](https://github.com/dependabot) или
[Renovatebot](https://github.com/renovatebot/renovate). Кроме того, он вводил
ненужные перенаправления для пользователей. Поэтому мы решили принять
`Package.swift` в качестве единственного способа определения зависимостей в
Tuist. Если вы использовали файл `Dependencies.swift`, вам придется перенести
содержимое файла `Tuist/Dependencies.swift` в корневой файл `Package.swift` и
использовать директиву `#if TUIST` для настройки интеграции. Подробнее о том,
как интегрировать зависимости Swift Package
, вы можете прочитать здесь
### Переименование `tuist cache warm` в `tuist cache` {#renamed-tuist-cache-warm-to-tuist-cache}
Для краткости мы решили переименовать команду `tuist cache warm` в `tuist
cache`. Если вы использовали команду `tuist cache warm`, вам придется обновить
свой проект, чтобы вместо нее использовать команду `tuist cache`.
### Переименовали `tuist cache print-hashes` в `tuist cache --print-hashes` {#renamed-tuist-cache-printhashes-to-tuist-cache-printhashes}
Мы решили переименовать команду `tuist cache print-hashes` в `tuist cache
--print-hashes`, чтобы было понятно, что это флаг команды `tuist cache`. Если вы
использовали команду `tuist cache print-hashes`, вам придется обновить свой
проект, чтобы вместо нее использовать флаг `tuist cache --print-hashes`.
### Удаленные профили кэширования {#removed-caching-profiles}
До появления Tuist 4 вы могли определять профили кэширования в файле
`Tuist/Config.swift`, который содержал конфигурацию для кэша. Мы решили убрать
эту возможность, потому что она могла привести к путанице при использовании в
процессе генерации профиля, отличного от того, который был использован при
генерации проекта. Кроме того, это могло привести к тому, что пользователи могли
использовать отладочный профиль для сборки релизной версии приложения, что могло
привести к неожиданным результатам. Вместо этого мы ввели опцию
`--configuration`, с помощью которой вы можете указать конфигурацию, которую
хотите использовать при генерации проекта. Если вы использовали профили
кэширования, вам придется обновить свой проект, чтобы вместо них использовать
опцию `--configuration`.
### Удалено `--skip-cache` в пользу аргументов {#removed-skipcache-in-favor-of-arguments}
Мы удалили флаг `--skip-cache` из команды `generate` в пользу управления тем,
для каких целей следует пропускать бинарный кэш, с помощью аргументов. Если вы
использовали флаг `--skip-cache`, вам придется обновить свой проект, чтобы
использовать аргументы вместо него.
::: code-group
```bash [Before]
tuist generate --skip-cache Foo
```
```bash [After]
tuist generate Foo
```
:::
### [Удалены возможности подписи](https://github.com/tuist/tuist/pull/5716) {#dropped-signing-capabilitieshttpsgithubcomtuisttuistpull5716}
Проблема подписи уже решена такими инструментами сообщества, как
[Fastlane](https://fastlane.tools/) и сам Xcode, которые справляются с этой
задачей гораздо лучше. Мы посчитали, что подписывать сертификаты для Tuist - это
нецелевая задача, и лучше сосредоточиться на основных возможностях проекта. Если
вы использовали возможности подписи Tuist, которые заключались в шифровании
сертификатов и профилей в репозитории и установке их в нужные места во время
генерации, вы можете захотеть повторить эту логику в своих собственных скриптах,
запускаемых перед генерацией проекта. В частности:
- Сценарий, который расшифровывает сертификаты и профили с помощью ключа,
хранящегося либо в файловой системе, либо в переменной окружения, и
устанавливает сертификаты в связку ключей, а профили инициализации - в
каталог `~/Library/MobileDevice/Provisioning\ Profiles`.
- Сценарий, который может взять существующие профили и сертификаты и
зашифровать их.
::: РЕКОМЕНДАЦИИ ПО ПОДПИСКЕ
Подписание требует наличия нужных сертификатов в связке ключей и профилей
инициализации в каталоге `~/Library/MobileDevice/Provisioning\ Profiles`. Для
установки сертификатов в связку ключей можно использовать инструмент командной
строки `security`, а для копирования профилей предоставления в нужный каталог -
команду `cp`.
:::
### Убрали интеграцию Карфагена через `Dependencies.swift` {#dropped-carthage-integration-via-dependenciesswift}
До 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 {#dropped-the-targetdependencypackageplugin-api}
До появления Tuist 4 вы могли определить зависимость от плагина пакета,
используя случай `TargetDependency.packagePlugin`. После того как в менеджере
пакетов Swift появились новые типы пакетов, мы решили доработать API до более
гибкого и перспективного. Если вы использовали `TargetDependency.packagePlugin`,
то вместо этого вам придется использовать `TargetDependency.package`, а в
качестве аргумента передать тип пакета, который вы хотите использовать.
### [Удалены устаревшие API](https://github.com/tuist/tuist/pull/5560) {#dropped-deprecated-apishttpsgithubcomtuisttuistpull5560}
Мы удалили API, которые были помечены как устаревшие в Tuist 3. Если вы
использовали какой-либо из устаревших API, вам придется обновить свой проект,
чтобы использовать новые API.