Как стать автором
Обновить

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

Чем дальше в лес, тем сложнее поддерживать проекты на Laravel в актуальном состоянии. То некоторые компоненты не позволяют обновиться — приходится временно форкать, решать проблемы совместимости и ждать когда примут PR. То приоритеты насущных задач не позволяют переключиться на обновление.

Так, на одном проекте 5.1 и как с нее переходить на 5.4 я уже ума не приложу. Работы явно не на 1 день. А ведь поддержка LTS 5.1 прекращается уже в июне 2017 года…

Тейлор отказался от идеи LTS в принципе, насколько я знаю. Так что 5.1 — последняя LTS версия.

Вот я тоже гуглю и не могу найти. Везде упоминается, что 5.5 будет следующей версией с LTS. При чем выпуск планируется как я и писал — в июне 2017 года.

Хм, значит, не правильно понял. :)

Да.

Ну с одной стороны я согласен, LTS билды мешают сосредоточиться на постоянном улучшении кодовой базы в новых версиях, а так же поощряют пользователей оставаться на "старом добром работает — не трожь" и как следствие — дальнейшее обновление (после окончания поддержки LTS и появления нового) может окончиться болью.


Но с другой стороны LTS необходим, т.к. зачастую в современной практике важнее стартануть продукт и навешать свистоперделок, вместо полноценной поддержки и обновления оного. Заодно и для крупных вендоров (ну т.е. компаний) невозможно без LTS обходиться.


Так что это палка о двух концах. Имхо, стоит выпускать LTS но с менее продолжительным жизненным циклом и чуть большим количеством оных.

Ещё вот это порадовало:


Он вообще такой интересный.
Вот тут можно проследить интересную логику: https://twitter.com/search?f=tweets&vertical=default&q=LTS%20from%3Ataylorotwell&src=typd


LTS is sort of an anti-pattern IMO.

I am not a fan of LTS in general. Prefer people take a couple days per year to stay updated

А до этого:


Forge currently designed for 14.04 LTS… will update to 16.04 LTS when its available

А чего ж не 14.10, 15.04, 15.10? Хорошо же несколько дней в году тратить на обновления! Быть на острие! Тем более когда LTS — антипаттерн!

Охренеть.

Вы что-то делаете не так, буквально месяца 3 назад проект перенёс с 5.1 на 5.3 и проблем никаких не было. Возможно, по той причине, что использовались преимущественно стандартные библиотеки, а не стандартные были заменены на стандартные в процессе переноса.
Ну как минимум, админка требует полного переписывания, т.к. нужно переходить с https://github.com/sleeping-owl/admin на https://github.com/LaravelRUS/SleepingOwlAdmin. Все бы ничего, но в процессе работы добавилось очень много кастомных типов ввода данных: автокомплит, другой визуальный редактор, разметка телефонов, seo поля, редактор json полей. Да, я могу в процессе обновления это все разом переписать — но кто мне за это заплатит? Да, я могу ничего не делать и просто обновить оставив стандартные поля ввода — но как на меня посмотрят клиенты? Так что проект-проекту рознь.
Не используем автоматических генераторов, да даже если бы и использовали — есть смысл обратить внимание на voyager. Админка в моём понимании — это обычный crud и это всё генерится прямо из консоли artisan без особых проблем.
Хрен редьки не слаще. В указанном вами CRUD абсолютно те же поля, что есть по умолчанию в SleepingOwl. При этом встраивание своих контроллеров и редактирование полиморфных связей под вопросом (я имею в виду возможны те же грабли при обновлении).

IMHO, в Вашем случае лучше всего дождаться поддержки Совой новой версии Laravel и только тогда апгрейдиться, чем делать это вслепую.

Пока ближайшее обновление запланировано после релиза Laravel 5.5. И это если Тейлор не откажется от LTS. В противном же случае будем будем взвешивать все за и против продолжения использования этого фреймворка в проекте.

