Да, я вас понимаю, но на одном из проектов, мне нужна была реализация именно через Docker. Для коробочного решения, в котором был заложен Shellcheck без дополнительной необходимости устанавливать его на сервер.
Вы должны понимать, что prog-time/git-hooks я создал изначально для себя, для хранения часто используемых скриптов. Чтобы было полезно для других разработчиков я дополнительно сделал универсальные версии скриптов.
Скорее всего после вашего комментария, я пересмотрю свой подход и вырежу лишние версии скриптов, оставив только универсальные.
Буду очень благодарен, если вы поддержите проект звёздочкой или участием в разработке и предложите PR!
Несколько скриптов, потому что я на разных проектах использую разные наборы скриптов + в CI используются разные задачи.
Хорошее замечание! Я просто отталкивался от идеи, что проверка на существования файла написаны до запуска скрипта.
"Разнородные проверки одного и того же..." это я поправлю и приведу к единообразию!
"В случае ошибок показать список "неправильных" файлов..." это я пробовал, по итогу получается мусорный лог! Я отказался от такой практики, но вы всегда можете сделать форк и доработать скрипты.
Есть часть скриптов, которые работают только через Docker, они имеют указание суффикса docker в название.
Отлично! С biome не работал, но обязательно посмотрю! "...слышали ли вы про подход trophy для fe ?" - не совсем понял, что вы имеете ввиду. Опишите пожалуйста подробнее.
Ну да, перефразировали и выдали за правильное определение!
Вы на, так называемое "окончание мысли", не пишите автотесты? Не подгоняете code style под общий стандарт? Не следите за ошибками?
Если вы всё это делаете, то вам не стоит бояться pre-commit проверок. Я в статье написал, что мои pre-commit скрипты проверяют только измененные файлы. А внутри pre-push проверяется уже весь проект целиком, чтобы лишний раз не гонять CI.
Согласен! Вы же всегда можете временно отключить pre-commit скрипты и пролить ветку в репозитори, а внутри репозитория вас уже не пропустит CI.
Но я всё же против такого подхода, так как считаю, что commit - это точка наиболее стабильной версии кода. По этой причине я при каждом коммите запускаю проверку тестов.
PSR-12 — официальный стандарт, а PER — это надстройка над PSR-12 для более строгой проверки. Она расширяет PSR-12 дополнительными правилами для более строгого и единообразного стиля кода (например, обязательное использование declare(strict_types=1), строгие пробелы, порядок импортов и т.п.).
Я считаю, что эти 2 подхода актуальны, но всё зависит от области применения:
Для проектов с открытым кодом, фреймворков, библиотек — PSR-12.
Для внутренних корпоративных проектов, где нужна дисциплина и единый стиль — можно добавить PER поверх PSR-12.
P.S. Как я писал ранее, я не рекомендую внедрять максимальную строгость на старые проекты, так как это может сильно нагрузить разработчиков и сократить продуктивность.
Я пробовал, но отказался от такого подхода по причине того, что Laravel имеет много внутренних ошибок и если поставить максимальный level, то PHPStan будет ругаться на ошибки фреймворка.
Я также не использую максимальный level, так как такая строгость может отпугнуть и убить всё желание использовать PHPStan.
Увеличивайте уровень постепенно, но начинайте с 6-7. Меньше уже плохо, так как он начинает закрывать глаза на типизацию.
Спасибо всем, кто дочитал до конца! Я постарался собрать практики, которые реально экономят время и нервы в Laravel-проектах. Если у вас есть свои лайфхаки по автоматизации — буду рад услышать в комментариях, возможно, смогу дополнить статью.
Спасибо всем, кто следит за проектом и делится обратной связью!
В этом обновлении постарался закрыть основные запросы от пользователей — в первую очередь, по интеграции с ВКонтакте и удобному развёртыванию через Docker.
Дальше в планах:
добавить web-интерфейс для просмотра информации о чатах и пользователях;
добавить API для работы с чатами;
расширить метрики и алерты в Grafana.
Если у вас есть идеи или кейсы использования — смело оставляйте в Issues, буду рад поработать над ними.
Спасибо за поддержку и звёзды — это действительно помогает развивать проект 🙌
Да это больно!
Радует, что хоть в Telegram ботах всё стабильно хорошо. Но не радует, что с Telegram не всё стабильно в России (((
Да, я вас понимаю, но на одном из проектов, мне нужна была реализация именно через Docker. Для коробочного решения, в котором был заложен
Shellcheckбез дополнительной необходимости устанавливать его на сервер.Вы должны понимать, что prog-time/git-hooks я создал изначально для себя, для хранения часто используемых скриптов. Чтобы было полезно для других разработчиков я дополнительно сделал универсальные версии скриптов.
Скорее всего после вашего комментария, я пересмотрю свой подход и вырежу лишние версии скриптов, оставив только универсальные.
Буду очень благодарен, если вы поддержите проект звёздочкой или участием в разработке и предложите PR!
Спасибо, что подсветили!
Несколько скриптов, потому что я на разных проектах использую разные наборы скриптов + в CI используются разные задачи.
Хорошее замечание! Я просто отталкивался от идеи, что проверка на существования файла написаны до запуска скрипта.
"Разнородные проверки одного и того же..." это я поправлю и приведу к единообразию!
"В случае ошибок показать список "неправильных" файлов..." это я пробовал, по итогу получается мусорный лог! Я отказался от такой практики, но вы всегда можете сделать форк и доработать скрипты.
Есть часть скриптов, которые работают только через Docker, они имеют указание суффикса docker в название.
Я с vale.sh не работал. Ознакомлюсь!
Спасибо. Рад, что вам понравилась данная статья.
Я не хотел делать акцент на событие pre-commit! В моём репозитории собраны скрипты и для pre-push.
Идея была в том, чтобы проводить проверки локально, чтобы избежать таких мелочей, как "лишний импорт", неправильные отступы и отсутствие типизации.
Вы самостоятельно можете комбинировать нужные вам скрипты!
Отлично! С biome не работал, но обязательно посмотрю!
"...слышали ли вы про подход trophy для fe ?" - не совсем понял, что вы имеете ввиду. Опишите пожалуйста подробнее.
Ну да, перефразировали и выдали за правильное определение!
Вы на, так называемое "окончание мысли", не пишите автотесты? Не подгоняете code style под общий стандарт? Не следите за ошибками?
Если вы всё это делаете, то вам не стоит бояться pre-commit проверок. Я в статье написал, что мои pre-commit скрипты проверяют только измененные файлы. А внутри pre-push проверяется уже весь проект целиком, чтобы лишний раз не гонять CI.
А как ты относишься к git-хукам, которые автоматически исправляют code style? Или те, что корректируют комментарий к коммиту?
Это достаточно универсальная вещь, которая приносит много пользы!
Согласен! Вы же всегда можете временно отключить pre-commit скрипты и пролить ветку в репозитори, а внутри репозитория вас уже не пропустит CI.
Но я всё же против такого подхода, так как считаю, что commit - это точка наиболее стабильной версии кода. По этой причине я при каждом коммите запускаю проверку тестов.
Я только начинаю изучать Python, поэтому буду рад если вы предложите свои альтернативы.
Про ruff я слышал, обязательно позже добавлю версию скрипта с проверкой ruff-pre-commit!
Спасибо, что подсветили!
PSR-12 — официальный стандарт, а PER — это надстройка над PSR-12 для более строгой проверки. Она расширяет PSR-12 дополнительными правилами для более строгого и единообразного стиля кода (например, обязательное использование declare(strict_types=1), строгие пробелы, порядок импортов и т.п.).
Я считаю, что эти 2 подхода актуальны, но всё зависит от области применения:
Для проектов с открытым кодом, фреймворков, библиотек — PSR-12.
Для внутренних корпоративных проектов, где нужна дисциплина и единый стиль — можно добавить PER поверх PSR-12.
P.S.
Как я писал ранее, я не рекомендую внедрять максимальную строгость на старые проекты, так как это может сильно нагрузить разработчиков и сократить продуктивность.
Проверки и тесты лучше внедрять постепенно!
Я не генерирую статьи с помощью LLM! Я пишу о том, что я лично использую.
Статья написана мной лично, все исходники кода можно найти в моих проектах и в отдельном репозитории на GitHub.
Я пробовал, но отказался от такого подхода по причине того, что Laravel имеет много внутренних ошибок и если поставить максимальный level, то PHPStan будет ругаться на ошибки фреймворка.
Я также не использую максимальный level, так как такая строгость может отпугнуть и убить всё желание использовать PHPStan.
Увеличивайте уровень постепенно, но начинайте с 6-7. Меньше уже плохо, так как он начинает закрывать глаза на типизацию.
Попробуйте level = 9 и скажите своё мнение )))
Спасибо всем, кто дочитал до конца!
Я постарался собрать практики, которые реально экономят время и нервы в Laravel-проектах.
Если у вас есть свои лайфхаки по автоматизации — буду рад услышать в комментариях, возможно, смогу дополнить статью.
Спасибо! Рад что вам понравился данный проект.
Статью писал сам, а нейросеть попросил проверить на грамматические ошибки и «припудрить» немного!
Интересно!
Обязательно ознакомлюсь. Спасибо!
Сейчас планирую двигаться в направление Viber и WhatsApp, так как они более популярны!
Также в ближайшем релизе я опубликую API для подключения внешних источников, например "живого чата" на сайте или для интеграции с CRM системой.
Проект развивается и мне очень важна ваша поддержка!
Спасибо всем, кто следит за проектом и делится обратной связью!
В этом обновлении постарался закрыть основные запросы от пользователей — в первую очередь, по интеграции с ВКонтакте и удобному развёртыванию через Docker.
Дальше в планах:
добавить web-интерфейс для просмотра информации о чатах и пользователях;
добавить API для работы с чатами;
расширить метрики и алерты в Grafana.
Если у вас есть идеи или кейсы использования — смело оставляйте в Issues, буду рад поработать над ними.
Спасибо за поддержку и звёзды — это действительно помогает развивать проект 🙌