Skip to content

[PhpUnitBridge] weak vendors mode silence legitimate deprecations #21991

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
theofidry opened this issue Mar 14, 2017 · 5 comments
Closed

[PhpUnitBridge] weak vendors mode silence legitimate deprecations #21991

theofidry opened this issue Mar 14, 2017 · 5 comments

Comments

@theofidry
Copy link
Contributor

theofidry commented Mar 14, 2017

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

@greg0ire
Copy link
Contributor

greg0ire commented Mar 14, 2017

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.

You may close this, it's the expected behavior. Only deprecations that come that a trigger_error call that can be found under /src will not be silenced. These are deprecations that you wrote yourself. Can you read the documentation and suggest changes to make it clearer maybe?

@greg0ire
Copy link
Contributor

To clarify the intended usage is for libraries that want a build job to shield them from in CI errors where they trigger their own deprecations.

@greg0ire
Copy link
Contributor

TL;DR: Symfony is a vendor too

@theofidry
Copy link
Contributor Author

Meh, that seems to be a missing mode then but I guess it's hard to have one that would do that 🙄

@greg0ire
Copy link
Contributor

@theofidry I thought about it but regexes as a value for SYMFONY_DEPRECATIONS_HELPER are already taken for something else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants