Thin library around different deprecation strategies
1.9k
Stars
20
Forks
7
Open issues
19
Contributors
AI Analysis
Doctrine Deprecations is a lightweight PHP library that provides a standardized layer for triggering and managing deprecation notices across Doctrine and other libraries. It offers flexible backends (PSR-3 logging, trigger_error, or silent tracking), deduplication to reduce overhead, and no side effects by default—making it ideal for library maintainers who need to communicate API changes without imposing error handling requirements on consumers.
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Doctrine Deprecations: Minimal, side-effect-free deprecation layer for PHP libraries
Doctrine Deprecations is a thin wrapper around PHP's trigger_error() and PSR-3 logging designed to help library authors signal breaking changes safely. It decouples deprecation handling from global error handler state, supports deduplication and tracking, and integrates with PHPUnit for test assertions. Adopted within the Doctrine ecosystem and broader PHP libraries that prioritize backwards compatibility signaling.
Created in July 2020, likely in response to the need for a standardized, reusable deprecation strategy across Doctrine projects. The library consolidates patterns that were previously implemented ad-hoc in individual packages, providing a shared abstraction for library authors.
The project has grown to 1,857 stars with modest velocity (1 star in last 7 days as of 2026-07-05). Growth appears steady rather than accelerating, suggesting adoption is driven by intentional adoption by library maintainers rather than viral demand. Being a low-level utility for library authors, not end users, explains the modest star count relative to its likely integration depth.
Adoption not explicitly verified in README, but the project is part of the official Doctrine organization, and given the ecosystem of Doctrine projects (ORM, migrations, cache all >4k stars), integration is likely widespread within that ecosystem. The library's purpose (library-to-application communication) makes star count a poor adoption metric; real adoption signal would require surveying downstream dependencies, which is not available here.
Based on README, the library provides static methods on a Deprecation class with multiple operational modes: trigger (always fire), triggerIfCalledFromOutside (stack-aware), enableWithPsrLogger (PSR-3 integration), enableWithTriggerError (native PHP), and enableTrackingDeprecations (silent tracking). Deduplication is built-in and can be disabled. Likely uses stack inspection to detect call origin and message hashing for deduplication. The design prioritizes composability and zero side-effects by default.
README documents PHPUnit integration with a VerifyDeprecations trait for assertion-based testing and suite-level reporting. No quantitative test coverage metrics provided in README. The existence of dedicated test tooling suggests deliberate test infrastructure, though coverage percentage not documented.
Last push 2026-06-14 (21 days before analysis date), indicating active, recent maintenance. MIT license, 20 forks, minimal GitHub stars velocity but consistent engagement. The recent push suggests the project is not dormant; modest velocity is consistent with a mature, stable utility that doesn't require frequent changes.
ADOPT IF: You are a PHP library author who needs a backwards-compatible way to signal breaking changes without depending on application-level error handling configuration, or if you are building on Doctrine and want integration with existing Doctrine patterns. AVOID IF: You are building a standalone application (not a library) or your deprecation needs require custom business logic beyond standard triggering and logging. MONITOR IF: You are evaluating deprecation strategies in a large PHP ecosystem and want to assess whether standardizing on Doctrine Deprecations vs. Symfony's variant makes sense for your organization.
Independent dimensions
Mainstream potential
4/10
Technical importance
6/10
Adoption evidence
3/10
- Adoption outside Doctrine ecosystem is unverified; the library may remain a 'Doctrine-internal' tool rather than a standard across PHP libraries.
- Stack inspection for triggerIfCalledFromOutside may be fragile or have false positives/negatives in unusual call contexts (e.g., dynamic calls, reflection), though README does not document known limitations.
- Deduplication is based on message identifier (URL); if identifiers are collision-prone or poorly managed, deduplication could mask real issues or fail to consolidate related warnings.
- PSR-3 integration is documented but may not be widely adopted in practice if library users still rely on native trigger_error; unclear whether PSR-3 adoption is growing among PHP library maintainers.
- The project is owned by Doctrine organization; if Doctrine loses community momentum or diverges from broader PHP standards, adoption barriers could increase.
Likely to remain stable and actively maintained within the Doctrine ecosystem. Adoption beyond Doctrine will probably remain modest unless the broader PHP community converges on a single deprecation standard; Symfony's variant may be more likely to become the de-facto standard due to Symfony's larger community reach. This library will probably continue serving its niche well without major growth.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Website
- https://doctrine-project.org
- Language
- PHP
- License
- MIT
- Last updated
- 4w ago
- Created
- 73mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Treat calls from PHPUnit as outside calls
Incorrect filename is being logged
RFC: detecting and handling unfixable deprecations
Libraries path is hardcoded to `/vendor`
Integrate with PHPUnit
Open pull requests
Recent releases
Similar repos
doctrine/cache
Doctrine Cache is a caching component extracted from Doctrine Common that...
doctrine/lexer
A lightweight PHP library providing a base lexer implementation for building...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
1.9k | — | PHP | 8/10 | 4w ago |
|
|
2.1k | — | PHP | 8/10 | 2w ago |
|
|
4.8k | — | PHP | 8/10 | 3w ago |
|
|
7.9k | — | PHP | 6/10 | 9mo ago |
|
|
11.2k | — | PHP | 8/10 | 4w ago |
|
|
3k | — | PHP | 8/10 | 1w ago |
Similar scope and purpose; 2,113 stars vs 1,857. Both provide PSR-3 integration and trigger_error wrapping. Symfony's version may have broader adoption due to Symfony ecosystem reach, but Doctrine Deprecations is agnostic to framework and can be used standalone.
Not a competitor but primary consumer; ORM is likely the largest user of this library within Doctrine ecosystem, validating the deprecation strategy at scale.
This library adds value over raw trigger_error by decoupling from global error handlers, enabling PSR-3 logging, deduplication, and safe library-internal usage via stack inspection.
Not directly competitive; Doctrine Deprecations signals deprecations, while Sentry and similar tools *collect* errors post-hoc. They can be complementary (deprecations fed into Sentry via PSR-3).
This library eliminates the need for per-project deprecation tooling, providing a standardized interface and reducing maintenance burden.