| Q |
A |
| Bug report? |
yes |
| Feature request? |
no |
| BC Break report? |
no |
| RFC? |
no |
| Symfony version |
3.3.0 (master) |
Not sure if that's the expected behaviour, but say if you have a test requesting a private service, you should get a warning along the lines of:
Requesting the "PrivateFoo" private service is deprecated since Symfony 3.2 and won't be supported anymore in Symfony 4.0
However if you use PhpUnitBridge with weak_vendors mode introduced in #21539, then this deprecation notice will be silenced.
I'm not sure if that's the expected behaviour, my understanding of weak_vendors was that third-party deprecations, as a third-party bundle using a deprecated feature, would be silenced, not any deprecation thrown by Symfony itself triggered or not by your code.
Steps to reproduce:
Inside tests.sh we can see that with weak_vendors, all deprecation notices are caught whereas without it, the deprecation notice for requesting private services is thrown (and is triggered by the user code).
/cc @greg0ire
Not sure if that's the expected behaviour, but say if you have a test requesting a private service, you should get a warning along the lines of:
However if you use PhpUnitBridge with
weak_vendorsmode introduced in #21539, then this deprecation notice will be silenced.I'm not sure if that's the expected behaviour, my understanding of
weak_vendorswas that third-party deprecations, as a third-party bundle using a deprecated feature, would be silenced, not any deprecation thrown by Symfony itself triggered or not by your code.Steps to reproduce:
composer install./tests.shInside
tests.shwe can see that withweak_vendors, all deprecation notices are caught whereas without it, the deprecation notice for requesting private services is thrown (and is triggered by the user code)./cc @greg0ire