как мне кажется, в вашем случае zend или symfony подойдут гораздо лучше
учитывая родство симфони и лары — симфони подойдет даже больше

Под CRUD подразумевал встроенные генераторы классов, не нужно смешивать мелкое с мягким. Пока Вы мне пытались доказать правильность своих решений и не правильность выбора наших. Мы обновились, сели в локомотив 5.4 и поехали дальше, чего и Вам желаю.
Боже упаси вам что-то чего-то доказывать. Просто проект проекту-рознь. А генераторы классов != CRUD в априори. При этом взяв любой компонент за основу для разработки админки, проблем нет ровно до тех пор, пока не возникает необходимости дорабатывать эту самую админку нестандартными решениями и выводами.

На простых проектах обновления протекают достаточно безболезненно — сел в локомотив и поехал дальше.
Тут я имею в виду формы редактирования/добавления данных стандартных форматов

Но на проектах с более сложной архитектурой такой фокус уже не проходит



Поэтому приходится балансировать между скоростью разработки и поддержанием версий в актуальном состоянии. Если бы админка писалась полностью под проект без всяких CRUD — мы бы уже давно обновились. Но вы же должны понимать, что на такой проект потребуется несколько больше времени…

Возьмем еще один пример: laravelrus/localized-carbon. Отличный компонент, думаю многие им пользуются. Но увы, без вот этого патча локомотив не тронется даже в рамках 5.1 версии. Или вы предлагаете вообще все писать самостоятельно?
Такого же уровня админка (еще не завершенная), но созданная без генераторов
Небольшой гос проект


Есть в том числе и модалки со вкладками и есть отдельная Модерка на лицевой странице сайта, на тех же контроллерах. Разница, как мне кажется, только в выборе пути развития проекта. Вы пошли одним путём — мы пошли другим (возможно более трудным).

Формы подобного вида я и охарактеризовал как типовые

Сколько с Laravel ни работал, всегда чувствовал что 5.1 нифига не LTS, так как он сам по себе сырой. Всегда приходилось новые проекты на последней версии Laravel начинать.
Странная политика, вроде фреймворку уже много лет и пора взрослеть.
Без LTS ларе не захватить вкусный корпоративный (и консервативный) сектор, так и останется хипстерской игрушкой.
Госспади, какой ужас…
Вот весь ларавель это костыли и подпорки вместо того чтобы чуток почитать сложные места документации симфони.
Наплодить столько кривых решений это надо уметь, но похоже сейчас markdown в письмах получает премию за самый кривой костыль.
Все фреймворки, кроме Simfony — УГ? :)
Где-то есть нормальное сравнение фреймворков?
Нет конечно, претензии восновном к ларавелю. Из ларавеля торчат уши симфони очень сильно — взяли компоненты симфони которые очень легко использовать, а те которые использовать сложнее потому что они довольно мощные заменили на свое, причем это свое получилось скажем так не очень. Из примеров — Eloquent, Blade и фасады.
Twig с блоками и Blade со слотами — это прям как из анекдота про немца, русского, украинца и сраку :)
Вот точно :)
Интересно, они починили блейд?
https://habrahabr.ru/post/238017/#comment_8316215
А чего минусите-то? Пользователи Twig и Blade не согласны в «разности» шаблонизаторов? Или кого-то оскорбила срака?
Тут боевой отряд хомячков Тейлора прибежал :)

Я не минусил, но сравнение совершенно неверное. Альтернатива блоков в симфони — это секции блейда. Для слотов же альтернатива в твиге — это macro, и то с большой натяжкой.

А embed это не оно?

Ну ок, слоты — это embed + macro.


Просто сравнивать Blade с Twig крайне не корректно. Blade создан для разработчиков, как доп.возможности для php. А Twig — это абстракция над языком с полным разбором токенов, построением AST (могу заблуждаться в деталях, не все сырцы просматривал) и прочее-прочее.


