CLI интерфейс для Laravel Artisan

    Хочу представить composer-пакет для Laravel, возможно кому-то придётся по душе.

    Суть проще показать, чем объяснять.

    image

    Кого заинтересовало — прошу под кат.

    А зачем?


    А почему бы и нет? Я, например, пришёл к этой мысли после того как в очередной раз забыл как правильно — «make:migration» или «migration:make» или может совсем какое-то «create:migration». Вот ей богу, каждые несколько дней приходится создавать эти миграции, а я всё равно не всегда помню название команд! А уж о каких-нибудь «config:clear», которые используются крайне редко — так вообще молчу.

    Это раз. А два — мне всегда нравились консольные интерфейсы. Есть в них что-то эдакое. Поэтому решил совместить приятное с полезным.

    А какие команды поддерживаются?


    Абсолютно все, которые работают через стандартный artisan, потому как я использую те же классы что и он. Ну, это в теории :) На практике пока проблем не встречал, но уверен что более широкая аудитория с чем-то да столкнётся.


    Кастомные команды в моём проекте

    А я не люблю синюю консоль


    No problem, цвета и размеры настраиваются в файле config/artisanui.php. Главное не забудьте сделать config:cache после изменений.

    Уговорил, как попробовать?


    Да вот тут github.com/VladReshet/ArtisanUI, собственно, всё написано. Поставил пакет, добавил сервис провайдер в config/app.php, запаблишил его — готово, можно пробовать.

    А что под капотом?


    А под капотом вот эта прелесть github.com/php-school/cli-menu. Надеюсь авторы найдут время допилить следующий релиз.

    А на сколько стабильно?


    На «свежем» laravel, только установленном — проверял все пункты стандартного artisan, всё работает. Со зрелыми проектами — ну, должно работать, а там, если что, issues на гитхабе всё покажут) В любом случае это решение скорее для локальной разработки, чем для использования в продакшн.

    Ну и ещё несколько скриншотов напоследок:





    Комментарии, конструктивные замечания, рекомендации — приветствуются. Даже если никто не заинтересуется — это был интересный процесс скрещивания ежа с ужом копания в исходниках Laravel :)
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 26

      0
      так как временно я использую нестабильную версию нужной мне зависимости

      Форкнуть зависимость, в своем репозитории тегнуть релиз, в composer.json в разделе "repositories" указать свой репозиторий "type": "vcs"

        0
        Если бы зависимость была заброшенной — то я бы так и сделал. А так я связался с контрибьютором — он говорит всё доделаем, правда не знаю точно когда. Ну я и решил что смысл эти костыли с форками городить.
        0

        А PHP точно ваш основной язык программирования? Потому что так вывернуть логику с ног на голову это еще надо постараться. Особенно передача $this как $self, зачем, куда, почему, попробуй разберись.
        Интересно, с Симфони консоль работать будет, у них АПИ достаточно схожи.

          +1
          Точно. Насчёт this — там не обычные замыкания, контекст this в них теряется, поэтому и добавлен «костыль» в виде self. Да и API библиотеки не очень позволяет писать «линейно». Это раз. Во-вторых, это скорее рабочий прототип, чем окончательная архитектура. Если людям библиотека зайдёт — обязательно придётся рефакторить. Ну а пока что так. В любом случае, буду рад посмотреть на более изящное решение.
              0
              Не спорю. Но если посмотреть историю коммитов, видно что это своего рода прототип, сделанный за день. Если «взлетит» — будет рефакториться. По этой же причине и тестов нет. Ну в конце то концов, вы же не думаете что у меня хватает навыков разобраться во внутренней структуре ларавеля, но не хватает ума на зависимости, и избегания лапши?) Вот только за ...$args согласен, редко приходится его использовать, упустил из виду
            0
            Вы знаете, посмотрел сегодня на код свежим взглядом — действительно, легко обойтись без $self. Спасибо.
              +1

              В целом стало конечно лучше, и понятней. Единственное что я сходу заметил это то что функция getItemsGroupClosure скорее всего не используется, buildItem до сих пор вызывает сомнения, использование Fluent interface и в некоторых местах отсутствие phpdoc, особенно так где используются массивы.
              А так, в целом, верной дорогой идете )

                0
                С getItemsGroupClosure и buildItem согласен — даже поправил уже) А вот по Fluent interface и phpdoc — есть вопросы. Какая проблема в текучести конкретно в данном случае? А phpdoc — так там нигде нет phpdoc, там тайпхинтинги..) А где именно не хватает?)
                  0

                  Нет тайпхинта:
                  https://github.com/VladReshet/ArtisanUI/blob/master/src/Artisanui.php#L85
                  https://github.com/VladReshet/ArtisanUI/blob/master/src/Artisanui.php#L102
                  Нет пхпдок для массива, с информацией о том что в нем находится:
                  https://github.com/VladReshet/ArtisanUI/blob/master/src/Artisanui.php#L215


                  Текучий интерфейс можно использовать для билдеров, которые наполняют ДТО, и выдают на выходе уже готовый класс, но не для действий которые должны выполняться друг за другом.
                  Об этом уже много статей написано, не вижу смысла их повторять.
                  Ну и я не думаю что тут стоит хранить состояния объекта, в нем самом, и поля типа title можно не использовать, или получать их через DI, а не через config()

                    0
                    Хмм, резонно. Поправлю. Спасибо за халявный код-ревью)
                      0

                      Да без проблемм, всегда рад помочь.

            0

            В своё время начал писать что-то похожее, но вовремя наткнулся на баш-автокомплит для компонента symfony/console
            Artisan им тоже поддерживается. Так что, когда забываю команду, tab мне в помощь

            0
            Я правильно понимаю, что для асинхронного ввода-вывода в консоль используется расширение POSIX и на винде работать не будет? Если да, то наверное стоит об этом упомянуть в readme
              0
              На винде PHP не держу, надо пробовать.

                0
                винда в пролете, так как vladreshet/cli-menu использует ext-posix, который:

                Note: This extension is not available on Windows platforms.
              –1
              копия проекта github.com/DivineOmega/artisan-menu
                –1
                Не видел этот проект, хотя искал. Были мысли что не мог до этого кто-то уже не дойти. Так оно и получилось.

                Но, прошу не называть мой проект копией. Во-первых код абсолютно разный, я не видел тот проект до сегодняшнего дня. А во-вторых, мой проект более функционален, потому как DivineOmega/artisan-menu не поддерживает опциональные параметры.

                artisan down
                Мой пакет предлагает выбрать опции, ivineOmega/artisan-menu просто выполняет artisan down

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое