mmxApp - разработка новых composer дополнений

Я для себя нашел решение, такое как описал для Василия. Я не использую образу напрямую из dockerhub, а строю свои образы на их основании. Это позволяет добавить в контейнер своего пользователя, настроить его привелегии и избежать проблем с правами на файлы, генерируемые внутри контейнера.
А как например работает вы? Вот самый простой пример, нужно запутсить ларавель в контейнерах. По умолчанию считаем (и я всегда придерживаюсь этого правила и на своей локальной машине и на серверах), что раз я использую докер, то значит никаких локально установленных программ не должно быть. Тоесть на нашем компьютере нет своего php, нет своей node или nginx, нет redis и прочих mariadb. Мы запускаем php-fpm контейнер, в нутри которого проброшена директория с файлами laravel. Вам нужно выполнить команду в artisan. Напоминаю, что выполнить локально php artisan мы не можем, у нас просто нет php на машине. Значит нам нужно войти в php-fpm контейнер и там выполнить php artisan make model. Файл будет создан, появится у вас локально в редакторе кода, но редактировать вы его не сможете, потому что он создан пользователем root внутри php-fpm. При такой конфигурации, когда генерация файла происходит «изнутри наружу» и не продуманы заранее эти проблемы с правами, вы не сможете работать с кодом, генерируемым artisan, но если вы создадите файл модели в редакторе вручную, то он будет создан наоборот, «снаружи внутрь» и такой файл будет работать правильно.
В общем да, докер жутко неидеальный инструмент. И не простой. Его осознанное использование требует высоких навыков системного администрирования линукс серверов, глубоких знаних в работе компьютерных сетей (попробуйте ради интереса получить ip адрес пользователя внутри php запущенного внутри docker compose).
А лично моя проблема, которая доставляет массу неприятностей в работе, в том что я перфекционист в требованиях к себе. Я не могу пользоваться технологией, пока не разберусь в ней хотя бы на 4- из 5. Искренне завидую тем людям (без иронии), которые умеют просто пойти нагуглить функцию на стекоферфлов и даже не читая ее вставлять в свой код. Или же которые просят какой то там ИИ написать решение. Я не могу) Поэтому приходится дотошно ночами экспериментировать с технологиями, но мне нравится.

Вот кстати насчет того, что я не любитель магии в программировании. Василий в своих полезных видео рассказывает много интересного, но помоему сейчас его уводит в стороны рассказ о том как работать с eloquent и vesp, последние видео очень мало связаны с modx.
было бы очень позновательно, если бы вы Василий сделали отступление и рассказали, а как именно код нашего приложения интегрируется и попадает внутрь modx. Для меня например был неприятен момент, когда я редактирую PHP код компонента в директории для этого преднозначенной, это сразу отражается в работе сайта. Да это удобно и полезно, но это НЕЛОГИЧНО. Я ведь видел что проищошла инсталяция нашего приложения через composer а значит весь исходный код должен был переместиться в директорию vendor внутри modx а значит никакие изменения теперь не должны влиять. Ведь так? А влияют. Приятно, но НЕНАВИЖУ МАГИЮ. И приходится построчно изучать все инсталяционные скрипты, докер конфигурации, команды symfony console чтобы понять, откуда магия. И найти что вы так очень хитро манирулируете с симлинками. (кстати почти уверен что будут проблемы при переносе приложения из одной директорию в другую, поскольку симлинки в linux создаются с абсолютными путями). Или тот же фронтенд. Тоже небольшая магия, правишь код уже инсталированного composer приложения а он сразу меняется. Правда от этого гадостного современного фронтенда ты уже морально ожидаешь такого подвоха и ты уже удивляешься меньше чем с php. Но снова приходится искать в коде, что вы подменяете ссылки на подключение скриптов. Так же очень неочевиден роутинг. Я пока только мельком взгялнул и пришел к выводу, что теперь в системе есть аж 3 разных роутера. Прежде всего сам modx стороит свой роутинг на основании неймспейсов компонентов. Потом vue строит свой роутинг, для фронтенда. И потом vesp имеет свою роутинг, на основании slim и наверное fastroute. И есть очень много таких подводных камней. Я не говорю что они сделаны плохо или что я могу лучше, нет. Я просто считают что прежде всего нужно рассказать в видео именно о таких вещах, детально рассмотреть как именно встраивается ваше приложение внутрь modx. А то сейчас вы описываете в видео создание псевдо магазина и это инересно, но это совсем не про modx, а про vue, bootstarp-vue, vesp и так далее. И кстати. а как вам удалсь избежать проблем с несколькими реализациями psr-7? Мельком глянул код и увидел что modx использует реализацию от guzzle, а вы slim овскую. (кстати считаю что слимовская правильный выбор, это наиболее точная реализация стандарта). Ведь теперь в системе есть два класса реализующий один и тот же интерфейс и нельзя будет где то запрашивать иньекцю зависимости по интерфейсу. Хотя может в 3 modx и нет такой возможности.
В общем, буду благодарен если в одном из следующих видео Василй расскажет детально про магию. В том числе как планируется работать с миграциями, сейчас насколько я понимаю выполнить миграции можно только при установке компонента.