Это как сравнивать Doctrine и Eloquent и вопрошать "зачем?!!11". Одно DataMapper, другое ActiveRecord. Разные подходы, идеи и цели.


Понятно, что будут пересечения в возможностях, но концепции разные.

Но Laravel, афаик, — самый трендовый фреймворк 2016 года. :)
Ну так виндовс вон тоже самая популярная система, так что же теперь.

Какой в симфони аналог Eloquent? Doctrine? так это отдельный продукт, а для Blade? Twig? Так и это другой продукт, может быть в симфони есть "фасады"? так такого там вообще нет. Может вам стоит разобраться в теме, а не делать пустые вбросы?

Ну фасады — это просто красивый способ избавиться от симфонийской сервис локации $container->get, так что можно сказать, что да, это аналог, только чуть более элегантный.

Это красивый способ? Да он же создает кучу псевдо-статических классов и ломает автокомплит, и это при том что с пятой версии DI стал вполне себе нормальным.
Для этого «красивого способа» уже приделали стандартный костыль, без которого вообще ад.

На вкус и цвет. Лично я против, как фасадов, так и сервис локации. Но. Автокомплит есть (достаточно плагин подключить или пакет поставить). А шансов ошибиться в алиасе или судорожно вспоминать какое у него там название, исследуя services.yml из десятков бандлов на порядок меньше. Плюс статический доступ к элементу контейнера на порядок повышает профитность REPL (это, признаться, единственное место где фасады нужны, имхо).

А шансов ошибиться в алиасе или судорожно вспоминать какое у него там название, исследуя services.yml из десятков бандлов на порядок меньше.

*конечно же я имел ввиду что шанс ошибиться выше, а не меньше. Опечатался.

Это такой себе аргумент. IDE уже давно все автокомплитит, причем с учетом типов.


Лично я больше рассматриваю эти фасады как антипаттерн, который позволяет разработчикам обращаться к сервисам из мест, абсолютно для этого не предназначенных. Поощряет написание лапши, имхо.

Лично я против, как фасадов, так и сервис локации.

А что Вы используете? :)
Можно примеры, почему за и против? :)

Спасибо.

Я не автор, но я против статики, потому что это неявные зависимости. Я за внедрение зависимостей через конструктор.

Опять та же самая ошибка (самая популярная, наверное) =)


Фасады, в контексте Laravel — это не статика. Это статический прокси на элемент (объект, не класс) контейнера. По-факту там совершенно пустой класс у которого есть лишь пометка-ссылка на элемент контейнера. Отсюда и моё сравнение с сервис-локацией, популярной раньше в симфони.

Подумайте почему "популярной раньше" и почему от этого ушли.
Вот добавили вы вызов Auth:user() в своем классе и… все, по публичному контракту вашего класса я никогда не узнаю что он поломается в консоли, потому как сессии нету.


зы. Если я не прав, укажите в чем

А кто говорит, что от этого ушли? Ядро Symfony до сих пор напичкано этим. Но это не значит что нет более профитных инструментов, которые появились в symfony 2.8 (намёк на автовайринг). С таким же успехом можно говорить: "вот вы отнаследовались от базового симфонёвого контроллера и… ну и т.д. ваши слова.)


Это просто значит, что это хоть и есть в ядре и хоть это облегчает порог входа, более того — даже в доках примеры есть (как в симфони, так и в ларке) но эти решения не есть истина в последней инстанции и грамотные разрабы всегда предпочтут DI сервис локации.


По-этому и говорю, что "популярной раньше", так же как были популярны раньше фасады в ларке. Просто удобных альтернатив не было.

Это не напичкано, это просто один базовый контроллер от которого совсем не обязательно наследоваться. Как раз создан для вот такой вот кучки хелперов, которые удобны в небольших проектах.

А фасады в ларавеле умудрились сделать из DI фактически статику по использованию со всеми ее проблемами.

