AB
https://github.com/yiisoft/yii-event/pull/10/files#diff-e092068ed7fbb4875374e27949c24381a44d38044f3ea9972dcf76d07caf8c54R70-R72 - мне кажется эту проверку можно запихнуть внутрь injector-а
Size: a a a
2020 November 12
NO
Ага, спасибо )
NO
Я имел в виду конечно официальную доку фреймворка.
NO
То есть вместо запиливания дефолтного сервис-провайдера, просто в пакете создаётся внятная дефолтная конфигурация, правильно?
NO
"In the application template yiisoft/composer-config-plugin is used. What the plugin does is collecting configs specified in all dependencies composer.json, config-plugin section and merging them on composer dump-autoload, composer update or composer install." Это ппц конечно (((
AM
То есть вместо запиливания дефолтного сервис-провайдера, просто в пакете создаётся внятная дефолтная конфигурация, правильно?
да
AM
"In the application template yiisoft/composer-config-plugin is used. What the plugin does is collecting configs specified in all dependencies composer.json, config-plugin section and merging them on composer dump-autoload, composer update or composer install." Это ппц конечно (((
Ты какой выпуск новостей читаешь? :)
NO
Супер, это как раз так как я хотел ) Кажется я об этом говорил, но рад что и без меня к тому же пришли ) Очень хорошее изменение
NO
Ты какой выпуск новостей читаешь? :)
Это в доке
В
"In the application template yiisoft/composer-config-plugin is used. What the plugin does is collecting configs specified in all dependencies composer.json, config-plugin section and merging them on composer dump-autoload, composer update or composer install." Это ппц конечно (((
Если не нравится юзать дефолтные конфиги - можешь просто написать свои, руководствуясь тем, что в пакете опубликовано :) Правда, я не понимаю пока, где здесь тот самый ппц.
NO
Ппц в лишнем этапе "сборки".
NO
Я уже приводил пример. Я правлю конфиг и чтобы приложение "увидело" изменение, я должен вручную дёргать "composer du"
NO
Боль, позор, унижение
NO
И всё это из-за того, что кому-то захотелось впилить плагин, который по-другому не умеет.
В
Я уже приводил пример. Я правлю конфиг и чтобы приложение "увидело" изменение, я должен вручную дёргать "composer du"
Есть еще 2 варианта:
- В точку входа добавить ребилд конфигов. Это, конечно, резко снизит производительность приложения, но изменения будут цепляться автоматом. Норм вариант для dev-окружения.
- Не использовать плагин, позволяющий грузить дефолтные конфиги.
- В точку входа добавить ребилд конфигов. Это, конечно, резко снизит производительность приложения, но изменения будут цепляться автоматом. Норм вариант для dev-окружения.
- Не использовать плагин, позволяющий грузить дефолтные конфиги.
В
И всё это из-за того, что кому-то захотелось впилить плагин, который по-другому не умеет.
Если есть идеи, как сделать лучше, мы всегда открыты для PR и issue :)
NO
1. Костыли во фреймворке
2. Перекладывание с больной головы на здоровую
2. Перекладывание с больной головы на здоровую
AM
Я уже приводил пример. Я правлю конфиг и чтобы приложение "увидело" изменение, я должен вручную дёргать "composer du"
Да нет же. В DEBUG режиме это уже пол года не так :)
NO
Да очень просто.
1. Сделать по дефолту в плагине чтение конфига напрямую без "сборки в файл".
2. Есть скомпиленный файл - читаем его.
3. Нет такого файла - читаем напрямую.
4. Компиляцию конфига сделать командой.
5. Команда компиляции будет выполняться только на проде после изменений конфига или при деплое.
1. Сделать по дефолту в плагине чтение конфига напрямую без "сборки в файл".
2. Есть скомпиленный файл - читаем его.
3. Нет такого файла - читаем напрямую.
4. Компиляцию конфига сделать командой.
5. Команда компиляции будет выполняться только на проде после изменений конфига или при деплое.
NO
Да нет же. В DEBUG режиме это уже пол года не так :)
Во-первых это костыль. Почему я свою локальную машину или допустим даже прод, должен переводить в DEBUG-режим, если я эту компиляцию использовать вообще не хочу?