А
Достаточно того, что я убедился, что ты его прочитал :D
Size: a a a
2020 November 12
Д
Вдруг это был не я?
А
Другой Дмитрий забил на чат. Видать бацка совсем интернет отрубил
T
Другой Дмитрий забил на чат. Видать бацка совсем интернет отрубил
🙈
AB
Можно делать так. При чтении конфига пакета создаëтся его копия в папке проекта и используется в дальнейшем.
Тогда при обновлении пакета старый конфиг никуда не денется.
Тогда при обновлении пакета старый конфиг никуда не денется.
Как тогда обновлять конфиги?
NO
Зачем?
2020 November 13
AB
В новом релизе появилась фича, которая требует конфигурирования, к примеру
NO
В таком случае есть Upgrade Notes, если нужна фича то вручную добавляешь её в свой конфиг.
Ну а если новый релиз не работает со старым конфигом то это прямое нарушение BC.
Ну а если новый релиз не работает со старым конфигом то это прямое нарушение BC.
AB
1. Тогда теряется смысл этих конфигов. При установке можно так же эти конфиги брать из пакета и тогда не будет этой возни с ребилдом конфигов
2. По условиям задачи - конфиг не часть публичного контракта. Зависимости из конфига не прописываются в require, средствами композера не разрулить
2. По условиям задачи - конфиг не часть публичного контракта. Зависимости из конфига не прописываются в require, средствами композера не разрулить
DS
Другой Дмитрий забил на чат. Видать бацка совсем интернет отрубил
Че это у вас тут за Дмитрии от бацьки?)
AB
2. Если у нас изменился не сам пакет, а, к примеру di и конфиги надо прописывать по-другому, то странно новую мажорную версию выкатывать
DS
2. Если у нас изменился не сам пакет, а, к примеру di и конфиги надо прописывать по-другому, то странно новую мажорную версию выкатывать
Если это yii-* пакет, то не странно.
AB
а если не он? вообще будет геморой с поддержкой, если каждая мажорная версия ключевого пакета будет требовать обновления мажорных версий всех пакетов из-за конфигов
DS
а если не он? вообще будет геморой с поддержкой, если каждая мажорная версия ключевого пакета будет требовать обновления мажорных версий всех пакетов из-за конфигов
По-другому это решается только вынесением конфигов в отдельные пакеты.
AB
Это да
А
По-другому это решается только вынесением конфигов в отдельные пакеты.
Или отдельным пакетом с версией формата конфигов
СП
А такой вариант не прокатит?
——
Есть сомнительный вариант - добавить в конфиг-плагин аналог "require". Тогда при сборке он будет ругаться, что у нас не та версия yiisoft/di или ещё какого пакета для этих конфигов.
То есть в composer.json будет что-то вроде:
——
Есть сомнительный вариант - добавить в конфиг-плагин аналог "require". Тогда при сборке он будет ругаться, что у нас не та версия yiisoft/di или ещё какого пакета для этих конфигов.
То есть в composer.json будет что-то вроде:
...
"extra": {
"config-plugin-require": {
"yiisoft:di": "^2.0",
},
...
}
...
DS
Собственно говоря по идеологии это близко к рецептам. Такие пакеты *-yiiconf можно делать и для сторонних пакетов других вендоров.
А
А такой вариант не прокатит?
——
Есть сомнительный вариант - добавить в конфиг-плагин аналог "require". Тогда при сборке он будет ругаться, что у нас не та версия yiisoft/di или ещё какого пакета для этих конфигов.
То есть в composer.json будет что-то вроде:
——
Есть сомнительный вариант - добавить в конфиг-плагин аналог "require". Тогда при сборке он будет ругаться, что у нас не та версия yiisoft/di или ещё какого пакета для этих конфигов.
То есть в composer.json будет что-то вроде:
...
"extra": {
"config-plugin-require": {
"yiisoft:di": "^2.0",
},
...
}
...
Надо ругаться не при сборке, а чтобы композер это разруливал
СП
Надо ругаться не при сборке, а чтобы композер это разруливал
тогда да, только пакеты приходят на ум