Alright, I want to take a brief break from building, and I want to focus our attention on housekeeping, just for a few episodes. Laravel 11 recently released, so many new features that we can make use of, and I know that some of you will be starting this series with Laravel 11 as your base, so it would be good to make sure we're on the same page. Vue, Vue 3.4 released not too long ago, and it can definitely clean up some of our components, so that's an upgrade that we can make. And finally, there are a few features that don't quite work as expected, some edge case bugs that it would make sense to fix, so that we don't start seeing issues later down the line.

bugs that it would make sense to fix, so that we don't start seeing issues later down the line. So let's take the time to do some housekeeping. We'll first of all focus our efforts on the Laravel 11 upgrade. So I'll head to documentation, and the upgrade guide is in Prolog, under Upgrade Guide. Now here's a tip for you. Don't upgrade the day that Laravel comes out. Leave it a couple of weeks, because that gives package maintainers time to make sure everything works correctly, any kinks to be ironed out, and any issues will likely appear on the Laracasts forums.

works correctly, any kinks to be ironed out, and any issues will likely appear on the Laracast's forums. So after a couple of weeks, then dive in and make the upgrade. First things first, we now have a minimum required php version of 8.2. I've been building this on 8.3, so I'm actually going to open up my composer.json, and I'll hard code 8.3 as the PHP required version. Laravel now requires a curl version greater than 7.34. You can check which curl version you have installed on your OS by going to the terminal and running curl -V. I'm on version 8.4.0, so I don't have to worry about this, but a quick Google search will show you how to update curl on your operating system if you need.

and running curl -V. I'm on version 8.4.0, so I don't have to worry about this, but a quick Google search will show you how to update curl on your operating system if you need to. We'll need to update our composer dependencies so that the Laravel framework and related packages match the requirements for Laravel 11. So of course first and foremost, Laravel framework goes to 11.0. Head to your composer.json, Laravel framework, greater than 11.0, let's go back, collision greater than 8.1, that's a dev dependency, here we go, collision, upgrade to greater than 8.1. We're not using Breeze or Cache or Dusk, we are using Jetstream, so let's upgrade that.

than 8.1. We're not using Breeze or Cache or Dusk, we are using Jetstream, so let's upgrade that to greater than 5.0. Here we go, greater than 5.0, come back, no Octane or Passport. We do have Laravel Sanctum installed, although we're not actually making use of any API features inside the application, so I may well remove Sanctum maybe in the next episode. For now we'll stick with the upgrade guide. So I'll go ahead and change our Sanctum version to greater than 4.0. We're not using Stripe or Telescope, we are using Inertia Laravel, which has now been bumped to greater than 1.0.

We're not using Stripe or Telescope, we are using Inertia Laravel, which has now been bumped to greater than 1.0. So we should be able to run composer update now. Let's head to our terminal, composer update, and with any luck, there we go, it is working. You may receive an error message here if you have package dependencies that don't yet support Laravel 11, however with a little bit of googling you can usually find out which packages are causing the issues. If you are struggling, post in the comments and no doubt myself or a helpful member of the community might well be able to help you out. Alright now we move on to the meat and potatoes of upgrading, which is updating our application

the community might well be able to help you out. Alright now we move on to the meat and potatoes of upgrading, which is updating our application code to make sure it works with Laravel 11's changes. Biggest piece of advice I can give, just read the upgrade guide, don't skip parts, take the time to go from top to bottom so that you can ascertain exactly what you'll need to change in your application. So password rehashing, well I want that functionality from Laravel 11, so I'm not going to change anything in this case. Notice that many of these changes will tell you how likely it is that you need to worry. In this case we don't have any custom User provider contracts, so I can skip that.

Notice that many of these changes will tell you how likely it is that you need to worry. In this case we don't have any custom user provider contracts, so I can skip that. Authenticatable, although the user is authenticatable, note that at the bottom of this change it tells us that the default user model, which is what we're using, already receives this method automatically. So again, we don't need to worry about that change. We're not using authentication exception, so we can skip that. We're not using the cache yet for anything, and even if we were, this change is very unlikely to cause any issues. So again, we'll skip that.

to cause any issues. So again, we'll skip that. When it comes to collections, we're not using custom collections, we're not implementing enumerable ourselves, so once more we can skip over this one. We use MySQL instead of SQLite. Note that we have the casts method on our eloquent models. You can quickly go and check about what this change is inside my What's New in Laravel 11 series, but essentially the actual change here is that if we have a casts method on our models for whatever reason, it will now conflict with the casts method that Laravel 11 defines.

our models for whatever reason, it will now conflict with the casts method that Laravel 11 defines. Now you don't have to change from using a cast property to a cast method, but seen as the only model in our application to actually make use of the cast property as a User, we could go ahead and do that. So if we come down here, here's casts. Let's come down to where our methods are declared. I'm going to implement the casts method. I'll take the content of this casts property and I'll just paste it in place there. There we go.

I'll take the content of this casts property and I'll just paste it in place there. There we go. We don't have to do that because Laravel can still read that cast property, but at least it realigns us with what Laravel 11 has, and it's a very simple change in this case. If I had many, many, many models that were using the casts property instead of the cast method, I may well decide to skip this for now. If we're modifying any columns in our database, now we have to re-declare all of the attributes again. There's an easy way to detect whether you are doing this or not, and that's to do a global search in your project for a change method.

