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