Upgrading to Symfony 6.4
Hey everyone! Symfony 7 is out! Woo! Well, of course I'm excited - I love all things Symfony, Twig, related. But what does it really mean that Symfony 7 is out?
Symfony's Delightfully Predictable Release Schedule
Honestly... not much! Thanks to Symfony's release schedule, a new major version isn't much of a big deal... though we try to pretend it is for marketing.
Every 6 months - in May & November - a new minor version is released, like 6.1 or 6.2. Those are the versions that contain new features. So it totally makes sense to get excited about Symfony 6.3 or fantastically amazing new features in Symfony 6.4. Then, each ".4" version, like 6.4, is released on the same day as the .0 version of the next major: 7.0. Yea, 6.4 and 7.0 were released on the exact same day and are, effectively, identical! They're twins!
The only difference is that, in 7.0, all the deprecated code paths are removed. And this is the core of what makes Symfony special. The release schedule and the deprecation policy mean that as users, we can upgrade our apps forever across major versions... without it being a big deal or breaking our apps. And that's exactly what we're going to do in this tutorial... followed by a tour of some of my favorite new features.
Project Set Up
As always, to get the most out of this tutorial, code along with me by downloading the course code from this page. After you unzip the file, you'll find a start/ directory with the same code that you see here. The README.md file tells an inspiring tale of how to get the application up and running. I've already done most of the steps, including running yarn install and yarn watch in this tab.
The final step is to use the symfony binary to run:
symfony serve -d
to start a development web server. I'll click the link. Say hello to Mixed Vinyl: The app from several of our Symfony 6 tutorials, which is currently on 6.1.2.
Using a Newer PHP Version
Open up composer.json. Near the top, our app requires php 8.1 or greater. In my apps, down under config.platform.php, I also like to set the specific PHP version that we're using on production:
| { | |
| // ... lines 2 - 4 | |
| "require": { | |
| "php": ">=8.1", | |
| // ... lines 7 - 32 | |
| }, | |
| "config": { | |
| // ... lines 35 - 44 | |
| "platform": { | |
| "php": "8.1.0" | |
| } | |
| }, | |
| // ... lines 49 - 96 | |
| } |
This guarantees that Composer only gives me dependencies compatible with that version.
Locally, if I run php -v, I already have PHP 8.3 installed. I also have a second php binary installed for version 8.1. And thanks to the 8.1 in composer.json, when I started the symfony web server, it used that older version.
Change this to, just PHP 8.3. Then run:
composer up
In composer.json, all my dependencies - whether they're Symfony or something else - are written in a way that only allows the last number or the second to last number to change. Assuming the package maintainers are doing their job, those updates won't contain backwards-compatibility breaks. We should be able to upgrade from 6.1 to 6.4... or 2.0 to 2.4 and our app should keep rocking like normal!
So running composer up to get these updates, in theory, is totally safe.
Encore & Minor Changes
Over in my yarn tab, the update triggered an error: something about a controller does not exist. This is special to Symfony UX & Encore. When you update your PHP dependencies, you may need to reinstall your node dependencies. Hit Ctrl+C, then run:
yarn install --force
Or npm install --force if you're using npm. Then
yarn watch
again. It's happy! In the main tab, run:
git status
Alongside the usual suspects, there's a new controller in controllers.json... which came from an update to ux-turbo. We won't use it, but it's fine there. In package.json, it added a new entry for stimulus bundle. This is a relatively new bundle that got installed during the upgrade, and we'll talk more about it soon.
Upgrading to 6.4
So we are now using PHP 8.3 and we've upgraded our dependencies a bit. But we're still using Symfony 6.1. To upgrade to 7, we first need to upgrade to 6.4. That'll give us a chance to prep for 7.0 by finding - and fixing - all the deprecations.
And... upgrading is easy! Find 6.1.*, replace with 6.4.* and replace all.
| { | |
| // ... lines 2 - 4 | |
| "require": { | |
| // ... lines 6 - 17 | |
| "symfony/asset": "6.4.*", | |
| "symfony/console": "6.4.*", | |
| "symfony/dotenv": "6.4.*", | |
| // ... line 21 | |
| "symfony/framework-bundle": "6.4.*", | |
| "symfony/http-client": "6.4.*", | |
| // ... line 24 | |
| "symfony/proxy-manager-bridge": "6.4.*", | |
| "symfony/runtime": "6.4.*", | |
| "symfony/twig-bundle": "6.4.*", | |
| // ... lines 28 - 29 | |
| "symfony/yaml": "6.4.*", | |
| // ... lines 31 - 32 | |
| }, | |
| // ... lines 34 - 81 | |
| "extra": { | |
| "symfony": { | |
| // ... line 84 | |
| "require": "6.4.*", | |
| // ... line 86 | |
| } | |
| }, | |
| "require-dev": { | |
| // ... line 90 | |
| "symfony/debug-bundle": "6.4.*", | |
| // ... line 92 | |
| "symfony/stopwatch": "6.4.*", | |
| "symfony/web-profiler-bundle": "6.4.*", | |
| // ... line 95 | |
| } | |
| } |
Though, be careful. Most of the time, the Symfony version constraints look like this. However, they could look like ^6.1. So don't miss those: the goal is to upgrade every symfony package that comes from the main repository. That... can be confusing because, mixed in with the packages that we do want to upgrade are other packages that live under symfony, but are independent and follow their own release timeline & versioning. Ignore those for now - but we will make sure every package is upgraded by the end.
Also, near the bottom, under extra.symfony.require, make sure this is also updated to 6.4.*. That's a composer optimization that tells it to only worry about 6.4 Symfony versions.
Back over at the terminal, let's do this!
composer up
Look at those beautiful upgrades from 6.1 to 6.4! And... when we try the site, the stinkin' thing still works!
Oh, but check out the PHP version: 8.1.27. When we started the symfony web server, it read the PHP 8.1 version from composer.json, found that version installed on my machine and used it. We changed this to 8.3, but we need to restart the server to use it. Run:
symfony server:stop
Then:
symfony serve -d
Yup: it found the PHP 8.3.1 version on my system. And on the site... got it!
Ok, this is working on Symfony 6.4. Our job now is to find every deprecation and fix them. On the web debug toolbar, we apparently hit 22 deprecated code paths on this page! To start fixing these, we'll... cheat... take a shortcut, by upgrading our Flex recipes.
The lockfile is not correct.
when doing a composer install, i'm getting the following error:
removing the composer.lock and doing a composer install again is fixing above error
so could you maybe remove the file from course code or update the lock file for new people that are trying this course ?