Dry Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. ignore: This is a "don't buy" decision. With 9 stars, 0 dependents, a composite score of 0.105, and a Symfony2-era scope, havvg/dry-bundle should not be adopted as a dependency. The PM decision it supports is to classify it as reference material, not infrastructure.
• Roadmap: Keep it off the roadmap for any new product or Laravel build. It has no roadmap capacity to offer — Symfony2 reached end of life in November 2018, so there is no security or upgrade path. The correct roadmap entry is a note to avoid it, not to schedule it.
• Framework mismatch resolves a common "is this a Laravel package?" question: Despite being framed as a Laravel/PHP package, it is a Symfony2 bundle (HavvgDRYBundle) wired through bundle registration, XML/YAML service definitions, and compiler passes. None of that surface is portable to Laravel. The PM takeaway is that any "Laravel integration" here is actually a rewrite, and rewrites must be justified on their own merits — which this package does not supply.
• DRY-pattern mining, not adoption: The only transferable value is the ideas — trait-based model boilerplate (timestamps, slugs, __toString), tag-based service collection, and small pure-PHP string/array helpers. Those ideas belong in an internal ADR and a Laravel-native implementation (boot{TraitName}() conventions, service providers, Illuminate\Support\Str/Arr, local scopes), not in composer.json.
• Legacy containment decision: If a team inherits a Symfony2 application that already uses this bundle, the PM decision is to isolate and document the dependency and plan removal during modernization — not to expand its footprint.
• Technical-debt signal: 0 dependents and low adoption are signals to track risk, not evidence of value. Use them as inputs when prioritizing modernization work.

When to Consider This Package

• Consider it only as a reference read when the team is maintaining an inherited Symfony2 codebase, or when someone wants concrete examples of DRY helpers before designing an internal shared library in Laravel. This is a time-boxed audit (roughly 1–2 days), not an integration task.
• Do not consider it for greenfield work, modern Symfony or PHP 8.x projects, Laravel applications, or anything requiring a security posture, long-term support, or active community maintenance.
• Look elsewhere for durable shared code: internal packages, Laravel-native concerns/traits, current Symfony bundles, or well-maintained utility packages. Modern Laravel already ships most of what this bundle was created to solve (HasTimestamps, SoftDeletes, HasUuids, Str::slug).
• Block adoption whenever zero dependents, an EOL framework, PSR-0 autoloading, and pinned symfony/symfony ~2.0 constraints create unacceptable upgrade and support risk — which is the case here.
• Proceed past the audit only if it surfaces a specific, currently unmet pattern in your codebase, and only with a named owner, tests, and an ADR. The default outcome should be a recorded "no-adopt" decision.

How to Pitch It (Stakeholders)

Executive summary: havvg/dry-bundle is a small, abandoned Symfony2 helper bundle with essentially no adoption — 9 stars, zero dependents, and a framework that reached end of life in 2018. It offers no strategic or commercial leverage and is not usable in our Laravel stack; adapting it would be a rewrite, not an integration. Recommendation: do not adopt, do not add it to any product plan. If it appears in legacy code, isolate it, document the dependency, and schedule removal during modernization. The only spend justified here is a short, time-boxed reference audit to see whether any of its DRY patterns are worth reimplementing ourselves.

Engineering summary: Treat this as reference material. Nothing in its Symfony bundle wiring — service definitions, compiler passes, kernel registration — maps onto Laravel's service providers and container. Reading the source is cheap and may surface useful patterns for model traits, tag-based service collection, and small pure-PHP utilities; porting any of it is self-funded work we would own entirely. If we extract anything, reimplement it idiomatically in Laravel with tests and an owner — never by adding Havvg\... classes or the package to require. Verify licensing before copying a file, keep the copied surface small enough to delete in one commit, and record the outcome (adopt-a-pattern or no-adopt) as an ADR so the question doesn't resurface.