Doctrine Extension Laravel Package

Product Decisions This Supports

• Build vs. buy for Doctrine behavior extensions: This package is a “buy” candidate for commodity ORM behavior (custom DBAL types, mapping extensions, lifecycle behaviors), but its maintenance signals make it a poor buy. Use it as a benchmark when comparing maintained alternatives such as Gedmo DoctrineExtensions or a small in-house extension.
• Roadmap and dependency policy: Do not add this as a production dependency. If a roadmap feature depends on Doctrine extension behavior, scope the work as “use a maintained library or build a narrow in-house type,” not “integrate this package.”
• Feature prioritization: Timestamps, soft deletes, tree/nested-set behavior, slugs, and custom column types are commodity capabilities. They should not consume differentiated product/design time; pick the lowest-risk implementation and move on.
• Laravel stack fit: Laravel’s default ORM is Eloquent, which already provides timestamps and soft deletes, and mature packages cover nested sets. This package is Doctrine-oriented, so adopting it implies a deliberate Doctrine bridge (e.g., laravel-doctrine/orm) rather than a normal Laravel integration. That is an architecture decision, not a routine dependency.
• Risk register / vendor assessment: Zero stars, zero dependents, and no release since 2016 mean no community, no security-response process, and likely incompatibility with modern PHP and Doctrine versions. Capture this as supply-chain and upgrade risk, not just a technical preference.
• Legacy maintenance decisions: If an existing product already depends on it, treat the dependency as frozen: isolate it, avoid expanding its surface area, and budget an exit path during the next platform upgrade.

When to Consider This Package

• Only in a legacy context: You are maintaining an existing PHP/Doctrine application that already uses it, is pinned to PHP 5.x/7.x-era and Doctrine 2.x constraints, and has no near-term upgrade. Even then, plan replacement rather than new investment.
• As a reference, not a dependency: You need a small example of a Doctrine DBAL type or mapping extension and want prior art before writing a focused in-house implementation.
• When not to consider it: Any new build; any Laravel-native product using Eloquent; any stack on PHP 8+ or Doctrine 3; any environment with security, compliance, or support requirements; any team without deep Doctrine expertise. In those cases, use a maintained alternative (e.g., Gedmo DoctrineExtensions for common behaviors) or implement the narrow capability internally. Laravel teams should first check whether Eloquent built-ins or maintained Laravel packages already solve the problem.

How to Pitch It (Stakeholders)

For executives: This is a low-adoption, unmaintained open-source package with no release since 2016. It is not a strategic dependency and should not enter the product. The business risk—security exposure, upgrade blockage, and engineer time spent working around abandoned code—outweighs any short-term convenience. The capability it provides is commodity; a maintained alternative or a small in-house implementation is the lower-risk path.

For engineering: Treat this package as reference material, not production infrastructure. It has no meaningful community, no recent compatibility work, and no security-response path. On a Laravel product, it also does not fit the default Eloquent stack without introducing a Doctrine bridge. Recommended direction: use a maintained Doctrine extension library if you are already committed to Doctrine, or write a small, tested custom DBAL type/mapping extension if the need is narrow. If the product is Laravel-first, solve the need with Eloquent built-ins or a maintained Laravel package.