Лучший код WordPress: файл блокировки Composer
Прежде чем завершить обсуждение Composer, нам осталось обсудить одну важную вещь: каталог поставщика (и, соответственно, файл блокировки Composer).
В частности, нам нужно поговорить о том, почему нам не нужно передавать каталог поставщика в репозиторий, а о том, как наши участники могут быть уверены, что у них есть последняя версия программного обеспечения, необходимого для работы с нашей кодовой базой.
Да, использование инструментов качества кода для написания лучшего кода WordPress важно, но также важно понимать, как правильно управлять зависимостями и нашим репозиторием. Итак, прежде чем рассматривать указанные утилиты, давайте рассмотрим файл блокировки, роль, которую он играет, и почему нам не нужно фиксировать каталог поставщика в нашем репозитории.
Лучший код WordPress с файлом блокировки Composer
Для тех, кто работает с WordPress — и, возможно, с другими фреймворками и платформами на основе PHP (я действительно не знаю, так как обычно не работаю с ними) — есть зависимость от Composer, и это хорошо.
Это также может привести к желанию зафиксировать весь исходный контроль каталога поставщика, что не очень хорошо.
Как упоминалось в предыдущем посте :
И я не рекомендую проверять каталог поставщика в вашем репозитории. Позже это может превратиться в огромный каталог и подорвать всю цель Composer.
Итак, как мы можем убедиться, что мы не передаем файлы без необходимости (и, таким образом, увеличивая размер нашего репозитория) в репозиторий все время, следя за тем, чтобы наши участники использовали ту же версию программного обеспечения, что и мы?
Желание зафиксировать каталог поставщиков
Для тех из вас, кто запускал Composer и знаком, по крайней мере, с каталогом поставщика, вы, вероятно, привыкли видеть несколько установленных каталогов зависимостей.
И они полезны; иначе вы бы их не включили, верно?
Но вот что касается каталога поставщика : даже если у вас установлено всего несколько зависимостей вместе с вашим проектом, сам размер файла может быть большим. И это может быть еще больше, когда у вас много зависимостей.
Тем не менее, передача этого в систему контроля версий имеет смысл, верно? Мы хотим убедиться, что у всех есть та же версия программного обеспечения, которую мы используем, и мы хотим убедиться, что им не приходится иметь дело с Composer.
Хотя есть и другой способ. И это сохраняет наш репозиторий небольшим, а также гарантирует, что версии наших зависимостей синхронизируются с теми, кто клонирует репозиторий, фиксирует в репозитории или для любой утилиты непрерывной интеграции, которая использует репозиторий.
Понимание файла блокировки
Прежде чем говорить о каталоге поставщика, я хочу коснуться еще одного важного аспекта Composer: файла блокировки. То есть, если вы запустите команду установки или обновления в своем терминале, вы увидите файл блокировки, сгенерированный вместе с каталогом поставщика .
Что это за файл?
В предыдущем посте был показан пример файла конфигурации. Одна из вещей, которую этот файл также позволяет нам делать, — это определять сторонние библиотеки или зависимости, которые мы можем использовать в наших проектах.
Я говорил об этом в других сообщениях (и мы можем рассмотреть это немного позже в этой серии). Но здесь в игру вступает файл блокировки.
Короче говоря, файл блокировки всегда содержит информацию о версии — точной версии — зависимостей, которые использовались с проектом при последнем запуске установки или обновления .
Когда Composer завершает установку, он записывает все пакеты и их точные версии, которые он загрузил, в файл composer.lock, блокируя проект для этих конкретных версий.
Вы должны зафиксировать файл composer.lock в репозитории вашего проекта, чтобы все люди, работающие над проектом, были привязаны к одним и тем же версиям зависимостей (подробнее ниже).
Цель состоит в том, чтобы убедиться, что все используют одну и ту же версию зависимостей проекта — не старые версии, не новые версии — а одну и ту же версию.
Таким образом, когда вы запускаете composer install, когда файл блокировки включен в репозиторий, будет использоваться версия программного обеспечения, указанная в файле блокировки.
И это гарантирует, что все используют одну и ту же версию каждой зависимости, и, таким образом, может предотвратить необходимость фиксации каталога поставщика в системе управления версиями.
Написание более качественного кода
Так куда мы идем отсюда?
Теперь, когда мы понимаем, как использовать Composer и как использовать файл блокировки, мы можем начать говорить о фактических зависимостях, которые помогают улучшить качество нашего кода.
И когда мы говорим о написании более качественного кода, существуют утилиты, созданные именно для этого. Поэтому в следующих нескольких постах мы рассмотрим некоторые из них.