Достаточно не разумное мнение. Ты понимаешь, что эти инструменты дают? Дело тут совсем не в "бум-бум". А в автоматизации процессов.
Эти все инструменты (тестирование, проверка безопасности) не отменяют необходимости знаний. Знания по прежнему необходимы. Более того при использовании сторонних проектов ты не будешь изучать чужой код досканально. Ну представь некий Вася купил у тебя фреймворк. Он должен просто верить что там все ок с безопасностью? Или ты реально веришь в свою гениальность и думаешь, что твой фреймворк по определению не возможно взломать? если да то ты очень наивен.
Так вот представь сторонняя организация находит уязвимость в твоем фреймворке. Запускает процедуру связанную с этим, в. т.ч. уведомляет тебя как автора. Но тот Вася не знает об этом. А тут есть инструмент, который это подсветит. (это один из сценариев). Опять же, если ты действительно понимаешь что такое композер, не каждый пакет можно просто взять и обновить. Есть еще понятие версий и не всегда можно обновиться не проведя предварительную работу.
Для примера. я работаю с проектами Битрикс, тут я доверяю вендору и своевременно обновляю. Но есть маркет модулей, и вот там вот я ценю работу вендора, который модули прогоняет в плане безопасности и убирает с маркета модули с уязвимостями. (И по моему модулю приходило уведомление - но у меня модуль для работы с git и там есть некоторый функционал, который может быть опасен. Я им письмо просто пояснительное написал)
И вернемся к твоему фреймворку. Вот ты его сделал. вот уже он успешно шагает по интренету. Миллиарды разработчиков создают для него модули, выкладывают на твой маркет модулей (для продажи, а ты процент с этого имеешь). И каковы твои действия:
1. Тебе будет плевать если зальют модуль с уязвимостью (и бросят тень на твой фреймворк и его экосистему)
2. Будешь каждый модуль лично проверять просматривая весь код, и каждое обновление каждого модул?
3. Применишь инструмент (возможно даже "быстренько" напишешь свой) который будет автоматом проверять.
4. Что то иное?
А ясно. Для композера есть такие тоже
Разве? На сколько я знаю с пхп dependabot работает
Если я правильно понял.
venv - это типа для обеспечение своего окружения проекту. В композер сама суть зависимости ставятся в каталоге venodor проекта. Т.е. например у меня и фреймворк и шаблонизатор используют PhpUnit. При этом эти пакеты разных версий (т.к. минимальные версии PHP разные) - и это не мешает ни как.
build - для этого есть понятие script - здесь под разные проекты и задачи можно настроить какую то логику необходимую. Т.е. я могу настроить, например чтоб по команде composer build - выполнялась некая последовательность действий.
Ну в базе вроде на GitHub есть бот . Так же есть пакеты которые можно поставить в проект и которые не дадут поставить в проект пакет для которого есть найденные уязвимости. (но т.к. по условиям челенджа нет зависимостей то и сканировать не чего : )
Если ты про уязвимости моего проекта.. ни чем. Вот только брат в самом начале прогонял фреймворк через ИИ
composer, аналог poerty (и появился сильно раньше :) ). Ну и я в composer.json проекта и пакетов указываю допустимые версии зависимостей. (например шаблонизатор не встанет на фреймворк менее чем 1.5 версии. И требует php от 8.5 (а фреймворк от 8.4)... ну и т.п.. в общем указываю для каждого необходимого по зависимостям (и для прода и для дева) пакета с определенном синтаксисом допустимые версии. Плюс есть параметр позволяющий ставить не релизные версии.
Естественно изначально именно по этому я и обозначил что composer точно буду использовать, реализация автозагрузки уже вторая его задача. ее можно заменить. В начале я для АрбНета тут сделал набросок, как раз чтоб не пришлось (о ужас) ставить composer :) но при этом запустить проект.
Вчера не написал: так же настроил и чтоб пакеты (и фреймворк и шаблонизатор) при загрузке на гитхаб проходили тестирование и под будущим релизом php 8.6 (т.е. на данный момент я уверен, что проблем на будущем релизе нет)
Да понял, но тут я действительно пошел по пути как удобно мне :) Так вообще мой первый вход в веб разработку был связан именно с конструктором сайтов и там были у нас шаблоны (в прочем там ядро было вообще на сях). Т.е. идею я эту понимаю. Да и был проект как то где шаблон это не php. И участвовал в холиварах на подобную тематику. В общем у меня так уже сложившееся для себя (не настаиваю, что это правильно всегда и для всех). Что шаблон в php проектах должен быть php. Т.е. организационно решаем что там это не приветствуется, но все же для исключительных случаев оставлять. Ведь тот же стиль кода ни как "не защищается" на уровне языка (если учитывать доп инструменты разработки отдельно). Не готов сейчас предметно примеры привести, но были ситуации когда необходимость во что бы то ни то ни стало убрать из шаблона php приводила к необходимости добавлять некий оверхед. И вот как то для себя пришел к такому балансу всех за и против.
Единственное, если подумать только над каким то оригинальным расширением, типа "tphp", но тут "придется" донастраивать (очень сложно 😆 ) IDE.
Но вообще подумаю :) может и рубану шашкой. и запрещу php. ради эксперимента. Больше всего я "волнуюсь" за гибкость шаблонов компонентов. Меня сейчас в битрикс, для пример, иногда мысль посещает: для своего шаблона компонент формирует ассоциативный массив данных, и шаблон просто их выводит (в качестве шаблонизатора php) - т.е. в идеале только простейшие: echo, if...else....,foreach. в то же время в шаблоне есть доступ к компоненту - иногда может быть полезным вызвать его метод, вместо того чтобы сразу насыщать его данными....
