СП
Эм... почему всего на свете?
Size: a a a
2021 May 20
СП
Ну вот есть конфигурация контейнера, она собирается из файликов, которые мёржаться. Или ты о чём-то другом?
NO
Ну, я не вижу преимуществ единого конфига для всего приложения перед несколькими конфигами для разных частей.
Даже наоборот, когда каждая часть получает свою собственную порцию, это более гибко и более наглядно
Даже наоборот, когда каждая часть получает свою собственную порцию, это более гибко и более наглядно
СП
Каким образом ты будешь распределять что в какую часть?
СП
что подразумеваешь под "часть приложения"?
NO
То что ты раньше называл - роуты, события, конфигурация контейнера
NO
Ладно, если порядок не важен, то остаëтся только объединение файлов в список?
Этого можно легко добиться без всякого merge_plan, одним лишь соглашением.
Этого можно легко добиться без всякого merge_plan, одним лишь соглашением.
СП
Каким образом соглашение позволит конфиг-плагину узнать где и какие файлы брать?
NO
Ну он как-то узнаëт про то где находится merge_plan?
СП
роуты, события, конфигурация контейнера не мёржаться между собой.
Для конфигурации контейнера, например, есть пачка файлов (из пакетов + из приложения), которые мёржаться в один массив
Для конфигурации контейнера, например, есть пачка файлов (из пакетов + из приложения), которые мёржаться в один массив
AM
План позволяет не ходить в vendor и не сканить в рантайме ничего пытаясь определить, есть там конфиг или нет его.
СП
у мержплана конкретное место
AM
Собственно, всё.
AM
Это что-то типа кеша.
AM
Освобождает нас от скана директорий.
СП
+ ещё хранит кэши конфигов из пакетов, чтобы узнавать, что обновилось
ПА
а почему не делать какой нить discovery метод который забирал конфиг из плагина / вендора и клал куда нужно и добавлял в мердж?
ПА
один раз просканил после установки пакета в postInstall какой нить и все
СП
Примерно это конфиг-плагин и делает :)
NO
Прикольно, и поменять нельзя?