# Переход с 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
```
<!-- -->
:::

> [!WARNING]
> **Mise в CI-средах и проектах Xcode**
>
> Если вы решите воспользоваться детерминированностью, которую обеспечивает Mise повсеместно, рекомендуем ознакомиться с документацией по использованию Mise в [CI-средах](https://mise.jdx.dev/continuous-integration.html) и [проектах Xcode](https://mise.jdx.dev/ide-integration.html#xcode).


> [!NOTE]
> **Поддержка Homebrew**
>
> Обратите внимание, что вы по-прежнему можете установить Tuist через Homebrew — популярный менеджер пакетов для macOS. Инструкции по установке Tuist с помощью Homebrew вы найдёте в <.localized_link href="/guides/install-tuist#alternative-homebrew">руководстве по установке</.localized_link>.


### Удалены конструкторы `init` из моделей `ProjectDescription` {#dropped-init-constructors-from-projectdescription-models}

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

> [!TIP]
> **Соглашение об именах**
>
> Мы следуем соглашению, согласно которому имя статического конструктора совпадает с именем модели. Например, статический конструктор для модели `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 читайте <.localized_link href="/guides/features/projects/dependencies#swift-packages">здесь</.localized_link>.

### Команда `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`.
  - Скрипт, который может взять существующие профили и сертификаты и зашифровать их.

> [!TIP]
> **Требования к подписи**
>
> Для подписи необходимо, чтобы нужные сертификаты присутствовали в связке ключей, а профили обеспечения — в каталоге `~/Library/MobileDevice/Provisioning\ Profiles`. Вы можете использовать утилиту командной строки `security` для установки сертификатов в связку ключей и команду `cp` для копирования профилей обеспечения в нужный каталог.


### Удалена интеграция Carthage через `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`.

> [!NOTE]
> **Carthage по-прежнему поддерживается**
>
> Некоторые пользователи решили, что мы отказались от поддержки Carthage. Это не так. Контракт между Tuist и выводом Carthage заключается в использовании системных фреймворков и XCFrameworks. Изменилось лишь то, кто отвечает за загрузку зависимостей. Раньше это делал Tuist через Carthage, теперь — сам Carthage.


### Удалён API `TargetDependency.packagePlugin` {#dropped-the-targetdependencypackageplugin-api}

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

### [Удалены устаревшие API](https://github.com/tuist/tuist/pull/5560) {#dropped-deprecated-apishttpsgithubcomtuisttuistpull5560}

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

Переход с 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, так как он позволяет детерминированно устанавливать и активировать версии в разных средах.

bash

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

Mise в CI-средах и проектах Xcode

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

Поддержка Homebrew

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

Удалены конструкторы `init` из моделей `ProjectDescription`#

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

Соглашение об именах

Мы следуем соглашению, согласно которому имя статического конструктора совпадает с именем модели. Например, статический конструктор для модели 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 для зависимостей#

До 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, вам нужно обновить проект, заменив его на аргументы.

bash

tuist generate --skip-cache Foo

bash

tuist generate Foo

Удалены возможности подписи#

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

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

Требования к подписи

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

Удалена интеграция Carthage через `Dependencies.swift`#

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

Carthage по-прежнему поддерживается

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

Удалён API `TargetDependency.packagePlugin`#

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

Удалены устаревшие API#

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