Dry Bundle Laravel Package

Technical Evaluation

Architecture fit: Fundamental mismatch. Despite being framed as a "Laravel/PHP package," havvg/dry-bundle is a Symfony2 bundle (HavvgDRYBundle). Symfony bundles extend Bundle, register through services.yml/xml, compiler passes, and the Symfony DI container. Laravel packages extend service providers, facades, and the Laravel container. None of the bundle's wiring is portable. What is potentially transferable are the underlying "common pattern" helpers — and only as a rewrite, never a dependency.

Integration feasibility: Near zero as-is. There is no composer require path that yields working functionality in Laravel. The bundle also carries PSR-0 autoloading and a symfony/symfony ~2.0 constraint that will conflict with any modern dependency tree. Practical engagement means reading the source, extracting patterns (base classes, traits, utility helpers), and reimplementing them in Laravel idioms.

Technical risk: High.

• Framework EOL: Symfony2 (including 2.8 LTS) reached end of life in November 2018 — no security patches.
• PHP compatibility: 5.3-era code conflicts with PHP 8.x (dynamic properties, removed functions, stricter types).
• Adoption signal: 9 stars, 0 dependents, composite score 0.105. Effectively an unvalidated, abandoned artifact with no downstream battle-testing.
• Opportunity score 1.09: marginal upside even if the patterns prove relevant — value is in the ideas, not the artifact.

Key questions:

1. What specific patterns does the bundle encode (model traits, base repositories, string/array utilities, service registration conventions), and which — if any — are unmet needs in our Laravel codebase?
2. Do we have any legacy Symfony2 service still running where this artifact is directly relevant, rather than merely reference-worthy?
3. Who owns any reimplementation, its tests, and its ongoing maintenance?
4. Does a maintained, modern equivalent (Laravel-native traits, Illuminate\Support\Str/Arr, current Symfony equivalents) already solve the same problem without the risk?

Integration Approach

Stack fit: None directly. The bundle assumes the Symfony kernel, bundle registration, DI compiler passes, and Symfony's event dispatcher. A Laravel application cannot consume it. Any "integration" is a conceptual extraction into Laravel-native constructs (traits, base classes, service providers, container tags).

Migration path (time-boxed, 1–2 days max):

1. Audit — read src/Havvg/Bundle/DRYBundle/: the bundle class, DI extension, Resources/config/*.xml, and any Model/, Util/ classes. Enumerate concrete helpers.
2. Triage — score each against current needs (relevance, overlap with existing packages, maintenance cost). Stop here if nothing clears the bar and record a "no-adopt" decision.
3. Extract — document accepted patterns as ADRs / internal specs.
4. Reimplement — write Laravel-idiomatic equivalents (e.g. HasSlug via boot{TraitName}(), Eloquent scopes, container tags) with tests.
5. Never carry the bundle as a dependency — if pure-PHP utility classes are vendored, copy into app/Support/ with attribution and make them deletable with a single rm.

Compatibility: Reference code only. If any legacy Symfony environment exists in the estate, verify its Symfony/PHP versions before referencing the artifact; otherwise treat it purely as prose.

Sequencing: Audit → triage → ADR → reimplementation → tests. Default outcome should be closing after triage given the low expected yield.

Operational Impact

Maintenance: Effectively unsupported — no maintainer activity, Symfony2-era code, no security posture. It must not enter production dependencies; if it somehow did, it would be a standing unpatched-transitive-code risk.

Support: Zero community surface — 9 stars, 0 dependents, no issue-tracker activity or case studies. Any reimplemented pattern becomes entirely our support burden.

Scaling: Low runtime concern — DRY helpers are thin abstractions. The real scaling risk is organizational: a bespoke, un-owned reimplementation accretes entropy across products.

Failure modes:

• PHP/framework breakage — silent failures if anyone attempts to load Symfony2 code under modern PHP.
• Hidden semantics — DRY helpers often fold implicit conventions (magic method naming, container lookup behavior) that don't translate cleanly; naive ports introduce subtle bugs.
• Dependency confusion — leaving it referenced in composer.json invites accidental use.
• Orphaned reimplementation — extracted patterns with no owner become dead code.

Ramp-up: Reading the small codebase is trivial. Porting is moderate and self-funded. The real ramp is ownership: any adopted pattern must be assigned to a team, tested, and documented in our own conventions before it ships.

TPM recommendation: Do not adopt as a dependency. Run a short, time-boxed reference audit; proceed to reimplementation only if a pattern shows clear, current, unmet value in our Laravel codebase — and only with a named owner and tests. Given 0 dependents, a 0.105 composite score, and Symfony2 EOL, the default decision is to close this out after the audit and mine it only for inspiration.