Еще можно glob патерны использовать

Как демку можно юзать

Ну есть такое, но там фигни много и я хз когда руки доберутся допилить https://github.com/SerafimArts/packagist.app/tree/master

Можно кстати разнести configs по своим модулям, правда там будет и более жесткое разделение, хз плюс это или минус)

Валентин в своем скелетоне показывал

И еще получается у тебя доктрина смотрит на всю апку. Хотя мб и пофиг

Те же типы в одном общем месте

Как тогда разнести их по разным папкам?

В каждом модуле делаешь свой конфиг, там все указываешь, а потом в основном конфиге цепляешь все внутренние

В каждом модуле делаешь свой конфиг, там все указываешь, а потом в основном конфиге цепляешь все внутренние

Ну например это нигде не найти в доке =)

Ну например это нигде не найти в доке =)

Там стандартный подход для мелких проектов

Там стандартный подход для мелких проектов

Ну например что такое модуль, и что за свой конфиг в каждом модуле?

В каждом модуле делаешь свой конфиг, там все указываешь, а потом в основном конфиге цепляешь все внутренние

Я так понимаю, примерно как сделал Кирилл выше? Просто ручками import указывать из главного конфига?

Я так понимаю, примерно как сделал Кирилл выше? Просто ручками import указывать из главного конфига?

Да, по маске

Как пример, вот - { resource: ./../src/**/config/di.yml}

Я так понимаю, примерно как сделал Кирилл выше? Просто ручками import указывать из главного конфига?

Разница в том, что у него конфиги в одном месте лежат, а тут (файл лежит внутри модуля)

Как пример, вот - { resource: ./../src/**/config/di.yml}

Ну это вариант да. Но получается единый конфиг всего приложения + не уверен как работают package директория. У Кирилла я не увидел разделения той же доктрины по модулям

Т.е. например если в одном модуле забиндить что то, то это будет доступно и в другом. Вроде и ок, вроде и не ок

Т.е. например если в одном модуле забиндить что то, то это будет доступно и в другом. Вроде и ок, вроде и не ок

Забиндить в каком плане?

_default: bind: $env

Короче основной поинт в том, что конфиг хоть и располагается в папке модуля - он единый системы. Ну это просто как факт

Короче основной поинт в том, что конфиг хоть и располагается в папке модуля - он единый системы. Ну это просто как факт

Ну да, но все равно удобнее работать, чем например конфиг на 1К строк

Ну это вариант да. Но получается единый конфиг всего приложения + не уверен как работают package директория. У Кирилла я не увидел разделения той же доктрины по модулям

На потому что я по-быстрому писал, без заморочек особых)

Если же грузить через Кернел, как Удальцов предлагал, то там конфиги будут как бы своих "неймспейсках". Это имеет как плюсы (что свой), так и минусы (что надо некоторые вещи дублировать)

Так-то, с удовольствием посмотрю как порезать это всё нормально

Но вообще вариант с импортом ручным все равно неплох по папкам, я лично не думал о таком)

https://github.com/vudaltsov/symfony-modular-skeleton Вариант Удальцова

https://github.com/vudaltsov/symfony-modular-skeleton Вариант Удальцова

Я в целом его вариант и использую почти, только с некоторыми отклонениями, например для dev свой файл конфига

Хм

Чет наверное я путаю сам тогда, дейстивтльено у него так и есть)

Я чет думал у него через Кернел

Чет наверное я путаю сам тогда, дейстивтльено у него так и есть)

Вообще, очень хорошо можно заметить разницу, когда есть два проекта, на одном стандартный сифони подход, а на другом нет

Вообще, очень хорошо можно заметить разницу, когда есть два проекта, на одном стандартный сифони подход, а на другом нет

Так, ладно. А как тогда package директории работают?

Вот это вот все про доктрину и тп

Они получаются все так же в config/package общие для всего проекта?

Я чет думал я кернел у Удальцова взял, а оказывается в другом месте где то )))

Они получаются все так же в config/package общие для всего проекта?

Это просто все в один идет в итоге imports: - { resource: ./packages/**.yml} - { resource: ./internal/**.yml} - { resource: ./../src/**/config/di.yml}

Это просто все в один идет в итоге imports: - { resource: ./packages/**.yml} - { resource: ./internal/**.yml} - { resource: ./../src/**/config/di.yml}

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

И например есои укащать теггет итератор одного модуля в другом - то он его видеть не будет.

Альясы сервисов наверно тоже

Связи, пропсы. Попробуй) Это грубо говоря вопрос ответ в cli а на выходе сущность с пропсами и геттерами/сеттерами

