ВШ
Вані4ка Луціашвілі
Как и в логах самого проектв
Так не бывает
Size: a a a
2021 March 09
ВШ
Либо в лог сервера, либо перехват в лог laravel
RK
Ребята, всем привет!
Возникла потребность упростить свою работу и генерировать скоупы для модели автоматизированно.
Очень долго искал, но нужного мне пакета так и не нашёл, поэтому решил написать свой.
Есть пакеты, реализующие отдалённо похожий функционал, но везде генерируются новые файлы моделей, от которых нужно наследоваться, а этот способ мне совершенно не подходит.
Так как в разработке пакетов (да и в принципе в архитектуре) не сказать, что много чего понимаю, очень бы хотелось услышать вашу конструктивную критику, что хорошо сделано, а что стоит поправить.
С удовольствием почитаю ваши сообщения, а для особо творческих - внимательно изучу ваши pull-реквесты и, вероятнее всего, приму их.
Было бы очень круто узнать ваше мнение.
Это не в коем случае не реклама. Просто хочу развиваться, да и дальше есть план написать ещё пакеты, поэтому хотелось бы опираться на что-то проверенное и одобренное.
Всем участвующим в тестировании - большое спасибо :)
https://packagist.org/packages/ratiborro/laravel-scopes
P.S. И да, не ругайте пока, что README на русском, просто я бы не смог нормально выразить свои мысли на другом языке. Буду над этим работать :)
Возникла потребность упростить свою работу и генерировать скоупы для модели автоматизированно.
Очень долго искал, но нужного мне пакета так и не нашёл, поэтому решил написать свой.
Есть пакеты, реализующие отдалённо похожий функционал, но везде генерируются новые файлы моделей, от которых нужно наследоваться, а этот способ мне совершенно не подходит.
Так как в разработке пакетов (да и в принципе в архитектуре) не сказать, что много чего понимаю, очень бы хотелось услышать вашу конструктивную критику, что хорошо сделано, а что стоит поправить.
С удовольствием почитаю ваши сообщения, а для особо творческих - внимательно изучу ваши pull-реквесты и, вероятнее всего, приму их.
Было бы очень круто узнать ваше мнение.
Это не в коем случае не реклама. Просто хочу развиваться, да и дальше есть план написать ещё пакеты, поэтому хотелось бы опираться на что-то проверенное и одобренное.
Всем участвующим в тестировании - большое спасибо :)
https://packagist.org/packages/ratiborro/laravel-scopes
P.S. И да, не ругайте пока, что README на русском, просто я бы не смог нормально выразить свои мысли на другом языке. Буду над этим работать :)
RK
И есть вопрос, на который я так и не смог найти ответ:
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
AH
Ребята, всем привет!
Возникла потребность упростить свою работу и генерировать скоупы для модели автоматизированно.
Очень долго искал, но нужного мне пакета так и не нашёл, поэтому решил написать свой.
Есть пакеты, реализующие отдалённо похожий функционал, но везде генерируются новые файлы моделей, от которых нужно наследоваться, а этот способ мне совершенно не подходит.
Так как в разработке пакетов (да и в принципе в архитектуре) не сказать, что много чего понимаю, очень бы хотелось услышать вашу конструктивную критику, что хорошо сделано, а что стоит поправить.
С удовольствием почитаю ваши сообщения, а для особо творческих - внимательно изучу ваши pull-реквесты и, вероятнее всего, приму их.
Было бы очень круто узнать ваше мнение.
Это не в коем случае не реклама. Просто хочу развиваться, да и дальше есть план написать ещё пакеты, поэтому хотелось бы опираться на что-то проверенное и одобренное.
Всем участвующим в тестировании - большое спасибо :)
https://packagist.org/packages/ratiborro/laravel-scopes
P.S. И да, не ругайте пока, что README на русском, просто я бы не смог нормально выразить свои мысли на другом языке. Буду над этим работать :)
Возникла потребность упростить свою работу и генерировать скоупы для модели автоматизированно.
Очень долго искал, но нужного мне пакета так и не нашёл, поэтому решил написать свой.
Есть пакеты, реализующие отдалённо похожий функционал, но везде генерируются новые файлы моделей, от которых нужно наследоваться, а этот способ мне совершенно не подходит.
Так как в разработке пакетов (да и в принципе в архитектуре) не сказать, что много чего понимаю, очень бы хотелось услышать вашу конструктивную критику, что хорошо сделано, а что стоит поправить.
С удовольствием почитаю ваши сообщения, а для особо творческих - внимательно изучу ваши pull-реквесты и, вероятнее всего, приму их.
Было бы очень круто узнать ваше мнение.
Это не в коем случае не реклама. Просто хочу развиваться, да и дальше есть план написать ещё пакеты, поэтому хотелось бы опираться на что-то проверенное и одобренное.
Всем участвующим в тестировании - большое спасибо :)
https://packagist.org/packages/ratiborro/laravel-scopes
P.S. И да, не ругайте пока, что README на русском, просто я бы не смог нормально выразить свои мысли на другом языке. Буду над этим работать :)
https://laravel-idea.com
Пара-тройка кликов хоткеев и всё создано и заполнено.
Пара-тройка кликов хоткеев и всё создано и заполнено.
ИС
Connection could not be established with host smtp.mail.ru :stream_socket_client(): Unable to connect to tsl://smtp.mail.ru:465 (Unable to find the socket transport "tsl" - did you forget to enable it when you configured PHP
AH
И есть вопрос, на который я так и не смог найти ответ:
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
AH
И есть вопрос, на который я так и не смог найти ответ:
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
Что касается зависимостей - им, по сути, нет разницы где работать, если их код используется в пакете и не конфликтует с окружением.
RK
Что касается зависимостей - им, по сути, нет разницы где работать, если их код используется в пакете и не конфликтует с окружением.
Андрей, я уже видел твой пакет)
По поводу зависимостей: т.е. можно вообще не указывать зависимости пакета, если он разработан для Laravel? Потому что указывая зависимости, высок шанс напороться на то, что возникнет конфликт версий (хотя на самом деле при принудительной установке всё равно бы всё работало).
По поводу зависимостей: т.е. можно вообще не указывать зависимости пакета, если он разработан для Laravel? Потому что указывая зависимости, высок шанс напороться на то, что возникнет конфликт версий (хотя на самом деле при принудительной установке всё равно бы всё работало).
AH
Ребята, всем привет!
Возникла потребность упростить свою работу и генерировать скоупы для модели автоматизированно.
Очень долго искал, но нужного мне пакета так и не нашёл, поэтому решил написать свой.
Есть пакеты, реализующие отдалённо похожий функционал, но везде генерируются новые файлы моделей, от которых нужно наследоваться, а этот способ мне совершенно не подходит.
Так как в разработке пакетов (да и в принципе в архитектуре) не сказать, что много чего понимаю, очень бы хотелось услышать вашу конструктивную критику, что хорошо сделано, а что стоит поправить.
С удовольствием почитаю ваши сообщения, а для особо творческих - внимательно изучу ваши pull-реквесты и, вероятнее всего, приму их.
Было бы очень круто узнать ваше мнение.
Это не в коем случае не реклама. Просто хочу развиваться, да и дальше есть план написать ещё пакеты, поэтому хотелось бы опираться на что-то проверенное и одобренное.
Всем участвующим в тестировании - большое спасибо :)
https://packagist.org/packages/ratiborro/laravel-scopes
P.S. И да, не ругайте пока, что README на русском, просто я бы не смог нормально выразить свои мысли на другом языке. Буду над этим работать :)
Возникла потребность упростить свою работу и генерировать скоупы для модели автоматизированно.
Очень долго искал, но нужного мне пакета так и не нашёл, поэтому решил написать свой.
Есть пакеты, реализующие отдалённо похожий функционал, но везде генерируются новые файлы моделей, от которых нужно наследоваться, а этот способ мне совершенно не подходит.
Так как в разработке пакетов (да и в принципе в архитектуре) не сказать, что много чего понимаю, очень бы хотелось услышать вашу конструктивную критику, что хорошо сделано, а что стоит поправить.
С удовольствием почитаю ваши сообщения, а для особо творческих - внимательно изучу ваши pull-реквесты и, вероятнее всего, приму их.
Было бы очень круто узнать ваше мнение.
Это не в коем случае не реклама. Просто хочу развиваться, да и дальше есть план написать ещё пакеты, поэтому хотелось бы опираться на что-то проверенное и одобренное.
Всем участвующим в тестировании - большое спасибо :)
https://packagist.org/packages/ratiborro/laravel-scopes
P.S. И да, не ругайте пока, что README на русском, просто я бы не смог нормально выразить свои мысли на другом языке. Буду над этим работать :)
В случае с пакетом задумка интересная, вот только Laravel Idea семимильными шагами обходит конкурентов.
AH
И есть вопрос, на который я так и не смог найти ответ:
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
Тинкер - это типа cli для запуска среды. Консольные команды и без этого могут запускаться.
Если проект позиционируется для работы в симфе или глобально в композере, то следует наследоваться от symfony/console, а если он для Лары, то illuminate/console. И по другим зависимостям также. Нужно смотреть что и где используется и, в зависимости от этого, использовать то или иное технологическое решение.
Если проект позиционируется для работы в симфе или глобально в композере, то следует наследоваться от symfony/console, а если он для Лары, то illuminate/console. И по другим зависимостям также. Нужно смотреть что и где используется и, в зависимости от этого, использовать то или иное технологическое решение.
RK
Тинкер - это типа cli для запуска среды. Консольные команды и без этого могут запускаться.
Если проект позиционируется для работы в симфе или глобально в композере, то следует наследоваться от symfony/console, а если он для Лары, то illuminate/console. И по другим зависимостям также. Нужно смотреть что и где используется и, в зависимости от этого, использовать то или иное технологическое решение.
Если проект позиционируется для работы в симфе или глобально в композере, то следует наследоваться от symfony/console, а если он для Лары, то illuminate/console. И по другим зависимостям также. Нужно смотреть что и где используется и, в зависимости от этого, использовать то или иное технологическое решение.
У меня не слишком широкий кругозор, да и опыт тестирования на разных продуктах тоже, поэтому кроме как для лары я пакет ни для чего не планировал :)
1. За совет спасибо. А как определить минимальную версию той же illuminate/console, с которой будет работать?
Методом тыка?
2. И как можно запустить консольные команды Лары без artisan-а?
1. За совет спасибо. А как определить минимальную версию той же illuminate/console, с которой будет работать?
Методом тыка?
2. И как можно запустить консольные команды Лары без artisan-а?
AH
Андрей, я уже видел твой пакет)
По поводу зависимостей: т.е. можно вообще не указывать зависимости пакета, если он разработан для Laravel? Потому что указывая зависимости, высок шанс напороться на то, что возникнет конфликт версий (хотя на самом деле при принудительной установке всё равно бы всё работало).
По поводу зависимостей: т.е. можно вообще не указывать зависимости пакета, если он разработан для Laravel? Потому что указывая зависимости, высок шанс напороться на то, что возникнет конфликт версий (хотя на самом деле при принудительной установке всё равно бы всё работало).
Например, делаю пакет Х только для Лары. Допустим, его функционал запускается через консоль и вносит изменения в базу.
Это значит, что 100% должны быть в основных зависимостях указаны пакеты
Для локальной разработки и тестирования следует ставить
В случае с версиями, смотри так: если функционал, например, для версий с 5.5 по 8.0 будет одинаков и ничего не сломается, можно смело указать
Это значит, что 100% должны быть в основных зависимостях указаны пакеты
illuminate/database, illuminate/support и illuminate/console.Для локальной разработки и тестирования следует ставить
mockery/mockery, orchestra/testbench и phpunit/phpunit как минимум.В случае с версиями, смотри так: если функционал, например, для версий с 5.5 по 8.0 будет одинаков и ничего не сломается, можно смело указать
^5.5|^8.0, а если, например, до 7-й лары не будет поддерживаться, то ^7.0|^8.0, ну или сразу только для новых - ^8.0.RK
Например, делаю пакет Х только для Лары. Допустим, его функционал запускается через консоль и вносит изменения в базу.
Это значит, что 100% должны быть в основных зависимостях указаны пакеты
Для локальной разработки и тестирования следует ставить
В случае с версиями, смотри так: если функционал, например, для версий с 5.5 по 8.0 будет одинаков и ничего не сломается, можно смело указать
Это значит, что 100% должны быть в основных зависимостях указаны пакеты
illuminate/database, illuminate/support и illuminate/console.Для локальной разработки и тестирования следует ставить
mockery/mockery, orchestra/testbench и phpunit/phpunit как минимум.В случае с версиями, смотри так: если функционал, например, для версий с 5.5 по 8.0 будет одинаков и ничего не сломается, можно смело указать
^5.5|^8.0, а если, например, до 7-й лары не будет поддерживаться, то ^7.0|^8.0, ну или сразу только для новых - ^8.0.А версии `
Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...). Почему это не работает, когда пытаешься указать зависимости?
illuminate/support` и подобных всегда совпадают с версией лары?Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...). Почему это не работает, когда пытаешься указать зависимости?
AH
У меня не слишком широкий кругозор, да и опыт тестирования на разных продуктах тоже, поэтому кроме как для лары я пакет ни для чего не планировал :)
1. За совет спасибо. А как определить минимальную версию той же illuminate/console, с которой будет работать?
Методом тыка?
2. И как можно запустить консольные команды Лары без artisan-а?
1. За совет спасибо. А как определить минимальную версию той же illuminate/console, с которой будет работать?
Методом тыка?
2. И как можно запустить консольные команды Лары без artisan-а?
AH
А версии `
Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...). Почему это не работает, когда пытаешься указать зависимости?
illuminate/support` и подобных всегда совпадают с версией лары?Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...). Почему это не работает, когда пытаешься указать зависимости?
Да, всегда
AH
А версии `
Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...). Почему это не работает, когда пытаешься указать зависимости?
illuminate/support` и подобных всегда совпадают с версией лары?Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...). Почему это не работает, когда пытаешься указать зависимости?
> Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...).
Плохая идея. По такой логике и 7.0, и 8.0, и 9.0 попадут, а там функционал под капотом может быть сильно переписан, что напрочь сломает твоё приложение, поэтому стоит привязываться к минорным версиям.
В качестве примера глянь таблицы совместимости тут и тут.
Плохая идея. По такой логике и 7.0, и 8.0, и 9.0 попадут, а там функционал под капотом может быть сильно переписан, что напрочь сломает твоё приложение, поэтому стоит привязываться к минорным версиям.
В качестве примера глянь таблицы совместимости тут и тут.
RK
> Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...).
Плохая идея. По такой логике и 7.0, и 8.0, и 9.0 попадут, а там функционал под капотом может быть сильно переписан, что напрочь сломает твоё приложение, поэтому стоит привязываться к минорным версиям.
В качестве примера глянь таблицы совместимости тут и тут.
Плохая идея. По такой логике и 7.0, и 8.0, и 9.0 попадут, а там функционал под капотом может быть сильно переписан, что напрочь сломает твоё приложение, поэтому стоит привязываться к минорным версиям.
В качестве примера глянь таблицы совместимости тут и тут.
Понимаю эту логику, но часто это приводит к тому, что многие пакеты становятся недоступны после выхода новой версии той же лары, потому что некоторые разработчики не обновляют composer.json своего пакета.
AH
Понимаю эту логику, но часто это приводит к тому, что многие пакеты становятся недоступны после выхода новой версии той же лары, потому что некоторые разработчики не обновляют composer.json своего пакета.
И это правильно, так как разработчикам нужно вначале протестить заработает ли их приложение на новой версии Лары.
В этом случае есть четыре пути:
1. Заработало без правок кода: просто обновляем
2. Заработало с небольшими правками кода: вносим корректировки, обновляем
3. Не заработало и нужны большие правки: рефакторим проект под новую версию. Если она совместима с предыдущими версиями (обратная совместимость не нарушена), то релизим минорную версию;
4. Не заработало и нужны большие правки: рефакторим проект под новую версию. Если она НЕ совместима с предыдущими версиями (обратная совместимость нарушена), то релизим мажорную версию, убрав из
В этом случае есть четыре пути:
1. Заработало без правок кода: просто обновляем
composer.json и релизим новую версию;2. Заработало с небольшими правками кода: вносим корректировки, обновляем
composer.json и релизим новую версию в виде патча или минор, в зависимости от количества правок);3. Не заработало и нужны большие правки: рефакторим проект под новую версию. Если она совместима с предыдущими версиями (обратная совместимость не нарушена), то релизим минорную версию;
4. Не заработало и нужны большие правки: рефакторим проект под новую версию. Если она НЕ совместима с предыдущими версиями (обратная совместимость нарушена), то релизим мажорную версию, убрав из
composer.json неподдерживаемые версии.AH
Понимаю эту логику, но часто это приводит к тому, что многие пакеты становятся недоступны после выхода новой версии той же лары, потому что некоторые разработчики не обновляют composer.json своего пакета.
Поэтому заведомо разрешать пакету работать на будущих версиях без проверки - плохой путь. От таких пакетов, обычно, адекватные люди держатся подальше, т.к. хер его знает что их разработчик ещё отчебучит.