Skip to content

Document allow outdated vendors mode #8686

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.

Sign up for GitHub

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
wants to merge 2 commits into from
Closed

Document allow outdated vendors mode #8686

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ed845bd
Document allow outdated vendors mode
greg0ire Nov 16, 2017
e7dee0c
Add a table to summarize the modes
greg0ire Jan 29, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions components/phpunit_bridge.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -188,6 +188,39 @@ the ``vendors`` directory will make the test suite fail, while deprecations
triggered from a library inside it will not, giving you the best of both
worlds.

When working on a project, you might be more interested in the
``allow_outdated_vendors``, which is a bit more strict. Let's say you
want to fix deprecations as soon as they appear. A problem many people
experience is that some dependencies they have tend to lag behind their
own dependencies, meaning they do not fix deprecations as soon as
possible, which means there is nothing you can do to fix that (apart
from a pull request on the outdated vendor). This mode allows you to
ignore those deprecations, allowing you to notice when *your code* is
using deprecated APIs, and to keep up with the changes.

Here is a summary that should help you pick the right mode:

+------------------------+-----------------------------------------------------+
| Mode | Recommended situation |
+========================+=====================================================+
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recommended repeats a lot

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, not sure what to do about that…

| strict | Recommended for actively maintained projects |
| | with little to no dependencies |
+------------------------+-----------------------------------------------------+
| <some integer> | Recommended for projects that you cannot |
| | immediately fix but don't want to make worse. |
| | Can be used to transition from one mode to another. |
+------------------------+-----------------------------------------------------+
| allow_outdated_vendors | Recommended for projects with dependencies |
| | that fail to keep up with new deprecations. |
+------------------------+-----------------------------------------------------+
| weak_vendors | Recommended for libraries that use |
| | the deprecation system themselves and |
| | cannot afford to use one of the modes above. |
+------------------------+-----------------------------------------------------+
| weak | Not recommended; will probably lead to |
| | a big refactoring. |
+------------------------+-----------------------------------------------------+

Disabling the Deprecation Helper
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Expand Down