Ктрл ц ктр в и всё, эти ваши гены нефига не удобные

Ктрл ц ктр в и всё, эти ваши гены нефига не удобные

Я не пользуюсь, но имел опыт знаю что это. Так же имел опыт общения с опытными, кто пользуется

Эпиляция к авторитету, понял

Эпиляция к авторитету, понял

Лишь опыт того, что видел слышал

Я не говорю пользоваться, я описываю какие возможности есть, и что есть те кто пользуется, и не только новички

Я знаю парня, который знает парня, который сказал что генерация через cli не удобная

Я знаю парня, который знает парня, который сказал что генерация через cli не удобная

В чем ваш поинт не пойму

Мы свой генератор написали для болерплейта

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

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

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

не.. у нас в кернеле все конфиги из всех модулей импортируются

не.. у нас в кернеле все конфиги из всех модулей импортируются

Вооо. Вот если взять В модуле A забиндить $envireonment, то в модуле Б этот бинд виден не будет

кстати наш генератор например для круда создает полностью все - ручки, тесты, openapi спеку

Если в модуле А сделать тегет итератор, то его нельзя будет заинжектить в модуле Б, он его тоже не увидит

Ну как то так короче

не понял о чем ты.. у нас практически все на атрибутах

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

кстати наш генератор например для круда создает полностью все - ручки, тесты, openapi спеку

А не на оборот должно разве быть? Из спеки рождаются сущности, поинты, тесты?

и энвы и таггед итератор, все через атрибуты

А не на оборот должно разве быть? Из спеки рождаются сущности, поинты, тесты?

ну спеку же надо написать.. а тут генератору говоришь имена сущности, полей и он тебе все генерит

Ну да, в этом и смысл. Пишешь спеку - из нё всё генерится. Обновляешь спеку - всё обновляется

надеюсь доживем когда голосом будешь управлять AI чтобы подобное делать

Ну да, в этом и смысл. Пишешь спеку - из нё всё генерится. Обновляешь спеку - всё обновляется

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

и энвы и таггед итератор, все через атрибуты

Если не ошибаюсь (просто такая фигня была с ямлом и тегами), например возьмем тегет локатор. Обозначим интерфейсом сервисы лежащие в модуле А, в потом ContainerInterface который будет являться точкой доступа для этих сервисов, обозначим в модуле Б. То сервисы из модуля А, внутри контейнера модуля Б - не окажутся. Потому что у них разный скоуп DI

Ну ладно, потом дойдёте

Ну ладно, потом дойдёте

писать спеку муторно и не интересно, поэтому мы ее тоже генерим

видимо ты меня не так понял

Если не ошибаюсь (просто такая фигня была с ямлом и тегами), например возьмем тегет локатор. Обозначим интерфейсом сервисы лежащие в модуле А, в потом ContainerInterface который будет являться точкой доступа для этих сервисов, обозначим в модуле Б. То сервисы из модуля А, внутри контейнера модуля Б - не окажутся. Потому что у них разный скоуп DI

Мы не используем такие извращения )

Мы не используем такие извращения )

Это просто пример =) Пример что импорт через конфиг и импорт через кернел -разные

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

Но я не говорю что, что то лучше хуже - просто есть свои + и -

Конфиги просто ужаснык, луичше через аннотацию

Конфиги просто ужаснык, луичше через аннотацию

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

просто перносим описание

Нyжны 2 человека.Нужен телефон и два часа свободного времени в день. От 200 зeлёных в дeнь. Удалённaя сфера.За подробностями пишите сюда [@top_grooup13bot]

Подскажите, как победить пхпстан 10го уровня? ) https://phpstan.org/r/31bce9df-d1d8-4647-a763-fd6535709243

<?php declare(strict_types = 1); class Uuid { private string $uuid; public function __construct(string $uuid) { $this->uuid = $uuid; } public function __toString() { return $this->uuid; } } class HelloWorld { /** * @param list<Uuid> $a * * @return list<string> */ public function sayHello(array $a): array { $b = array_map( static fn(Uuid $c): string => (string)$c, $a, ); return $b; } }

на именнованные константы и модификаторы доступы у меня ругается для php 7

Подскажите, как победить пхпстан 10го уровня? ) https://phpstan.org/r/31bce9df-d1d8-4647-a763-fd6535709243

не использовать именованные аргументы в некорректном порядке

это багло в стане, кажется

ага спасибо )

Подскажите, как победить пхпстан 10го уровня? ) https://phpstan.org/r/31bce9df-d1d8-4647-a763-fd6535709243

А там есть какие то плюсы после 8 уровня?