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
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.
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" :)
Really good article - thanks for sharing
Thank you so much for the awesome article. Also, learn How to Customize Default Middleware in Laravel 11