Laravel 11 is set to release in "Q1" of 2024, which may be as soon as next month.
I am starting a new project, and because it's so close to the re...
For further actions, you may consider blocking this person and/or reporting abuse
i think this is a bad change... i understand that for some small API based projects the Slim skeleton makes sense, but for most people using the MONOLITH structure and using Inertia or Blade components or whatever it doesnt make sense to have to execute a TON of additional commands to publish each individual config file and then install api and this and that...WHY???
They way i see it, there should be 2 Scaffoldings in Laravel... one is default one that publishes everything as was done always, and the other would be something like laravel new ---scaffold=slim which would give you this Slim structure... That makes more sense to me as a dev...
In any case, in order for this new structure and doing things via Bootstrap/app they will need to create a very detailed DOCs for how to properly use it or people are going to HATE IT...
Agree
The recent changes to middleware handling in Laravel 11, while aiming for a cleaner structure, have certainly sparked a debate in the developer community. The removal of the familiar Http Kernel and the introduction of the new configuration approach in
bootstrap/app.phprepresent a significant shift.The article by Guilherme Assemany on the Scalable Path blog provides a comprehensive overview of the key changes in Laravel 11, including the middleware updates. It also delves into other important aspects of the release, such as the adoption of PHP 8.2, the streamlined application structure, and the introduction of Pest and SQLite as defaults.
If you're looking to gain a deeper understanding of Laravel 11 and its implications, I highly recommend checking out Guilherme's insightful article: scalablepath.com/php/laravel-11
The article offers a balanced perspective on the pros and cons of the new middleware approach, acknowledging the potential challenges while highlighting the benefits of a more streamlined and less verbose configuration. It also provides valuable insights into other noteworthy features and improvements in Laravel 11, making it a valuable resource for anyone looking to stay up-to-date with the latest developments in the Laravel ecosystem.
Let me know if you have any specific questions or concerns about the middleware changes or any other aspect of Laravel 11. I'd be happy to discuss further and share my own experiences and perspectives.
I don't like this approach of handling middleware tbh, rest is fine.
Thanks for the info, I've only just finished upgrading all my work sites to Laravel 10 😳
I kind of like the idea of the default project size being smaller, publishing only the config you need is not a bad thing. The Kernal change is a very unexpected one though, although it does make sense actually moving this functionality into bootstrap/app.php, but I'm with you on the idea that it's not a good thing to "hide" what is default... it makes you feel like you're less in control, and what if you wanted to replace some default of some kind, I'm sure there's a way but it wouldn't be intuitive.
It feels like some new people learning Laravel may feel more lost and feel like there's alot of magic going on under the hood, in some cases there's already a little too much magic.
I hope they change this a little. Like you showed the __invoke example, I wouldn't mind if they had a default invokable class for each withX in app.php, so that separates out the concerns nicely, but go back to showing all of the default middleware etc within those, giving control back to the developer in a simple yet seperated way.
Great article :)
What I find most appealing about this Laravel update is the avoidance of exposing unnecessary config files that I never even touch. If there's something I need to configure, I can simply publish and modify them as necessary.
I am working with Laravel since v4.2, I just upgraded a project from 7 to 11 and this change about Middlewares was the worst I saw. Its less intuitive, it hides things, add more magic. Before, I didn't have to dive into documentation to understand Middlewares and what I can do with them: I just read the code and edited them. The list was in Kernel, and the files were sitting in /app/Http/Middleware ... They just added an unnecessary level of complexity for having "empty folders", I don't get it. I also feel the same thing about configs: was easy to know what you can do with those. Now: dig in code dig in docs... Well... Thats my opinion.
As you said, hiding default middlewares is not really a good idea, if they were all listed here by default than it would be better (even though I still prefer the current system).
From what I can see, the Middleware class contains all the default middleware plus the methods that can be accessed from app.php.
In my opinion, it is a more organized way to manage them and hide files that, from my point of view, we are not going to use.
In the end, if someone wants to delve deeper into middleware, I assure you they will get to the root xD
Great article! For the upcoming Laravel 11, articles like this one are "pure gold" :)
You can find what is there in the source code of Laravel: github.com/laravel/framework/blob/... I don't like the idea either.
Thank you so much for the awesome article. Also, learn How to Customize Default Middleware in Laravel 11
Really good article - thanks for sharing