There's an easy way to detect whether you are doing this or not, and that's to do a global search in your project for a change method. If you are not using a change method in your migrations, you don't have to worry about this change. But even if I were using change, I would actually be tempted to just squash my migrations rather than changing all of the existing migrations. It seems a lot simpler. We don't have to worry about it, so let's move forward. We're not using doubles or floats in any of our migrations, so we can skip over this section as well.

We're not using doubles or floats in any of our migrations, so we can skip over this section as well. We're using MySQL, not MariaDB, so again, we'll skip over this section. Spatial types, nothing funky like that taking place. Let's move forward. And I don't have Doctrine Debug installed. If you do, you can completely remove it now because it's no longer required. All of that functionality is actually part of the Laravel framework itself. Super cool that we no longer have to worry about that additional dependency. There are some deprecated schema methods which might be concerning at first, until you realize

Super cool that we no longer have to worry about that additional dependency. There are some deprecated schema methods which might be concerning at first, until you realize that all of these methods are just ways of introspecting the database, which we're definitely not doing in the case of our particular project. So nothing to worry about here. Same with GetColumnType and the DatabaseConnection interface. Laravel 11 now supports both Carbon 2 and Carbon 3. Before it only supported Carbon 2. Now we don't have Carbon declared as a direct dependency. It's a sub-dependency of our project, so we can check the installed version by running

Now we don't have Carbon declared as a direct dependency. It's a sub-dependency of our project, so we can check the installed version by running composer show followed by the package name, in this case nesbot/carbon. And at the top of the output, here we go, it's version 3.1.1, so it has been upgraded to v3. We're not doing anything funky with dates, so I'm not worried about Carbon at all. But if you are worried and you want to make sure that nothing has broken, you could absolutely go for something like composer require and then you'd specify the actual version you're interested in, in this case nesbot/carbon:^2.0. And using the capital -W flag will ensure that any dependencies that need to be changed to

interested in, in this case nesbot/carbon greater than 2.0. And using the capital -W flag will ensure that any dependencies that need to be changed to support that will also be downgraded at the same time. Nice easy way to lock the package in place. But in our case, yeah, I'm pretty sure nothing is going to go awry by upgrading to use Carbon 3. Our application has no mail at the moment, so no need to worry about this change here. We're in the context of an application, not a package, so we can skip this. We have no jobs at the moment, even if we did have jobs, we wouldn't be implementing BatchRepository directly like so, so again, no need to worry.

We have no jobs at the moment, even if we did have jobs, we wouldn't be implementing batch repository directly like so, so again, no need to worry. As for rate limiters, we have support for per second rate limiting, and this change only comes into effect if you have manually defined your limits using the new keyword. Now we do have a rate limiter in place in the root service provider, Laravel shipped out of the box with this one. You don't have to worry about it because it's using the static methods rather than the new keyword. So we can carry on without any issues there. And then we're on to package changes, of which we only have Sanctum installed.

So we can carry on without any issues there. And then we're on to package changes, of which we only have Sanctum installed. And as I said, we'll remove that in the next episode. So hopefully, if we come to the terminal now, and we'll run php artisan test, I'll use the -P flag to run it in parallel. Look at that, we have 85 passing tests. And the four skip tests are Jetstream tests that ship with Jetstream, so no need to worry about those. But with those 85 tests passing, I'm pretty confident because we have a thorough test suite that everything is in fact working.

But with those 85 tests passing, I'm pretty confident because we have a thorough test suite that everything is in fact working. We could of course do some manual testing. So we'll come to the application. Let's use the filters. Nice, that seems to work fine. We'll click into one of these. Again, all good. Let's go ahead and add a Comment. This is a comment.

Let's go ahead and add a Comment. This is a comment. And we'll post it. Can we edit the Comment? Add a few exclamation marks. Yes, we can. Let's delete the Comment. Nice. And then let's create a new Post. We'll use our nifty little auto-fill feature, conspiracies, create Post.

And then let's create a new Post. We'll use our nifty little auto-fill feature, conspiracies, create post. There we go, that works. So we've successfully upgraded our project to Laravel 11. Didn't take that long, did it? Of course, depending on the complexity of your project, maybe it takes less time, maybe it takes more time. You might have to be a little bit more careful. But so long as you have tests in place, you'll pretty much have confidence that everything works exactly as expected and the upgrade won't be painful.

But so long as you have tests in place, you'll pretty much have confidence that everything works exactly as expected and the upgrade won't be painful. If you are worried or you just can't be bothered to do the upgrade yourself, you could reach for a service like Laravel Shift, pay them a small sum at one time and it will upgrade for you. It will do all the changes automatically. You run your tests or you go ahead and manually check things work, you merge it, you're good to go. But even if you're doing it manually, because Laravel is now a mature ecosystem, it's a mature framework, the upgrades really don't break much and it isn't difficult to upgrade.

But even if you're doing it manually, because Laravel is now a mature ecosystem, it's a mature framework, the upgrades really don't break much and it isn't difficult to upgrade. So don't be put off from upgrading so that you can enjoy the latest and greatest.