Comments 10
Кажется что проблема должна решаться с другой стороны: когда мы хотим понять состояние дел, некая консольная тулза вроде phpstan может пробежаться по проекту/классу/всем классам неймспейса, собрать все import/new, и отобразить в консоли как warning все обращения к внешним классам, которых там быть не должно.
Не огораживание-драйвен-дев (ради потенциальной возможности когда-нибудь удобнее разбить монолит), а чтобы при необходимости разбить монолит можно было удобнее провести рефакторинг, для которого описанная выше тулза и пригодилась бы.
В текущем виде modulite создает неудобства/напоминает о себе каждый день, ради потенциального выигрыша в будущем. Для проектов мельче ВК это врядли окупится.
Жаль что так и не дождемся нативной поддержки приватных классов в php, как это описано здесь https://wiki.php.net/rfc/namespace-visibility
А можно ли с помощью Modulite решить такую проблему?
Допустим я в проекте использую две библиотеки (установленные через composer): LibA версии 1.0 и LibB версии 1.0, при этом у LibB в зависимостях библиотека LibA версии 2.0
Т.е. что бы мой проект использовал LibA своей версии, а библиотека которой я пользуюсь (LibB) - брал LibA своей версии.
Как это, допустим, возможно в JS, где всё билдится webpack'ом, и у каждого пакета могут быть "одинаковые" зависимости разных версий.
Насколько я понял данная либа это надстройка над средствами разработки и она никак не влияет на сам пхп, а у пхп ограничение на уровне ядра, что если класс с заданным именем уже был объявлен, то второй класс с таким же именем объявить нельзя
Кстати это типичная проблема в разработке для wordpress (бессмысленной и беспощадной)
Вот как иногда это решают:
Очень гнетущее впечатление от статьи. Долго пытался представить себе реальную ситуацию, где бы это могло пригодиться и я смог бы такое внедрить, и не находил в своей памяти и рассказах коллег ничего похожего. Код джунов все равно проходит ревью и там прилеты нежелательных связей отслеживаются. Если джун поймает нежелательную связь через ошибку, то он все равно пойдет спрашивать у того, кто знает, какой именно пяткой принято чесать это ухо в текущем проекте.
В случае если сеньоры будут лезть друг другу в подсистему без ревизий - инструмент наверное поможет. Но по опыту разгребания таких монолитов могу сказать, что там часто бывает так, что человек писавший модуль просто не думал, что его будут через год использовать ТАК и ОТТУДА. И нужно будет потратить много времени чтобы прийти к выводу, что да действительно, придется создавать связность.
Я в общем что хочу сказать: вы создали замечательный костыль для вашей кодовой базы в условиях вашего флоу. Называть это "честными модулями в PHP" - как-то громковато.
Что только не сделаешь, лишь бы не использовать подходящие инструменты, да?
Довольно интересная вещь, хоть и подход со стороны инструментов, что немного необычно. Может быть пропустил в тексте, но как внедрить модули такие в уже большой проект, если по умолчанию все запрещено "импортировать", можно ли создать точку отсчета, как в Psalm и применяться будет только к новому коду (модулям)? Просто из описания кажется, что внедрение этого инструмента разбивает проект на защищенные модули и разрывает уже существующие, иногда критичные, костыльные связи.
А какие версии PhpStorm поддерживаются?
Хотел проверить модуль в работе но в новых редакциях PhpStorm у меня так и не завелось.
Честные модули внутри PHP: теперь они существуют