Д
Я пока процентов 9 разговоров в чате понимаю...
Size: a a a
2020 July 22
Д
Хорошо хоть прогресс есть . Месяца три назад был 1
Д
Вроде и язык русский.
2020 July 23
RM
@viktorprogger AFAIK PRs should be merged by "squash and merge" :)
В
@viktorprogger AFAIK PRs should be merged by "squash and merge" :)
Sorry, will do this way next time
В
I have to re-check our guides
DS
Проверка хороша когда в dev. Конфиг events поменял, но чтобы проверить валидность конфига - надо дойти в проекте до того места, где вызывается событие, либо вызывать его самому - не удобно. А в проде это всё лишнее
Есть мысль сделать EventConfigChecker и в дев запускать
$checker->checkConfig(require Builder::path('events-web'))
А проверки с конфигуратора вообще убратьА
Есть мысль сделать EventConfigChecker и в дев запускать
$checker->checkConfig(require Builder::path('events-web'))
А проверки с конфигуратора вообще убратьЧекать ивенты через ивенты? Звучит как план. Мне нравится.
DS
Чекать ивенты через ивенты? Звучит как план. Мне нравится.
Почему через ивенты?
А
Почему через ивенты?
Опять сообщение жопой прочитал )
А
Но кстати через ивент мб было бы и проще
А
Модули, которым надо чекать конфиг, подписываются на событие, которое им скажет, когда можно прочекать...
А
А проще тем, что не надо создавать новую группу конфигов, например
DS
А
О, опять к вопросу о валидации :)
В
@yiiliveext, @roxblnfk, а чем не нравится мысль сделать dev-реализацию конфигуратора с проверками и prod без них?
А
О, опять к вопросу о валидации :)
Является ли коллейбл с указанием несуществующего класса валидным?
А
@yiiliveext, @roxblnfk, а чем не нравится мысль сделать dev-реализацию конфигуратора с проверками и prod без них?
Дмитрий предлагает эти проверки объединить в один сервис и само приложение будет решать, когда их запускать. Вроде хороший вариант то