В симфони этим тоже многие страдают, но только не через фасады, а через запрос контейнера, и вызова нужных сервисов уже внутри класса, а не через DI.

В ларке есть совершенно чудесный DI с инжектами как в конструктор, так и в методы. При этом, у каждого "фасада" есть интерфейс, который висит в Contracts. Как следствие
1) фасады, либо для тех, кто осознаёт риск, но иногда проще и профитнее их запилить, вместо создания тучи сервисных классов
2) либо для новичков, которые пока не изучили механизм внедрения и сам контейнер


С фасадами


public function some()
{
    return \Config::get('some.any', 23);
}

С двойной диспатчеризацией


// RepositoryInterface == Illuminate\Illuminate\Contracts\Config\Repository
public function some(RepositoryInterface $config)
{
    return $config->get('some.any', 23);
}

С инжектом в конструктор


public function __contruct(RepositoryInterface $config)
{
    $this->config = $config; // А в методе some просто получаем объект
}

В случае 2 и 3 достаточно указать интерфейс — ларка сама всё пробросит (во отличие от симфони, где надо прописывать автовайринг и проч).

во отличие от симфони, где надо прописывать автовайринг и проч

* в отличии (очепятался, простите)


По сути: Это не плохо. Можно в любой момент увидеть что куда улетает, пробежавшись по конфигам (services.yml). Но это не так удобно. Т.е. и плюс большой и минус.

Вы правы, фасады это не статика. Это классический сервис-локатор.
И правильнее пример переписать так:


public function some()
{
    return $this->serviceLocator->get('some.any', 23);
}

В этом нет ничего сильно криминального за исключением того, что это крайне сильно повышает связанность кода.


Также лично я никогда не понимал радостей внедрения зависимостей прямо в методы. Это несколько нелогично перемешивать зависимости (которые могут меняться, добавляться и убираться) и аргументы — нет стабильного интерфейса.

Ну я приводил пример с фасадом, чтобы потом привести два других примера "как от них отказаться и начать жить". Радость же с внедрениями в метод просты:
1) Облегчается инциализация объекта (уменьшается список зависимостей в конструкторе)
2) Видно какие зависимости требует сам класс, а какие сам метод — это крайне актуально при тестировании и на порядки его упрощает
3) Позволяет реализовывать факторные методы, вместо написания самой фектори
4) Просто в некоторых местах удобнее


Можно рассмотреть простой пример. Как работают консольные скрипты в симфони:
1) Если мы хотим использовать православный DI — добавляем инжект в конструктор нужных сервисов и радуемся.
НО:
а) Набертся штук 30 таких скриптов и старт консоли превратится в муку, особенно из дев. режима с пересбором контейнера по несколько секунд
б) Если мы решим что-то инициализировать в этом конструкторе (ну, допустим соединение к БД указать другое) — нужно помнить, что эта иницализация отразится на всех существующих скриптах в проекте


Вывод: Надо получать либо через сеттер, либо через сервис-локацию в методе execute. И то, и другое, объективно, не очень. Но живём.


Пример с Laravel приводить нужно с DI в метод выполнения скрипта, вместо конструктора?


Ну и да, никто не мешает НЕ ломать интерфейс, даже используя DD. Но согласен, есть такие места, где так не прокатывает в Laravel. Боль.

  1. Никто вас не заставляет наследовать все ваши команды от общего предка с жестко заданным конструктором. Вы можете кажду команду зарегистрировать отдельным сервисом только с нужными ему зависимостями. А значит поменять конект в одной команде вообще не проблема.


  2. Я не представляю насколько огромным должен быть проект, чтобы в дев режиме сборка контейнера была проблемой. Поделитесь ссылочкой чтоли (зы. сборка медленная потому что ямл парсер который идет с симфоны написан на пыхе. Всегда можно поставить pecl расширение для парсинга ямлов и допилить на его основе свой ридер. Симфони позволяет это сделать без проблем)
Там не в парсере дело, а в том, что при вызове консоли приложение регистрирует ВСЕ команды из ВСЕХ бандлов принудительно (и не лениво в данный момент). Если команд действительно много — это может стать проблемой. Но я до такого пока не доходил. В принципе всегда можно оформить PR с фиксом этой фичи, я например не вижу никакой принципиальной проблемы сделать их ленивыми сервисами или инициализировать лениво через замыкания

А ещё можно сделать так, чтобы в команде был сервис-локатор, из которого бы лениво подгружался единственный объект и выполнялся — вынести всю логику из команды. По факту, это будет то же самое, о чём сейчас и говорим в ларавеле. В данном случае сервис локатор будет выступать в роли фабрики — и не более.


Только одно дело — применять эти фасады (как и сервис-локаторы) в контроллерах и командах, а другое — погружать их куда-нибудь далеко-далеко в бизнес логику.

Есть еще и возможность напрямую обратиться к DI что чаще всего я и делаю, если объект из DI используеться только в этом методе.

public function some()
{
return app('config')->get('some.any', 23);
}

Это такая же сервис-локация сквозь функцию-хелпер, которая дёргает контейнер ядра (т.е. тот, который зарегистрирован как синглтон). Ничем не лучше фасадов, а может даже хуже.

Вот именно что доктрина и твиг это отдельные проекты, потому что очень хорошие проекты, и можно их использовать, а не лепить свои кривейшие поделки (Eloquent и Blade).
А может в симфони фасады нафиг не нужны? Не задумывались над этим? В ларавеле они кстати тоже нафиг не нужны, потому что DI вполне нормальный, но нет, прикрутили.
Этот ваш ларавель уже оброс костылями для подключения доктрины, твига и до кучи хелперами для хоть какой-то подсветки этих ваших фасадов и элоквента.

Чем Eloquent плох? Можно конкретики? А то всё "кривой-кривой", а аргументов 0.

В Eloquent слишком много магии, из-за которых порой возникают очень странные ошибки, которые не мог предусмотреть сам создатель.
Вот например, что случилось после недавнего неожиданного обновления laravel 4.2: https://www.reddit.com/r/laravel/comments/5cgih9/too_much_magic_in_laravel/
Тейлор в итоге выпустил новую версию, где откатил эти изменения.


Также там много чего намешано, что нарушает принцип MVC. За примером далеко ходить не надо:


$users = DB::table('users')->paginate(15);

Если же появится желание использовать Eloquent отдельно от Laravel, придётся увидеть на первый взгляд странную инициализацию, т.к. выяснится, что для полной работы eloquent нужны illuminate события — на них завязаны события eloquent вроде saving и прочего. Кому-то, возможно, удобно отправлять и обрабатывать события ORM через менеджер событий вместе со всеми остальными событиями приложений. Но лично для меня это бардак.


Недавно я делал простенький проект — собирал из компонентов symfony и прочих библиотек и решил в качестве шаблонизатора использовать привычный blade. И я отказался от этой идеи, увидев сколько всего он за собой тянет, включая эти сраные события (видимо для обработки composer-ов) и хелперы Illuminate\Support, которые не будут работать у меня из-за отсутствтия остальных частей Laravel.


На самом деле и Eloquent очень даже удобен в использовании (особенно конструктор запросов), но надо иметь ввиду следующие факты:


  1. Много магии, которая порой выстреливает в разработчика.
  2. Порой нарушаются принципы MVC и SOLID, что иногда мешает что-то сделать кастомное.
  3. Эти библиотеки крайне сильно завязаны на Laravel и не сильно то модульные.

Потому критика Eloquent вполне обоснована.

Эти библиотеки крайне сильно завязаны на Laravel и не сильно то модульные.

Они и не подразумевались как модульные. Но, думаю, через пару версий станут (судя по тому, что Tinker вынесли в отдельный модуль).


