// composer.json
{
"require": {
"php": ">=8.2",
"ext-ctype": "*",
"ext-iconv": "*",
"babdev/pagerfanta-bundle": "^4.5", // v4.5.0
"doctrine/dbal": "^3", // 3.9.4
"doctrine/doctrine-bundle": "^2.13", // 2.13.2
"doctrine/doctrine-migrations-bundle": "^3.3", // 3.4.0
"doctrine/orm": "^3.3", // 3.3.1
"knplabs/knp-time-bundle": "^2.2", // v2.4.0
"pagerfanta/doctrine-orm-adapter": "^4.7", // v4.7.1
"php-cs-fixer/shim": "^3.46", // v3.65.0
"phpdocumentor/reflection-docblock": "^5.3", // 5.6.0
"phpstan/phpdoc-parser": "^1.25", // 1.33.0
"stof/doctrine-extensions-bundle": "^1.12", // v1.13.0
"symfony/asset": "7.1.*", // v7.1.6
"symfony/asset-mapper": "7.1.*", // v7.1.9
"symfony/console": "7.1.*", // v7.1.8
"symfony/dotenv": "7.1.*", // v7.1.9
"symfony/flex": "^2", // v2.4.7
"symfony/framework-bundle": "7.1.*", // v7.1.6
"symfony/http-client": "7.1.*", // v7.1.9
"symfony/monolog-bundle": "^3.0", // v3.10.0
"symfony/property-access": "7.1.*", // v7.1.6
"symfony/property-info": "7.1.*", // v7.1.9
"symfony/runtime": "7.1.*", // v7.1.7
"symfony/serializer": "7.1.*", // v7.1.9
"symfony/stimulus-bundle": "^2.13", // v2.22.0
"symfony/twig-bundle": "7.1.*", // v7.1.6
"symfony/ux-turbo": "^2.13", // v2.22.0
"symfony/yaml": "7.1.*", // v7.1.6
"symfonycasts/tailwind-bundle": "^0.7.1", // v0.7.1
"twig/extra-bundle": "^2.12|^3.0", // v3.16.0
"twig/twig": "^2.12|^3.0" // v3.16.0
},
"require-dev": {
"doctrine/doctrine-fixtures-bundle": "^3.6", // 3.7.1
"symfony/debug-bundle": "7.1.*", // v7.1.6
"symfony/maker-bundle": "^1.52", // v1.61.0
"symfony/stopwatch": "7.1.*", // v7.1.6
"symfony/web-profiler-bundle": "7.1.*", // v7.1.9
"zenstruck/foundry": "^2.2" // v2.3.1
}
}
7 Comments
I liked this tutorial. In times past when I made a mistake with my data inserts or needed new fields it can be a problem using vanilla PHP. We end up dropping the database and starting over more often than not. Which the migrations are doing but it's mechanized and easier this way. That's what the framework is for, eliminating the boilerplate code we would normally do by hand. I just don't like having all of the features that we do not need. And the potential of a possible backdoor in the code that we do not know about is always a concern.
Hey @David-H!
I'm glad you're digging it!
Yeah, the potential back-door of course always exists. But with 3rd-party packages like Doctrine, which is massively used, there are a ton of people looking at it and fixing these. You just need to make sure you keep it up-to-date!
For the extra features, yeah, I hear that. I think, for the most part, the unused features wouldn't impact performance (only disk space). A looong time ago, the recommended way to use Symfony was to install the full thing - we've come a long way since then!
--Kevin
Just wondering, are you using an AI voice for this? It doesn't sound natural... Hopefully Ryan can make a full return after his convalescence...
Hey @Markchicobaby,
No AI, just me! I'm still getting used to doing these videos - Ryan's a hard act to follow :)
And yep, we're all hoping to see Ryan doing videos again soon!
Cheers!
Kevin
Your expertise is appreciated. We just got attached to Ryan a little, but the favoritism wears off the more time we spend with you, Kevin. Thank you all at symfony for your hard work, bery impressive. Ryan definitely has a booming personality.
Hi just wondering if the createdAt field should be set with datetime, instead of datetime_immutable? My understanding is that having mutable allows actions like $this->updatedAt->modify('now'); while immutable forces you to do $this->updatedAt = new \DateTimeImmutable(); ?
Hey @Markchicobaby,
Unfortunately, Doctrine sort of treats
datetimelikeDateTimeImmutableanyway.$this->updatedAt->modify('now')is not detected as a change onflush()so you'd need to use$this->updatedAt = new \DateTime('now'). It's recommended to always usedatetime_immutableso there's no confusion.See this doc for more information.
--Kevin
"Houston: no signs of life"
Start the conversation!