Add TraceableMessageBus stub with typed getDispatchedMessages()

[pscheit]

This adds stubs for the TraceableMessageBus to make it easier to write tests using this class.

[VincentLanglet]

Hi @pscheit,

Thanks for the PR.
For Symfony stubs I often recommend to open the PR adding the phpdoc on latest branch of Symfony repo first
https://github.com/symfony/symfony/blob/675cb3a1a285907bf4572333b29b1dc19d048d59/src/Symfony/Component/Messenger/TraceableMessageBus.php#L17

It's a good way to validate that the phpdoc added is right.

Then it can still be added here for previous versions.

[pscheit]

hey @VincentLanglet thanks for the info, last time I did this there was this policy at symfony that they would never add array shapes xD

[VincentLanglet]

hey @VincentLanglet thanks for the info, last time I did this there was this policy at symfony that they would never add array shapes xD

I cannot be sure about array shapes but I added conditional types and template type on symfony code base so i think it's worth trying.

[pscheit]

I'll give it a try :)

[stof]

I'm not sure those stubs should be added, as they would override any type defined in Symfony itself (and could become outdated if future Symfony versions add more things in the shape)

[VincentLanglet]

I'm not sure those stubs should be added, as they would override any type defined in Symfony itself (and could become outdated if future Symfony versions add more things in the shape)

This already have been the strategy for previous symfony stubs so I don't see a reason doing it differently for this one.

The issue is that Symfony only accepts those PHPDoc improvement as feature on the latest branch and

• Not every body use the latest version (some oldest are still supported)
• Worst, the latest branch is unreleased so people have to wait for the new minor release to fix those errors.

The way I see it, phpstan/phpstan-symfony solved those issues, and if the shape is outdated we can still fix it.

Maybe some times, old stubs should be deleted here when they are old-enough fixed on symfony side.

[staabm]

we might even include some stubs depending on the symfony version we can detect from composer locks

[stof]

This already have been the strategy for previous symfony stubs so I don't see a reason doing it differently for this one.

And this is based on the impact of those stubs that I'm making this feedback. We shipped a lot of type improvement in Symfony 7.3 and 7.4, and most of them were overridden by some stubs for users of phpstan-symfony.
For some cases, it was just confusing about why the better type was not used. For other cases, it was creating weird errors (for instance when types defined in stub were overriding only some of the new types of Symfony)

we might even include some stubs depending on the symfony version we can detect from composer locks

I agree. But #431 is not implemented yet.