Хранил ли пакеты локально

Хранение пакетов локально в Unity

Да, я регулярно храню пакеты локально в своих проектах, и это является критически важной частью рабочего процесса. Unity предлагает несколько подходов для локального хранения пакетов, и их использование зависит от контекста проекта, требований к стабильности и необходимости изоляции от внешних репозиториев.

Зачем хранить пакеты локально?

• Стабильность сборок: Локальные пакеты гарантируют, что все члены команды используют идентичные версии зависимостей, исключая риск поломки из-за обновлений в удалённом репозитории.
• Работа в оффлайне: Разработка возможна без постоянного доступа к интернету или внутреннему серверу пакетов.
• Контроль и безопасность: Полный контроль над используемым кодом, что важно для проприетарных или сильно модифицированных пакетов. Снижение рисков, связанных с недоступностью packages.unity.com или удалением пакета автором.
• Кастомизация: Возможность быстро вносить изменения в локальную копию пакета для отладки или добавления специфичного для проекта функционала и сразу тестировать их.

Основные способы локального хранения

1. Использование локального пути в manifest.json

Самый прямой метод — указать путь к папке с пакетом на диске в файле Packages/manifest.json. Unity будет рассматривать эту папку как пакет.

{
  "dependencies": {
    "com.company.local-package": "file:../LocalPackages/com.company.local-package",
    "com.unity.render-pipelines.universal": "12.1.7"
  }
}

Преимущество: Максимальная скорость итерации, изменения в папке пакета мгновенно видны в проекте.
Недостаток: Путь абсолютный или относительный, что может вызвать проблемы при перемещении проекта между компьютерами без дополнительной настройки.

2. Локальный сервер пакетов (Scoped Registry)

Более масштабируемое решение — развернуть локальный сервер пакетов (например, upm или GitLab Package Registry). В manifest.json добавляется Scoped Registry, указывающий на этот сервер.

{
  "scopedRegistries": [
    {
      "name": "My Local Registry",
      "url": "http://localhost:4873",
      "scopes": [
        "com.company"
      ]
    }
  ],
  "dependencies": {
    "com.company.shared-tools": "1.0.0",
    "com.unity.ugui": "1.0.0"
  }
}

Преимущество: Централизованное управление версиями пакетов для всей команды, семантическое версионирование.
Недостаток: Требует настройки и поддержки сервера.

3. Git-репозиторий как пакет (Git URL)

Хотя этот метод использует удалённый Git, он часто применяется для хранения "локальных" для компании пакетов в приватном репозитории. По сути, это ваш собственный удалённый, но контролируемый источник.

{
  "dependencies": {
    "com.company.network-module": "git+ssh://git@my-git-server.com:company/network-module.git#v2.5",
    "com.company.utility": "git+https://my-git-server.com/company/utilities.git#release/stable"
  }
}

Преимущество: Встроенный контроль версий через Git, привычный workflow для разработчиков.
Недостаток: Зависит от доступности Git-сервера, может быть медленнее локального пути.

Мой стандартный рабочий процесс

В типичном проекте я комбинирую подходы:

1. Для активной разработки общего модуля (например, CoreGameplay) используется file: ссылка из папки проекта ../CoreModules/CoreGameplay. Это позволяет вести параллельную разработку и мгновенно тестировать изменения.
2. Для стабильных внутренних библиотек (UI Framework, Save System) используется локальный npm-сервер. После тестирования и версионирования пакет публикуется туда, и команда подключает его по версии ("com.company.ui-framework": "3.2.0").
3. Для публичных пакетов Unity и сторонних зависимостей используется встроенный Registry (packages.unity.com) с фиксацией конкретной версии в manifest.json.

Важные практики

• .gitignore: Папки локальных пакетов, подключённых через file:, обычно не добавляются в репозиторий основного проекта. Версионируется только их исходный код в отдельном репозитории.
• Резервное копирование: Локальные папки с пакетами должны быть частью стратегии бэкапов (через Git или иначе).
• Документация: В README.md проекта чётко указывается, как получить и расположить локальные пакеты перед первым открытием проекта.

Итог: Локальное хранение пакетов — это не просто техника, а стратегия обеспечения надёжности, повторяемости и контроля над зависимостями проекта. Прямое редактирование через file: путь незаменимо при разработке нескольких взаимосвязанных модулей, в то время как локальный сервер пакетов идеален для командной работы над стабильными библиотеками.