Как стать автором
Обновить
4
0

Пользователь

Отправить сообщение
Ну, все таки, при обычной недоступности спасет кэш-прокси (маловероятно что вам почистят кэши именно в день, когда гитхаб опять забанят).

От внезапного удаления пакета помогает во-первых все тот же кэш прокси (они все таки жалуются, когда пакет пропал при синке), а во вторых --prefer-source при разработке — хоть у кого то из разработчиков да останется пакет в исходном виде (если учесть, что он не обновляется).

В самом крайнем случае код довольно легко извлечь с любого из стендов и уже в момент потери положить в репку, которую подключить в satis\toran\etc.

Мне все это кажется менее геморным, чем постоянно поддерживать несколько сотен форков, все таки пакеты не каждый день пропадают
Ну вот это примерно тот подход, который практиковали и мы. Обычно форк предварялся игрой «найди более поддерживаемый форк»
я просто грустнею даже от самой мысли, что мне бы пришлось поддерживать сотни три форков (да пусть даже и автоматикой, но поддерживать) с полной синхронизацией всех коммитов
А форки также случайно не почистят? подумав что это ненужная фигня — вот же оригинальный обновляемый проект в публичном доступе.
А какой смысл в тотальных форках пакетов? Если вы боитесь, что репы пропадут, то проще использовать кэширующий прокси для пакетов
Нет никакой проблемы зашить айпи запроса в токен и сверять их при получении токена на последующих запросах.

fingerprint клиента — это в любом случае клиентские подделываемые данные, доверять им не стоит никогда
саджест все равно в таких случаях некорректен. саджест — это предложение, а в вашем случае без установки такого «предложения» пакет не будет работать. в таких случаях делают по-другому:

реквестят (мета)-пакет «some-vendor/my-super-interface-implementation»
этот пакет не зарегистрирован в packagist, но любой другой пакет (например из вашего списка саджестов) может прописать у себя provides some-vendor/my-super-interface-implementation

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

Вот например так работают с тем же PSR-3 логгером

packagist.org/providers/psr/log-implementation
C газлом возможно неудачный пример, надо было брать какой-нибудь соап клиент, на которых нормальных стандартов не понаписали, а наследоваться от \SoapClient все не хотят
в таком случае
1. у вас в src нигде не будет зависимости от guzzle, только от psr
2. в require у вас будет какой нибудь psr/http-message все равно, т.к он требуется для вашей библиотеки
Очевидно же, что в библиотеке require желательно оставить пустым, а в require-dev пишем, что хотим, так как эти пакеты используются только для разработки и тестирования и к клиенту они не попадут.


я правильно понимаю, что вы заставляете пользователя искать транзитивные зависимости вручную? ну типа у вас есть какой-нибудь api клиент с использованием guzzle, а guzzle нужной версии вы заставляете людей ставить?

А если ваша библиотека написана с использованием nullable, а у человека 7.0, он тоже об этом только опытным путем узнает?
Как сейчас государство отзывает (объявляет недействительными) паспорта, которые лежат у нас в карманах? Принцип примерно тот же — достаточно внести идентификатор в базу. Хранить идентификатор — дешево. Проверить — быстро.
Зачем хранить за все время? или вы токены выдаете на года? Хранить надо до истечения времени жизни токена
Не очень понятно про возросший оверхед — сессию вы проверяли бесплатно? Поясните, пожалуйста. Инвалидация — да, болячка известная
Хранит придется только его идентификатор, что очень дешево
Докер на Win10 работает нативно быстро, если используется Hyper-V драйвер. Тормоза вольюмов VBox можно обойти, настроив файл-синк проекта шторма в руками созданный докер-хост на убунте. Если у вас Win10 — то просто поменяйте подсистему виртуализации и все залетает
Где свели в один инструмент git и env? если вы про dotenv, то по факту это инструмент, позволяющий мокать энвы через файл для локальных окружений, где их тяжело поддерживать одинаковыми путем системных инструментов. Он даже «по канону» включается только тогда, когда не определена перенная APP_ENV в окружении

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

Так что dotenv — это упрощение именно разработки для тех людей, где прод построен на энвах
Только зобми и есть безголовый браузер (https://github.com/assaf/zombie), поэтому он и зомби, я полагаю )
Не буду спорить, но у меня на сложных админках уже столько кастома, что проще впиливать полностью свои экраны, чем заморачиваться с кастомизацией что сонаты, что изиадмина.
Свои форм-тайпы там использовать так же просто — вместо встроенных типов указываете класс. Конфигурирование — да, чем то попахивает, с другой стороны проект расчитан именно на простые круд админки. Это прописано у них в фичах — круд, поиск и дизигн. Но для простых админок он гораздо удобней, чем соната. на мой взгляд.
Sonata получила поддержку symfony 3 (из-за FOS UB) только этим летом, что заставило нас отказаться от этого проекта в пользу easy admin в нескольких проектах. Ну и да, «особенностей» у нее полно.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность