Модульная сборка проектовgears - минимальный менеджер зависимостей

Interlabs

20 августа 2014

1 / 22

Что мы хотим?

Единообразный подход к модульной сборке проектов:

• серверные модули на PHP• клиентские модули на JavaScript• стандартные таблицы стилей• фрагменты схем БД и т.д.

Для каждого типа модулей есть стандартные утилиты, можетиспользовать их?

2 / 22

Стандартные утилиты

Composer, Bower, Volo, Jam и т.д.

• ориентация на централизованные внешние реестры иgithub (большинство)

• сложность настройки частных репозиториев («вампонадобится CouchDB. . . » what??)

• невозможность использования ссылок наразрабатываемые модули (например, нет аналога npmlinks в composer)

• установка полной копии, избыточной для runtime (bower)• слишком много конфигурации

3 / 22

Наши потребности

• установка необходимого runtime-кода в проект• версионность, учет зависимостей• единое решение для серверных и клиентских модулей• адаптация под используемый нами инструментарий• возможность установки в проект произвольной структуры• гарантированная совместимость компонент между собой• минимум конфигурации

4 / 22

Что нам не важно

• взаимодействие со сторонними разработчиками(внутренняя платформа)

• интеграция с github• установка по сети — некритично, достаточно локальнойдоступности на сервере разработки

• избыточная конфигурируемость — лучше convention overconfiguration

• buzzword compatibility — нам ехать, а не шашечки

5 / 22

gears

• стандартный git-репозиторий используемых модулей• каждый модуль содержит только код, необходимый вruntime или для сборки runtime

• файлы модуля — подмножество файлов соответствующегопроекта, разработка модуля — в отдельном репозитории

• каждый модуль имеет версию, репозиторий определяетзависимости между версиями

• утилита командной строки для установки модулей сзависимостями

• использование симлинков при установке модулей в проект

6 / 22

Структура модуля

Метаданные:

package - краткое описание модуляmanifest - перечень устанавливаемых в проект файловLICENSE - текст лицензии модуляREADME.md - описание модуля

Каталоги с устанавливаемыми файлами:

js/ - модули JavaScriptcss/ - css, less или stylimg/ - стандартные изображенияtpl/ - PHP-шаблоныlib/ - PHP-классыfnt/ - шрифты

7 / 22

Версионность модулейКаждому модулю соответствует символическое имя:

jquery jquery-cycle2 bare

У каждого модуля есть версия:

jquery-1.11.1 jquery-cycle2-2.1.5 bare-0.2.0

Версия платформы устанавливает зависимости междуверсиями модулей:

jquery-cycle2: jquery jquery-cycle2-2.1.5jquery: jquery-1.11.1

8 / 22

Версионность платформы

• версия платформы определяется индекс-файлом,описывающим зависимости

• внутри одной версии платформы модули гарантированносовместимы

• появление новой версии платформы не отменяетсуществование предыдущих

• версия платформы может быть удалена, если не осталосьпроектов, использующих эту версию

• переход проекта на новую версию может потребоватьвнесение изменений в проект

9 / 22

Структура репозитория

.git/ git-репозиторийgears выполняемый файлpkg/

index-current.mk -> index-0.1.0.mk индекс по умолчаниюindex-0.1.0.mk индекс 0.1.0jquery-1.11.1/ модуль jquery

LICENSEmanifestpackageREADME.mdjs/

jquery.js устанавливаемый файлjquery-cycle2-2.1.5 плагин cycle2...

10 / 22

Требования к установкеМодули могут быть установлены в произвольный проект,поэтому:

• структура модуля не должна зависеть от структуры проекта• смена версии модуля не должна влиять на егоподключение в проекте

• модули могут быть легко переустановлены илиустановлены с нуля

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

• пути не должны зависеть от версий модулей

11 / 22

Установка в проект

• все модули устанавливаются в специальный выделенныйкаталог ext