Но в целом мысль Ваша понятна.

А могли бы конкретные примеры привести? С симфони плотно не работал поэтому интересно. И почему markdown в письмах это костыль?
Ну вот сейчас скачал это чудо посмотреть.
Скачались базовые компоненты симфони в зависимостях. К ним написаны обертки, которые по сути проксируют вызовы и добавляют фасады.
А потом у нас появляются статьи как прикрутить доктрину к ларавелю. Зачем нужно было использовать такой кривой велосипед как Eloquent?
Потом, посмотрите на папку Illuminate — там либо как в случае базовых компонентов идет extend Symfony либо творчество уровня студента —
Illuminate\Config например, конечно, симфоневый конфиг это сложно
роутинг — обвязка над симфоневым, и кеширование выдрано с мясом, а инициализация роутов вещь тяжелая
консоль — полностью притащена с симфони, но зачем-то сделана обертка.

> И почему markdown в письмах это костыль?
Вот на кой черт оно во фреймворке? Причем это blade, а потом то что получилось обрабатывается маркдауном, причем это прибито гвоздями, только в мейлере.
Для сравнения — как это сделано в симфини — есть банд https://github.com/symfony/swiftmailer-bundle который просто подключает библиотеку в контейнер и из него конфигурирует ее и ее плагины, после настройки метода отправки нужно просто вызвать container->get('mailer')->send($message) и передать ей объект сообщения, которому уже сам генеришь тело хоть твигом хоть маркдауном, хоть еще каким конвертором, который ставишь отдельно.
У Симфони другие задачи. Относитесь к Ларавелю, как к Yii — для небольших сайтов и быстрого старта они подходят оптимально.

Симфони хорош для больших архитектур, где необходимы DI через конфиги и тп.
Markdown письма внтури фреймворка (как и многие другие костыли) из-за того, что так Тейлору удобнее разрабатывать и поддерживать свои коммерческие продукты +)

Идея Laravel быть гибкой и удобной. Идея Симфони быть правильной. Отсюда и ответ. Любому отпетому симфонисту вряд-ли понравится возможность "из коробки" иметь дополнительную зависимость.


При этом Laravel в результате получается на порядок удобнее:


// Symfony
public function listAction() 
{
    $repo = $this->container->get('doctrine')->getRepository(Some::class);

    return new JsonResponse(['items' => $repo->findAll()]);
}

// Laravel
pubic function index(SomeRepositoryInterface $repo)
{
    return $repo->findAll();
}

И зачастую даже грамотнее. А всякие замечания "прибито гвоздями" просто от незнания, т.к. Laravel местами гибче симфони.

Простите, вы когда симфони последний раз видели? Версия 2.1?
Инжект параметров есть с 3.1 версии, причем не прибит гвоздями к роутеру, как в ларавеле, а реализован через события с помощью ресолверов и возможностью добавлять свои.
Вы простите когда удобство показываете хоть не на двухстрочных функциях это делайте, а то я же тоже могу взять бандлы для апи, там куча вкусностей развешено, а не только 2-3 стандартных преобразования.

А всякие замечания «прибито гвоздями» просто из-за того что посмотрел код мейлера.
Извините, но
        $markdown = Container::getInstance()->make(Markdown::class);

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

Гибкий блин, удобный, особенно гибкий. Хомячки блин тупые, даже код не могут посмотреть той поделки на которой пишут.
гвоздями к роутеру, как в ларавеле

шта?


а реализован через события

Вместо того, что бы сделать по-нормально через контейнер. В ларке подобная схема работает не только для контроллеров, а для чего угодно. Т.к. DD реализован именно через него. Вспомните сколько автовайринг ожидали. И только к версии 3.2 (да ведь?) его наконец доделали до нормального состояния с резолвом из интерфейсов.


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

