[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: [Bug/Proposal] Locale missing from queues / queued emails and listeners #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.

[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 : laravel/framework#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!

[manyopensource]

Volt instead of Blade (because Blade is absolutely bullshit)

[manyopensource]

Please add DI such as Phalcon\DI (because now is ...)

[manyopensource]

You need to update your micro-framework (now it is unuseful)

[imliam]

@manyopensource What're the problems you're having with Blade, Laravel's DI and Lumen? They all do their job well and you've not given any reason for them to be changed.

[mxrxdxn]

@manyopensource what's wrong with Blade? Calling it "bullshit" without reason isn't exactly helpful 😂

[autaut03]

@michaeldyrynda, to me Laravel should at least create it's own package for handling modular structure, preferably Porto. There are a couple of laravel-modules like packages and a framework (not really) built on top of Laravel, Apiato, which utilitizes Porto, but all of them aren't quite suitable for a real production project. Forcing to use modular structure isn't probably the best thing to do, but giving an option to and showing the advantages is a good path to use it as default one in Laravel 7 ;)

[donnysim]

I wish fillable and guarded to be gone in Laravel 6 and instead introduce columns field. Eloquent is mostly usable with them turned off, otherwise it becomes more of a headache then help and leads to bad practices like Model::create($request->all()) etc.. Instead of them, maybe introduce a columns field, which would be optional. It could contain all writable columns from database which would allow to filter which model fields should actually be persisted (updated, created) to database in case you have properties added to your model, that has nothing to do with database, before saving.

[donnysim]

Maybe extract eloquent Model as an App\Model? maybe in this way we would be able to finally make our own, lighter eloquent model version without all the stuff we hate? Because as it is now, Laravels most inflexible peace is the Model and query builder coupling, you can't replace the Model because everything expects a Laravels Eloquent Model, you can't use custom Builder because you have to modify the Model to return the custom Builder, then replace all extended models to use the new model.

[RoccoHoward]

Have a look at my package - https://github.com/hnhdigital-os/laravel-model-schema where I moved all these things to a model schema using a static associate array which brings everything Laravel does with attributes into the one array. It also provides custom casts to be implemented. It's fully compatible with existing Laravel models - accessing the fillable and guarded returns exactly these attributes that would be expected.

…

On Mon, 13 Aug 2018 at 16:22, Donatas Šimkevičius ***@***.***> wrote: I wish fillable and guarded to be gone in Laravel 6 and instead introduce columns field. Eloquent is mostly *usable* with them turned off, otherwise it becomes more of a headache then help and leads to bad practices like Model::create($request->all()) etc.. Instead of them, maybe introduce a columns field, which would be optional. It could contain all writable columns from database which would allow to filter which model fields should actually be persisted (updated, created) to database in case you have properties added to your model, that has nothing to do with database, before saving. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#226 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAN6OILUQ7g62GSupigFs33ysvpReghdks5uQRs2gaJpZM4KG_jF> .

[donnysim]

Adjusting a single line in save method still requires you to create a new model class and change everything to extend it. Having a base "Model" in the app by default would make things easier at any point in time. A huge bonus (at least for me) would be if it was the eloquent model itself, where I can remove fillable and guarded features without overwriting and changing a bunch of other methods. I know we can just create it if we need it, and this is very unlikely to happen because all those packages depend on getting a eloquent model instance instead of customized model, but worth a try :|

[dracon55]

Make function: registerMetaTag(['name' => 'keywords', 'content' => 'yii, framework, php']);

some think like Yii2

[manyopensource]

@dracon55 You mean someone like you, who thinks like Yii2? And I know you from Russia, isn't it?

[autaut03]

@dracon55 To me, this isn't framework's task.

[tomschlick]

I think this thread has run it's course. At this point we should be opening separate threads and PRs for any new items.