• на файлы модулей создаются симлинки в других каталогахпроекта

• имя подкаталога модуля соответствует его полному именис номером версии

• симлинки в подкаталогах проекта — через промежуточныйсимлинк, соответствующий чистому имени модуля безверсии

12 / 22

Структура файлов проектаsrc/

js/jquery.js -> ../../ext/jquery/js/jquery.js

ext/jquery -> jquery-1.11.1/jquery-1.11.1/

js/jquery.js

font-pt-sans -> font-pt-sans-1.0.0font-pt-sans-1.0.0/

fnt/pt-sans-r400.eot...

www/fnt/

pt-sans -> ../../../ext/font-pt-sans/fnt

13 / 22

Установка в проект• используемые версии компонентов легко контролировать• промежуточный симлинк позволяет менять версию модулябез изменения симлинков в проекте

• для одновременной разработки модуля вместе с проектомможно использовать временный симлинк наразрабатываемую версию

• можно использовать PHP autoloader прямо из ext

А не слишком много симлинков?

• практически не влияют на производительность• симлинки в src не используются в runtime

14 / 22

Клиентские модулиПочему просто не использовать bower? Избыточность файлов иотсутствие адаптации под наши условия.

Адаптация:

• преобразование в формат AMD• исправление ошибок и реализация недостающегофункционала

• преобразование CSS в Stylus для параметризации ивключения в общую цепочку генерации CSS

• всегда включаем полную версию, минимизациявыполняется в проекте при сборке

• включаем только то, что необходимо в runtime

15 / 22

Серверные модули

Почему просто не использовать composer? Слишком многотелодвижений и сложность одновременной разработки модуляи проекта.

• PHP-классы + файлы шаблонов• используем стандартные autoload.php, не нужнодополнительно конфигурировать автозагрузчик

• не используем composer для установки в проект, что неотменяет возможность его использования внутри модуля

• каталог шаблонов включается в общую иерархиюшаблонов проекта

16 / 22

Серверные, клиентские . . .

Просто модули

• модуль может включать в себя файлы как для серверной,так и для клиентской части

• модуль — просто набор файлов, устанавливаемых постандартным правилам

17 / 22

Автоматизация установки# Установка из версии платформы current$ gears install jquery-cycle2 flight d3

# Установка из версии платформы 0.1.0$ GEARS_VERSION=0.1.0 gears install flight d3

# Автоматическая установка с помощью make.PHONY extexport GEARS_VERSION=0.1.0 # декларируем версию платформыDEPS=flight d3ext:

gears install $(DEPS)

make ext18 / 22

Использование репозитория

• должен ли проект строиться только из модулейрепозитория — нет

• накладывает ли использование репозитория ограниченияна структуру проекта — нет

• можно ли использовать непосредственно ссылки намодули репозитория — нет, за исключением случаевотладки

• должен ли ext включаться в git-репозиторий проекта —зависит от ситуации, можно не включать, еслинеобходимые модули могут быть установленыавтоматически

19 / 22

Поддержка репозитория

• необходимо периодически отслеживать новые версиимодулей сторонних разработчиков — да

• необходимо проверять совместимость новых версий врамках платформы — да

• кто поддерживает репозиторий — менеджер репозитория(один-два выделенных разработчика)

• когда — по необходимости + периодически (например,каждый месяц)

• новые модули — по запросу разработчиков проектов ибиблиотек

20 / 22

Что выигрываем

• переходим от разрозненных библиотек к единойкорпоративной платформе

• минимизируем зоопарк версий в проектах• стараемся использовать компоненты не из репозиториятолько если это действительно необходимо

• решаемые задачи относительно типовые — со временемрепозиторий перестает расти и содержит наборпроверенных типовых компонент

• максимально простая организация — не зависит отособенностей развития внешних инструментов

21 / 22

gearsprivate: https://bitbucket.org/interlabs/gears

22 / 22