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:

1. Update your Symfony dependencies to 6.4-dev, and temporarily install the symfony/error-handler component.

2. 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-declarations

3. The script patches any methods that are private, final, @internal or 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?).

4. 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 @return PHPdoc.

   If this is the case, please leave a comment with all details below.

Thanks for helping us towards type safety!