Size: a a a

Laravel для начинающих

2021 March 09

ВШ

Виталий Шутов... in Laravel для начинающих
Вані4ка Луціашвілі
Как и в логах самого проектв
Так не бывает
источник

ВШ

Виталий Шутов... in Laravel для начинающих
Либо в лог сервера, либо перехват в лог laravel
источник

RK

Ratibor Korobin in Laravel для начинающих
Ребята, всем привет!

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

Так как в разработке пакетов (да и в принципе в архитектуре) не сказать, что много чего понимаю, очень бы хотелось услышать вашу конструктивную критику, что хорошо сделано, а что стоит поправить.
С удовольствием почитаю ваши сообщения, а для особо творческих - внимательно изучу ваши pull-реквесты и, вероятнее всего, приму их.

Было бы очень круто узнать ваше мнение.
Это не в коем случае не реклама. Просто хочу развиваться, да и дальше есть план написать ещё пакеты, поэтому хотелось бы опираться на что-то проверенное и одобренное.
Всем участвующим в тестировании - большое спасибо :)

https://packagist.org/packages/ratiborro/laravel-scopes

P.S. И да, не ругайте пока, что README на русском, просто я бы не смог нормально выразить свои мысли на другом языке. Буду над этим работать :)
источник

RK

Ratibor Korobin in Laravel для начинающих
И есть вопрос, на который я так и не смог найти ответ:
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
источник

AH

Andrey Helldar in Laravel для начинающих
Ratibor Korobin
Ребята, всем привет!

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

Так как в разработке пакетов (да и в принципе в архитектуре) не сказать, что много чего понимаю, очень бы хотелось услышать вашу конструктивную критику, что хорошо сделано, а что стоит поправить.
С удовольствием почитаю ваши сообщения, а для особо творческих - внимательно изучу ваши pull-реквесты и, вероятнее всего, приму их.

Было бы очень круто узнать ваше мнение.
Это не в коем случае не реклама. Просто хочу развиваться, да и дальше есть план написать ещё пакеты, поэтому хотелось бы опираться на что-то проверенное и одобренное.
Всем участвующим в тестировании - большое спасибо :)

https://packagist.org/packages/ratiborro/laravel-scopes

P.S. И да, не ругайте пока, что README на русском, просто я бы не смог нормально выразить свои мысли на другом языке. Буду над этим работать :)
https://laravel-idea.com
Пара-тройка кликов хоткеев и всё создано и заполнено.
источник

ИС

Игорь Спутник... in Laravel для начинающих
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

Andrey Helldar in Laravel для начинающих
Ratibor Korobin
И есть вопрос, на который я так и не смог найти ответ:
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
источник

AH

Andrey Helldar in Laravel для начинающих
Ratibor Korobin
И есть вопрос, на который я так и не смог найти ответ:
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
Что касается зависимостей - им, по сути, нет разницы где работать, если их код используется в пакете и не конфликтует с окружением.
источник

RK

Ratibor Korobin in Laravel для начинающих
Andrey Helldar
Что касается зависимостей - им, по сути, нет разницы где работать, если их код используется в пакете и не конфликтует с окружением.
Андрей, я уже видел твой пакет)

По поводу зависимостей: т.е. можно вообще не указывать зависимости пакета, если он разработан для Laravel? Потому что указывая зависимости, высок шанс напороться на то, что возникнет конфликт версий (хотя на самом деле при принудительной установке всё равно бы всё работало).
источник

AH

Andrey Helldar in Laravel для начинающих
Ratibor Korobin
Ребята, всем привет!

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

Так как в разработке пакетов (да и в принципе в архитектуре) не сказать, что много чего понимаю, очень бы хотелось услышать вашу конструктивную критику, что хорошо сделано, а что стоит поправить.
С удовольствием почитаю ваши сообщения, а для особо творческих - внимательно изучу ваши pull-реквесты и, вероятнее всего, приму их.

Было бы очень круто узнать ваше мнение.
Это не в коем случае не реклама. Просто хочу развиваться, да и дальше есть план написать ещё пакеты, поэтому хотелось бы опираться на что-то проверенное и одобренное.
Всем участвующим в тестировании - большое спасибо :)

https://packagist.org/packages/ratiborro/laravel-scopes

P.S. И да, не ругайте пока, что README на русском, просто я бы не смог нормально выразить свои мысли на другом языке. Буду над этим работать :)
В случае с пакетом задумка интересная, вот только Laravel Idea семимильными шагами обходит конкурентов.
источник

AH

Andrey Helldar in Laravel для начинающих
Ratibor Korobin
И есть вопрос, на который я так и не смог найти ответ:
Как правильно определить зависимости своего пакета, если я пишу пакет на Laravel?
Без самой экосистемы Laravel, по идее, это всё равно не работает, потому что, например, консольные команды Laravel запускаются через artisan.
Тинкер - это типа cli для запуска среды. Консольные команды и без этого могут запускаться.
Если проект позиционируется для работы в симфе или глобально в композере, то следует наследоваться от symfony/console, а если он для Лары, то illuminate/console. И по другим зависимостям также. Нужно смотреть что и где используется и, в зависимости от этого, использовать то или иное технологическое решение.
источник

RK

Ratibor Korobin in Laravel для начинающих
Andrey Helldar
Тинкер - это типа cli для запуска среды. Консольные команды и без этого могут запускаться.
Если проект позиционируется для работы в симфе или глобально в композере, то следует наследоваться от symfony/console, а если он для Лары, то illuminate/console. И по другим зависимостям также. Нужно смотреть что и где используется и, в зависимости от этого, использовать то или иное технологическое решение.
У меня не слишком широкий кругозор, да и опыт тестирования на разных продуктах тоже, поэтому кроме как для лары я пакет ни для чего не планировал :)

1. За совет спасибо. А как определить минимальную версию той же illuminate/console, с которой будет работать?
Методом тыка?

2. И как можно запустить консольные команды Лары без artisan-а?
источник

AH

Andrey Helldar in Laravel для начинающих
Ratibor Korobin
Андрей, я уже видел твой пакет)

По поводу зависимостей: т.е. можно вообще не указывать зависимости пакета, если он разработан для Laravel? Потому что указывая зависимости, высок шанс напороться на то, что возникнет конфликт версий (хотя на самом деле при принудительной установке всё равно бы всё работало).
Например, делаю пакет Х только для Лары. Допустим, его функционал запускается через консоль и вносит изменения в базу.
Это значит, что 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

Ratibor Korobin in Laravel для начинающих
Andrey Helldar
Например, делаю пакет Х только для Лары. Допустим, его функционал запускается через консоль и вносит изменения в базу.
Это значит, что 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.
А версии `illuminate/support` и подобных всегда совпадают с версией лары?

Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...). Почему это не работает, когда пытаешься указать зависимости?
источник

AH

Andrey Helldar in Laravel для начинающих
Ratibor Korobin
У меня не слишком широкий кругозор, да и опыт тестирования на разных продуктах тоже, поэтому кроме как для лары я пакет ни для чего не планировал :)

1. За совет спасибо. А как определить минимальную версию той же illuminate/console, с которой будет работать?
Методом тыка?

2. И как можно запустить консольные команды Лары без artisan-а?
1. Консоль у них, как правило, не менялась в критическом плане версии с 5.5, так что, по сути, любую вызывай.

2. В случае пакета так просто их нельзя запустить - только в рамках теста. Может помочь это и это.
источник

AH

Andrey Helldar in Laravel для начинающих
Ratibor Korobin
А версии `illuminate/support` и подобных всегда совпадают с версией лары?

Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...). Почему это не работает, когда пытаешься указать зависимости?
Да, всегда
источник

AH

Andrey Helldar in Laravel для начинающих
Ratibor Korobin
А версии `illuminate/support` и подобных всегда совпадают с версией лары?

Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...). Почему это не работает, когда пытаешься указать зависимости?
> Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...).

Плохая идея. По такой логике и 7.0, и 8.0, и 9.0 попадут, а там функционал под капотом может быть сильно переписан, что напрочь сломает твоё приложение, поэтому стоит привязываться к минорным версиям.

В качестве примера глянь таблицы совместимости тут и тут.
источник

RK

Ratibor Korobin in Laravel для начинающих
Andrey Helldar
> Читал, что для пакетов можно просто указывать >5.5 (чтобы не писать ^5.5|^6|^7...).

Плохая идея. По такой логике и 7.0, и 8.0, и 9.0 попадут, а там функционал под капотом может быть сильно переписан, что напрочь сломает твоё приложение, поэтому стоит привязываться к минорным версиям.

В качестве примера глянь таблицы совместимости тут и тут.
Понимаю эту логику, но часто это приводит к тому, что многие пакеты становятся недоступны после выхода новой версии той же лары, потому что некоторые разработчики не обновляют composer.json своего пакета.
источник

AH

Andrey Helldar in Laravel для начинающих
Ratibor Korobin
Понимаю эту логику, но часто это приводит к тому, что многие пакеты становятся недоступны после выхода новой версии той же лары, потому что некоторые разработчики не обновляют composer.json своего пакета.
И это правильно, так как разработчикам нужно вначале протестить заработает ли их приложение на новой версии Лары.

В этом случае есть четыре пути:

1. Заработало без правок кода: просто обновляем composer.json и релизим новую версию;
2. Заработало с небольшими правками кода: вносим корректировки, обновляем composer.json и релизим новую версию в виде патча или минор, в зависимости от количества правок);
3. Не заработало и нужны большие правки: рефакторим проект под новую версию. Если она совместима с предыдущими версиями (обратная совместимость не нарушена), то релизим минорную версию;
4. Не заработало и нужны большие правки: рефакторим проект под новую версию. Если она НЕ совместима с предыдущими версиями (обратная совместимость нарушена), то релизим мажорную версию, убрав из composer.json неподдерживаемые версии.
источник

AH

Andrey Helldar in Laravel для начинающих
Ratibor Korobin
Понимаю эту логику, но часто это приводит к тому, что многие пакеты становятся недоступны после выхода новой версии той же лары, потому что некоторые разработчики не обновляют composer.json своего пакета.
Поэтому заведомо разрешать пакету работать на будущих версиях без проверки - плохой путь. От таких пакетов, обычно, адекватные люди держатся подальше, т.к. хер его знает что их разработчик ещё отчебучит.
источник