modx-docker-minishop — сбора MiniShop3 в докере
modx-docker-minishop
modx-docker-minishop — рабочее название исследовательского направления внутри основного проекта modx-docker, посвящённого автоматической установке современного магазина на MODX 3 + pdoTools 3 + VueTools + MiniShop3 непосредственно из исходников.
Код эксперимента сейчас находится в ветке minishop3-native репозитория MODX-Club/modx-docker.
Важно: это пока research-версия, а не готовое стабильное решение. Сейчас прощупывается само направление: насколько удобно и надёжно собирать весь современный MiniShop-стек из Git-репозиториев, устанавливать его без ручной работы в Manager и использовать такой процесс как часть воспроизводимого runtime.
Зачем это исследуется
Обычная установка MODX хорошо решается самим modx-docker: нужная версия Revolution берётся из Git, устанавливаются Composer-зависимости, собирается core и выполняется unattended setup.
Но реальный современный магазин — это уже не только MODX. Минимальный стек включает несколько отдельных проектов:
MODX 3
+ pdoTools 3
+ VueTools
+ MiniShop3
Если ставить их вручную через Manager, теряется главное преимущество воспроизводимого окружения: новый проект уже нельзя полностью восстановить одной автоматической процедурой.
Исследовательская ветка проверяет другой подход:
Git source
→ native build
→ MODX transport package
→ native installation
То есть каждый компонент берётся непосредственно из его исходного репозитория, собирается штатными средствами самого проекта, после чего полученный transport package устанавливается через API MODX.
Текущий pipeline
Ветка minishop3-native расширяет базовую установку MODX ещё тремя стадиями:
01-07 обычная установка MODX
08 clone packages
09 build packages
10 install packages
В итоге процесс выглядит примерно так:
clone MODX
→ composer install
→ build MODX core
→ MODX CLI setup
→ clone pdoTools / VueTools / MiniShop3
→ build каждого компонента
→ получить .transport.zip
→ установить transport packages через MODX API
Это принципиально отличается от установки готовых пакетов из package provider: собирается именно текущее или выбранное состояние исходников.
Получение исходников компонентов
На стадии 08 создаётся отдельная директория _packages, куда клонируются репозитории компонентов.
Сейчас исследуется следующий набор:
pdoTools;VueTools;MiniShop3.
Идея состоит в том, что в дальнейшем для каждого компонента можно будет задавать конкретный Git ref: branch, tag или commit.
Тогда можно воспроизвести не абстрактный «последний MiniShop3», а точную комбинацию:
MODX <commit/ref>
pdoTools <commit/ref>
VueTools <commit/ref>
MiniShop3 <commit/ref>
Для разработки и отладки самой экосистемы это особенно ценно.
Нативная сборка компонентов
На стадии 09 каждый проект собирается собственным штатным build-процессом.
pdoTools 3
Для pdoTools используются Composer-зависимости и его собственный transport builder:
composer install
→ build.transport.php
→ pdotools-*.transport.zip
VueTools
VueTools содержит frontend-сборку, поэтому используется Node.js toolchain:
npm install
→ npm run build:all
→ PHP build script
→ vuetools-*.transport.zip
MiniShop3
MiniShop3 требует одновременно PHP- и frontend-сборку:
Composer dependencies
→ Vue Manager build
→ MiniShop3 build script
→ minishop3-*.transport.zip
Таким образом, modx-docker не пытается заменить build-системы компонентов. Он оркестрирует их штатные процессы в одном воспроизводимом окружении.
Установка через нативный MODX Transport API
Самая интересная часть эксперимента — стадия 10.
После сборки компоненты не устанавливаются через браузерный Package Manager и не требуют внешнего CLI вроде Gitify. Скрипт bootstrap'ит уже установленный MODX, находит созданные .transport.zip, создаёт объекты transport package и вызывает штатную установку через MODX API.
Получается цепочка:
source repository
→ official component build
→ .transport.zip
→ MODX Transport API
→ installed Extra
Это сохраняет все стандартные механизмы MODX package installation: resolvers, создание таблиц, settings, namespaces, menus и другие действия, которые заложены авторами компонента.
Почему не Composer как общий package manager
Composer здесь остаётся важной частью сборки, но не используется как замена MODX Package Manager.
Причина проста: MODX Extra — это не только PHP-код в vendor/. При установке transport package могут создаваться и изменяться объекты MODX, таблицы, системные настройки, меню, плагины и другие сущности.
Поэтому разделение ответственности выглядит так:
Git
→ исходники
Composer / npm
→ build dependencies
component build scripts
→ transport packages
MODX Transport API
→ фактическая установка Extras
На текущем этапе это выглядит чище, чем патчить composer.json MODX и пытаться превратить Composer в управляющий слой всей CMS.
Source-first подход
Главная особенность текущего эксперимента — компоненты устанавливаются не из готового каталога пакетов, а собираются прямо из Git.
У такого подхода есть несколько интересных сценариев.
Разработка MiniShop3 и зависимостей
Можно одновременно работать с исходниками:
MODX
pdoTools
VueTools
MiniShop3
и проверять изменения всей цепочки в одном runtime.
Это удобно для воспроизведения багов, тестирования pull requests и проверки совместимости между компонентами.
Точные версии
В перспективе каждый repository checkout можно привязать к конкретному commit. Тогда окружение становится значительно более воспроизводимым, чем установка latest из provider.
Исследование несовместимостей
Если конкретные версии MODX, pdoTools или MiniShop3 не собираются вместе, compatibility patches можно хранить явно на уровне runtime и документировать как часть конкретной комбинации.
Уже сейчас при сборке проявляются различия между актуальным MODX и ожиданиями build scripts некоторых компонентов. Это хороший пример того, почему source integration environment полезен сам по себе.
Compatibility patches
В исследовательской ветке уже приходится адаптировать некоторые build-time различия между компонентами и MODX.
Такие изменения важно рассматривать не как скрытые правки ядра, а как compatibility layer конкретного runtime.
В дальнейшем разумно хранить их явно, например:
patches/
modx3-package-builder-compat.patch
Это делает причину патча наблюдаемой и позволяет агенту или разработчику понимать, почему он существует и к каким версиям относится.
Что пока сделано упрощённо
Текущая реализация специально минимальна и предназначена для проверки гипотезы.
Сейчас набор компонентов и порядок их установки фактически зашиты в shell/PHP scripts. Это нормально для research-ветки, но не является желаемой конечной архитектурой.
Также пока не решены полностью:
- фиксация точных Git refs всех компонентов;
- lock-файл для комбинации версий;
- повторная сборка при изменении ref;
- корректное определение уже установленного состояния;
- строгий fail-fast при ошибке сборки или установки отдельного пакета;
- универсальное описание разных наборов Extras;
- управление compatibility patches;
- обновление уже установленного набора компонентов.
Например, простые marker-файлы вида .cloned, .packages-built и .packages-installed удобны для первого прототипа, но позднее должны уступить место сравнению desired state и фактического состояния окружения.
Возможное развитие: installation profiles
Если подход подтвердит жизнеспособность, конкретный набор MiniShop3 можно будет вынести из installer scripts в отдельный профиль.
Условно:
profile: minishop3
packages:
- pdoTools
- VueTools
- MiniShop3
А базовый modx-docker останется универсальным механизмом:
MODX runtime
+ fetch packages
+ build packages
+ install packages
Тогда MiniShop3 будет не жёстко зашитой особенностью Docker-окружения, а одним из готовых сценариев поверх него.
Позже аналогичным способом можно будет исследовать и другие наборы компонентов.
Связь с воспроизводимостью проекта
Это направление хорошо дополняет основную идею modx-docker.
Базовый проект отвечает на вопрос:
Как воспроизводимо поднять конкретную версию MODX и её runtime?
modx-docker-minishop исследует следующий уровень:
Как поверх этого runtime автоматически собрать и установить конкретный набор MODX-компонентов непосредственно из их исходников?
В перспективе воспроизводимая конфигурация магазина может включать:
MODX ref
PHP version
DB version
pdoTools ref
VueTools ref
MiniShop3 ref
project code
project database/files snapshot
Такое описание уже намного ближе к реальному состоянию проекта, чем просто номер версии MODX.
Связь с AI-разработкой
Для AI-агента source-first подход особенно интересен.
Агент получает доступ не только к установленному магазину, но и к исходникам всей технологической цепочки. Он может исследовать совместимость, видеть Git diff, менять компонент, пересобирать transport package, переустанавливать его и проверять результат в том же runtime.
Условно:
AI agent
↓
MODX source
pdoTools source
VueTools source
MiniShop3 source
↓
build / install
↓
running shop
↓
test / diagnose / modify
Это делает окружение полезным не только как автоматический installer, но и как экспериментальный SDK для разработки самой MODX-экосистемы.
Текущий статус
Сейчас modx-docker-minishop следует воспринимать именно как исследовательскую ветку.
Задача текущей реализации — не предоставить готовый production workflow, а проверить несколько архитектурных гипотез:
- можно ли полностью автоматизировать современный MiniShop3 stack без Manager UI;
- удобно ли собирать Extras прямо из Git;
- достаточно ли штатных build scripts и Transport API для общего installer pipeline;
- можно ли превратить набор компонентов в воспроизводимый installation profile;
- насколько такой runtime удобен для разработки и AI-агентов.
По результатам эксперимента часть решений может быть изменена или отброшена.
Исходный код research-ветки: MODX-Club/modx-docker — branch minishop3-native.
