Symfony 7.0 Type Declarations: Requesting Feedback from the Community #51563
Comments
|
Hey @wouterj. We've started testing Symfony 6.4 on Laravel v10 and Symfony v7.0 on upcoming Laravel v11. Currently seeing CI failures but we'll first weed out the ones we can solve ourselves before reporting back here. |
|
@wouterj we got all the failures for 6.4 fixed so I think we're good on that front. For 7.0 we'll work on the CI failures in the upcoming weeks. |
|
We've merged v7 support into Laravel v11. Got everything sorted there as well 👍 |
|
Dropping in here from Drupal-land (though I am far from a core maintainer, hopefully they can/will chime in here as well.) The earliest Drupal could do this wholesale is Drupal 11, which is tentatively scheduled for June, Sept. or Dec. 2024. Here's the Symfony 7 compatibility issue in our tracker. Personally I am working one issue (#52084) that would benefit from Symfony 7 in the Drupal 10 lifecycle, however I'm not sure our internal rules would even allow for that. From what I can see on the Serializer component, though, there are a lot of existing types in 6.x so there may not be too many compatibility issues there vs. other components. If I have some spare CPU cycles in the coming week I'll try to whip up a test run that applies the instructions in this issue and generates a report on our major items. |
|
Drupal does not appear to have any significant blockers from 6.4, however we are likely having to fork |
|
Thanks for checking in @bradjones1! Does this mean that Drupal doesn't see any type deprecation? That would be great news, otherwise we need to know before the end of the month (especially if the type is |
|
@wouterj There's a chance I could be missing something here, but our PHPstan baseline only had to add deprecations for Interestingly, I can't easily run the patch script as in the IS because Drupal dynamically adds modules to the autoloader depending on runtime configuration and I'm pretty confident that the testing in the CI suite (we recently added phpstan to all the things) would catch these issues anyway. |
|
Note that phpstan doesn't catch all type declaration and compatibility issues until level 6, and Drupal is afaics running at level 1 right now. It's not the most reliable indicator yet at this point. |
|
Good point. This is configurable on our new CI so let me play with that this weekend. |
|
As Symfony 7.0 is released last week, I'm closing this issue. Thanks to everyone for testing their apps against our pre-releases! |
Symfony 7.0 will come with type declarations to almost all methods, parameters and properties. See this blogpost for all information.
We acknowledge that introducing types impacts the whole Symfony open source ecosystem. As adding a type is a BC break, libraries are forced to release a new major version between now and December. Based on the experiences of bundles maintained by the Symfony team, we've postponed some impactful types to Symfony 8.0 already (increasing the timeframe for a new major version with two years).
We are open to, on a case by case basis, consider postponing more type declarations. If your library is blocked by one of the types we introduced, we would love to hear from you.
Test compatibility with 6.4/7.0 as early as possible by following these steps:
Update your Symfony dependencies to 6.4-dev, and temporarily install the
symfony/error-handlercomponent.Run the type patch script twice:
# the script relies on Composer's class map, check "exclude-from-classmap" in composer.json $ composer dump-autoload -o $ SYMFONY_PATCH_TYPE_DECLARATIONS=force=1 ./vendor/bin/patch-type-declarations $ SYMFONY_PATCH_TYPE_DECLARATIONS=force=1 ./vendor/bin/patch-type-declarationsThe script patches any methods that are private, final,
@internalor tests (i.e. methods that can safely be updated).The second run reports deprecations for methods that are not patched. Please double check if the unpatched methods should not be final or internal (i.e. should a user really extend or use this class?).
For the left-over deprecations, check if the type exists in the 7.0 branch. The 7.0 branch reflects the actual state, as postponed types will still trigger a deprecation in 6.4. You can suppress these deprections by adding the correct
@returnPHPdoc.If this is the case, please leave a comment with all details below.
Thanks for helping us towards type safety!
The text was updated successfully, but these errors were encountered: