а, ну если учитывать и тот что в вендоре..

В девтул такое на автомате отрабатывает. Надо только универсальнее сделать, чтобы не только для пакетов из yiisoft работало

Я локально.

Можно в issue?

У меня подобное вылезало когда я композером в проекте вне yii-dev работал. То ли обновлял со старой версии на новую, то ли тег вешал на config-plugin. Приходилось вендор сносить.
Я так понимаю, там просто возникают ситуации, когда по событию композера надо дёрнуть хендлер config-плагина, но хендлера физически нет. То ли это поведение кешируется в композере, то ли событие не то выбрано - хз.

Сделал PR по избавлению от дублирующихся конфигов:

1. Убрал ненужное копирование и создание папок

2. Сделал загрузку конфига из вендора если пользовательский конфиг отсутствует

3. Поправил один из тестов, к сожалению тестов много и все завязаны на дубликаты, поэтому править их долго, не успеваю (

https://github.com/yiisoft/config/pull/16

Может возникнут проблема в ситуации:

• Приложение работает с пакетом 0.1.0, использует конфиги по умолчанию
• Пакет обновляет конфиги в версии 0.2.0
• В приложении обновляем пакет и мы НЕ знаем, что конфигурация-то изменилась

Слом обратной совместимости это не дело пакета управления конфигами, а дело автора конкретного пакета, и он должен это сам корректно разруливать например через соблюдение семантического версионирования.

+ инструкция по обновлению на ломающие совместимость версии

Автор изменил конфиг пакета, но это меняет конфигурацию нашего приложения.
Хотелось бы это держать под контролем.

Сейчас я сразу увижу, что конфиг изменился.

Конфиг это лишь место где хранятся настройки. Поймите уже наконец. Если автор пакета прописал дефолтное значение в конфиге, это ничем не отличается от того если бы он прописал это значение в своём коде. И последствия изменения и в конфиге и в коде абсолютно те же самые.

Если он меняет что-то что ломает совместимость с приложением он обязан это разрулить, вне зависимости в конфиге это или в коде.

Например апнуть мажорную версию или предоставить инструкции по обновлению или и то и другое.

Например, в конфиге пакета 0.1.0:
MyInterface::class => MyImplementation::class

В приложении используется MyInterface и всё работает.

В конфиге пакета 0.2.0 конфигурация этого интерфейса убирается. Пакет работает отлично.

Но после обновления, моё приложение уже не будет работать, так как не сможет получить реализацию интерфейса.

Конфиги - это не код... менять мажорную версию из-за конфигов - не правильно.

Почему у вас в голове конфиг это что-то отдельное от приложения? Это тупо часть кода, просто для удобства редактирования сгруппированная в одном файле. Точно так же определяет поведение приложения как и всё остальное.

Исключение - это "секреты", типа ключей, паролей, IP, хосты, и прочие инфраструктурные вещи. Это уже отдельно. Но для этого обычно есть .env либо локальные конфиги которые не хранятся в гите, это другое )

С ^0.1.0 ты не обновишь до 0.2.0

Неправильно думать что ты можешь вытолкнуть часть своего кода в отдельный файл, обозвать его конфигом и позволить его менять как душеньке угодно наплевав на проблемы пользователей этого файла.