[6.0] Laravel 6 Wishlist

[tomschlick]

We are probably within a 18 months or so of Laravel 6 based on previous iteration cycles.

Taking that into account. If L6 was released in November/December of 2017, what would you like to see as the big name features / refactors?

[tomschlick]

For me the big one would be the jump to PHP >= 7.0 only. That would allow us to type hint parameters where possible as well as return types. As much as some people hate them (for whatever reason) they are pretty useful in terms of finding bugs where data input/output is the cause.

That wouldn't mean that you would have to use them in your code. Just that the framework would to use them internally to help self-validate data and increase performance.

[michaeldyrynda]

I'd love to see the unit testing updated (if possible) to not spew a full stacktrace to the console. Makes it hard to find out what the actual cause for the failed test is with all the noise.

[tomschlick]

@michaeldyrynda is that something that would be handled by phpunit? or does the framework make that happen via some special config / error handler?

[hipsterjazzbo]

Are we dreaming here? Cause I'd give my left foot to see @taylorotwell's take on a pure data mapping ORM 😎

[tomschlick]

We are dreaming here... throw in whatever you got 👍

[michaeldyrynda]

@tomschlick playing around with it yesterday, we just added a check for php_sapi_name() == 'cli' in app/Exception/Handler.php, then just spit out response($e->getMessage()) or similar. Would be nice to just push it upstream. May not even need to wait for 6, though.

[tomschlick]

@michaeldyrynda yeah might as well make a PR for it. Doesn't sound like it's a breaking change and could help the usability of tests.

[taylorotwell]

I think it's possible we could move to PHP 7+ before Laravel 6.0. Perhaps Laravel 5.5 in May 2017? I don't know that I really have any paradigm shifting ideas that would require a jump to Laravel 6. I like the overall structure and feel of the 5.x series.

[tomschlick]

Yeah I am really enjoying the flow and everything of the 5.x series but figured the 7.0 jump would have been a big enough change to warrant 6.

Though I guess it wouldn't be any different than the jump from php 5.4->5.5->5.6 in terms of signifying BC breaks.

[kamui545]

👍 for PHP 7+.

For me, rather than big features, I would love to see two issues we keep seeing fixed, they have been here for too long =/

• Migration of unsupported types from Doctrine DBAL
• Issues with ORM casting isDirty()

About the features I'm not sure yet, the proposal for a 2FA is a good start.

[fragkp]

Would love to see, I could use '::' as the delimiter for controller actions :)

PS: 1 Up for PHP7+

[CristianLlanos]

I wish the Authenticatable Interface didn't force me to add a "remember_token" field to my users table. When developing stateless APIs we don't often need a field like that, I think.

[dwightwatson]

Would like to see some sort of headless browser integration testing. I know Jeffrey Way was playing with a Selenium driver for Laravel's TestCase and there's been some talk about Nightwatch.js, but I think an integrated or recommended solution would be great.

[constb]

In the spirit of PHP versioning, I think we should jump right to Laravel 7.0 and skip 6s altogether :)

[xwiz]

The most singular breaking change I can think of is to put AI in the framework. AI is coming to coding and we should start thinking about that. We can start with making artisan a global PHP plugin and enabling it to learn what a user normally does or copy code from projects.

[jbrooksuk]

Would like to see some sort of headless browser integration testing. I know Jeffrey Way was playing with a Selenium driver for Laravel's TestCase and there's been some talk about Nightwatch.js, but I think an integrated or recommended solution would be great.

@dwightwatson got his wish!

[imliam]

Some native HMVC, modular or Porto style layout in Laravel 6 would be great, especially for some things such as make:auth and Spark to help keep larger applications organised.

[manojnegee]

Multi Threading in Laravel 6 . What do you think ?

[sisve]

@manojnegii90 Just saying "multi threading" is a bit vague. Could you clarify where in Laravel you would want multi-threading?

[manojnegee]

I am sending serveral http request from the server to track or to store information somewhere else. The response from those request is insignificant to me. Waiting for the response is making user to wait more for the response. I want to avoid that and want to quickly respond to the user.

[jbrooksuk]

Dispatch the requests in a job then @manojnegii90?

[boynet]

you are looking for udp @manojnegii90

[m1guelpf]

async php in the core?

[Rudoslav]

php artisan make:view

[jakebathman]

I don’t think make:view would need to wait until v6

[sisve]

I would like a major overhaul on how locales are handled.

1. Switch over to BCP 47 locales.
2. Introduce a Locale class instead of using opaque strings.
3. Let the Translator have support for fallbacks. The locales sv-SE and sv-FI can both be served by the sv translation (assuming that no other translations are provided).
4. Preserve the current locale when you dispatch a job and restore it when the job executes. Ref: https://github.com/laravel/internals/issues/394

[antoineMoPa]

Not really a feature, but as someone who is currently migrating a 4.2 application to a 5.1 application, I would appreciate a smoother upgrade path to Laravel 6 and that means do not require developers to move folders around. Moving folders around seems like a small change, but consider developers who have to fix production bugs while migrating an application. They'll probably use git rebase and merges to keep the new app in sync with the bugfixes over the course of a few days/weeks. If all the controllers, tests, routes, etc. have moved, the merge process is painful (and consumes a third of my upgrade time).

Changing the release number is not an excuse to introduce tons of breaking changes. Improvements should be made while trying the best not to break people's code. Let's just not make the framework upgrades hostile to developers, the goal is to be developer friendly and encourage upgrading.

Having a complex upgrade path means having more users with old unsafe and unsupported versions of Laravel, which keeps Laravel and PHP's reputation bad. Laravel is popular and mature enough to justify less folder name changes every 2 years. A smoother upgrade path would help make Laravel a good long term choice for application development.

[mhndev]

Maybe not completely related to laravel 6, but I want to use all laravel components out of laravel, so for example 1 - eloquent (I know that I can use it out of laravel but it really isn't designed to be used out of Laravel) 2 - horizon 3 - validation 4 - localization 5 - routing ...

and many other components.

[mattstauffer]

@mhndev Check out Torch: https://github.com/mattstauffer/Torch

It's a project dedicated to showing you how to use all of Laravel's components outside of Laravel.

It doesn't cover Horizon or any of the separated packages, but you can add those as requests in the issues if you'd like.

[powelski]

I'd love the better Eloquent data integrity. Like assuming the types and relations from database schema itself, wherever it's possible. Also, defining each relation once, not twice.

[connectkushal]

Integration with php-pm :checkered_flag: :racehorse:

[mfn]

Integration with php-pm 🏁 🐎

… but there's an adapter for it and it works (didn't do much testing, only tested it on a private app). What more do we want here? A suggestion in composer to install it? 🤔

There are potential bugs though, see

• https://github.com/php-pm/php-pm-httpkernel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+laravel and
• https://github.com/php-pm/php-pm-httpkernel/blob/master/Bootstraps/Laravel.php#L88-L96

[connectkushal]

By integration i meant dealing with the bugs, having the adapter in the core with a way to toggle its use via some variable in env file maybe, tweaks to php artisan serv or a new command to serve pages using ppm commands, things like that... Im just dreaming here :)

[manojnegee]

I would like to see module based directory structure in Laravel 6 . For eg: - Let's take a user module -> All routes, views, controllers related to the user module at one place. what do you guys think ?

[michaeldyrynda]

I don't see the default application structure changing too much at all.

You own everything inside the app/ fold and it's namespaced using the PSR-4 autoloading specification, which means that you can structure your code in there however you'd like.

Laravel doesn't ship with any default 'modules' as such, so there isn't too much point in shipping a specific structure for it with the default application.

[putheakhem]

@taylorotwell I would like to see the doctrine in a new version of laravel release!

[semsphy]

@putheakhem , Eloquent is enough.

[RemiCollin]

@semsphy : Eloquent is a bloated god class and this clearly handicaps its evolution. Attempt to implement Object Casting, for example, didn't work out : https://github.com/laravel/framework/pull/18229 .

It's probably enough for basics CRUD operations, but it quickly becomes messy when used in complex applications. So "Eloquent is enough" is quite a subjective statement.

[sisve]

This sounds like usual discussion between Active Record (the wrong-doers) and Doctrine (the right-doers). I'm clearly totally unbiased. ;)

But, think about the maintainability. We would still need to support Eloquent since there's a huge community that uses it. Adding another database layer, and the documentation needed to let people do a informed choice between them, sounds like a huge undertaken without clear return of investment. Those of us that wants to use Doctrine already has the capability via https://www.laraveldoctrine.org/ Why should it be added to the framework?

[RemiCollin]

@sisve : I don't think there are right-doers or wrong-doers, I use both AR & DM on a daily basis, they are two different patterns that have both pro & cons. I just don't agree with the general consensus among the Laravel community that "Eloquent is enough" for every use case.

But as you said there are already alternatives, so I agree with you that it doesn't need to be added to the framework.

[zuohuadong]

reactphp async php

[jakesylvestre]

@tomschlick noticed you closed this. Is there a better place to discuss?

[tomschlick]

@jakesyl new threads would probably be best. This one was getting pretty long and already accomplished a few of the items outlined here.

[darron1217]

Supporting @ImLiam and @manojnegee 's idea. I've been dreamed of having component-style(module) structure on Laravel. Frontend frameworks' trend shows that component-style directory structure is clearer to understand, and also it enhances productivity (especially on git) If laravel supports component style directory structure, it might be another huge leap for the PHP eco-system

[michaeldyrynda]

Laravel already supports component style directory structure.

[darron1217]

@michaeldyrynda Yes, I mean the complete code split (including providers, routes, ..etc) Just like https://github.com/nWidart/laravel-modules

[michaeldyrynda]

I don't think the framework needs to be responsible for how you use it at this level of granularity.

[darron1217]

Hmm... I meant the concept like Angular's Style Guide I felt comfortable when Angular Team has provided a guideline of directory structure.

I love laravel because it is bunch of best practices. My opinion was about supporting HMVC pattern by providing docs about best practices :)

[michaeldyrynda]

Plenty of those things out there already; Laravel gives you the tools do build the apps however you see fit. It makes no suggestions for architectural decisions and that's idea. Not every app needs HMVC, start with the lowest common denominator and let people build up however they need from there.

[mauricemojito]

My wishlist is to rollback a specific migration, because sometimes migrating from the last to the needed migration is hard and the other reason is it deletes all data.Some command like: php artisan migrate:rollback specific="cars,users" and for migrating php artisan migrate:specific="cars,users". Love laravel, keep the good work up!