А я не беру бандлы, я беру коробочную стандарт эдишн. В коробочной поставке симфони огрызок ещё тот, по-этому каждый проект потом превращается в фарш из JMS, Knp, Fos и прочей лабуды с вермишельками сонаты.


Гибкий блин, удобный, особенно гибкий. Хомячки блин тупые, даже код не могут посмотреть той поделки на которой пишут.

Мне жаль, что у меня, как симфониста есть подобные коллеги как вы.

В коробочной поставке симфони огрызок ещё тот, по-этому каждый проект потом превращается в фарш из JMS, Knp, Fos и прочей лабуды с вермишельками сонаты.


Мне жаль, что у меня, как симфониста есть подобные коллеги как вы.

На Simfony получается вермишельный код?
Его удобно поддерживать?
Почему вам тогда нравится Simfony? :)
На Simfony получается вермишельный код?
Его удобно поддерживать?
Почему вам тогда нравится Simfony? :)

Это утрированная ирония =)


  • В Symfony ты собственноручно отстреливаешь себе ногу из пистолета
  • В Laravel тебе мило предоставляется гранатомёт сразу "из коробки", чтобы наверняка

P.S.


  • В Yii это небольшой виджет-танк на JQuery

</irony>

Можно вопрос?
В документации Ларавеля указано в требованиях
PHP >= 5.6.4
https://laravel.com/docs/5.4

PHP 5.6.4 — это, что за зверь такой?

Версию 5.6.30 — знаю, 7.1.1 — знаю, а вот 5.6.4 — не знаю
http://php.net/downloads.php

Открываю секрет: 5.6.4 → 5.6.8 →… → 5.6.10 →… → 5.6.30.

Спасибо за разъяснение!
Так бы я не догадался, что это не «сорок», а просто «четыре».
Мой реквест https://github.com/laravel/framework/pull/16736 влили в 5.4 и теперь можно для роутера объявить глобальные маркеры типа {locale} и тп.

Можете определить, например, в своем ServiceProvider

app("url")->setDefaultNamedParameters(["locale", app()->getLocale(), "userId" => app("auth")->user()->getKey()]);


а потом использовать в роутерах

app('router')->pattern('locale', '(' . implode('|', config('app.locales')). ')');
app('router')->group(['domain' => '{locale}.telenok.com'], function ()
{
    app("router")->post("some-url", array("as" => "some-name", "uses" => "SomeClass@somemethod"));
});
Пока этого нет в документации, использовать не советуется, т.к. Тейлор любит убирать незадокументированные фичи, в текучем релизе есть такие поломки BC.
Проверил — на месте

https://github.com/laravel/framework/blob/master/src/Illuminate/Routing/RouteUrlGenerator.php#L208
Важно ни его наличие в коде, а наличие в документации. Вот пример из неё
The share method has been removed from the container. This was a legacy method that has not been documented in several years. https://laravel.com/docs/5.4/upgrade#upgrade-5.4.0

документация на большинстве opensource продуктов неполная… по тому же Request 50% методов не освещены на https://laravel.com/docs/5.4/requests — нет методов merge(), clone() и многих других… поэтому лучшая документация — это код фреймворка
Нет, потому недокументированными методами и не нужно пользоваться, они могут быть удалены без предупреждения. Я даже пример привёл.
пример апгрейда, при котором, само собой, методы могут исчезнуть, были они задокументированы или не были
НЛО прилетело и опубликовало эту надпись здесь
Осталось дождаться Множественные в JSON-переводах.
о чем речь, что такое Множественные в JSON-переводах?
plurals в конструкции __()
как-то уж очень бодро выпиливает Тейлор код от версии к версии. Сейчас радостно перешли на Dusk и при этом выпилили большой пласт ассертов для тестов seeJson*
как теперь передавать параметры в конструктор?

Через биндинг, ака singleton(), bind(), etc.

хм… спасибо
У laravel отличная документация + крутое сообщество.
Десант Фабьена уже высаживался в комментариях?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.