Dry Bundle Laravel Package

Getting Started

Read the framing first: havvg/dry-bundle is a Symfony2-era bundle (~2012, symfony/symfony ~2.0, PHP 5.3/5.4, PSR-0 autoloading). It has no Laravel service provider, no facades, and 0 dependents. You will not composer require this into a Laravel app — the constraints will either fail or drag in abandoned transitive dependencies. Treat it as reference material, not a dependency.

Do this instead of installing:

1. Read the source in this order (it's small — a solid afternoon):
   • src/Havvg/Bundle/DRYBundle/HavvgDRYBundle.php — what the bundle registers.
   • DependencyInjection/HavvgDRYExtension.php + Resources/config/*.xml — where the actual "helpers" are declared as services. The XML reveals intent better than the README.
   • Model/ (or equivalent) — reusable entity/model boilerplate. This is the only part with real transferable value.
   • Util/ — string/array helpers. Usually plain PHP with no Symfony imports, so these are the only classes you could plausibly lift.
2. Check composer.json constraints before anything else. The symfony/symfony: ~2.0 pin and PSR-0 autoloading are the reasons for the "do not install" advice.
3. Your first real use case: open it side-by-side with app/Models/ in your Laravel project and ask "what boilerplate am I repeating that a trait would remove?" That's the whole thesis of this bundle — and Laravel already ships most of it (HasTimestamps, SoftDeletes, HasUuids, Str::slug).

If you're genuinely on a legacy Symfony 2.0 install (the only context where this runs): add new Havvg\Bundle\DRYBundle\HavvgDRYBundle() to AppKernel::registerBundles(), run app/console container:debug to see the exposed services, and app/console config:dump-reference HavvgDRYBundle to see available config keys.

Implementation Patterns

The bundle's thesis is "don't repeat yourself across entities/services." Here is how each pattern maps to Laravel — that's where day-to-day leverage actually comes from.

Pattern 1 — Model boilerplate via traits

Symfony/Doctrine forced hand-written getId(), setCreatedAt(), getSlug() on every entity. The bundle's contribution was trait-based mixins. Laravel equivalent:

// app/Concerns/HasSlug.php
trait HasSlug
{
    public static function bootHasSlug(): void
    {
        static::saving(function ($model) {
            $source = $model->slugSource ?? 'title';
            if (blank($model->slug) && filled($model->{$source})) {
                $model->slug = Str::slug($model->{$source});
            }
        });
    }
}

Use boot{TraitName}() conventions so multiple concerns compose cleanly. Cross-reference the bundle's trait names and methods to sanity-check for gaps (timestamp-on-update handling, __toString, identity comparisons).

Pattern 2 — String/array utility helpers

If the bundle ships pure-PHP StringUtil/ArrayUtil classes with no Symfony imports, those are the only files you can realistically vendor. Copy them into app/Support/ with attribution and the license header rather than pulling the package — this avoids the Composer constraint war entirely. But check Illuminate\Support\Str and Arr first; in modern Laravel the gap is usually just slug transliteration edge cases, which Str::slug($value, '-', 'de') already handles.

Pattern 3 — Service wiring (XML DI) → Service Providers

The bundle works through Resources/config/services.xml with tagged services. Translate the shape, not the code:

// XML <service id="..."> with <tag .../>  ==>
$this->app->singleton(MyHelper::class);
$this->app->tag([MyHelper::class], 'my.helpers');

The pattern worth stealing: tag-based collection of small services resolved on demand, not hardcoded bindings. Model it as a container tag plus a registrar/resolver class if you need extension points.

Pattern 4 — Twig extensions → Blade

Extension methods there map to Blade::directive(), or better, to plain helper functions or view components. Resist porting Twig filters one-for-one — Blade directives accumulate as untyped magic strings and are harder to test.

Pattern 5 — Repository/query helpers

Any base-repository or query-building helpers should be reimplemented as Eloquent local scopes or a base Model trait. A base repository class adds indirection in Laravel where Model::query() + scopes already reads well.

Integration tip — if you must share code: extract pure-PHP utility classes into your own app/Support namespace with a classmap autoload entry. Do not add the bundle to require, and do not expose Havvg\... classes in your public API. You want the ability to delete the copied files with a single rm.

Gotchas and Tips

• Abandoned and version-locked. The symfony/symfony ~2.0 constraint will conflict with every modern package in your tree. composer require havvg/dry-bundle in a Laravel app will fail or drag in ancient transitive deps. Don't try.
• PSR-0 autoloading. Expect class names to mirror directory structure with the namespace separator in the path. This does not play well with Composer 2's PSR-4-first world; even if you did install it, autoload mismatches would be the first failure.
• PHP 8.x incompatibilities. Dynamic properties, removed functions (each, create_function), and stricter type checks will break Symfony2-era code. Don't attempt to run it under PHP 8 without a full framework harness — not worth constructing.
• Hidden semantics in traits. DRY helpers often fold implicit conventions (magic method naming, container lookup behavior). A naive port can introduce subtle bugs — mirror the behavior, don't just copy the code shape.
• Don't leave it in composer.json "for reference." That invites accidental use and creates a standing security/upgrade risk. Keep a copy of the source in a docs/reference/ folder if you want it retained, with a README explaining why it lives there.
• Own the extraction. Any pattern you port must have a named owner, tests, and a place in your own conventions. Orphaned reimplementations accrete entropy and become dead code.
• Timebox the audit. 1–2 days max. If the audit surfaces nothing of clear current value in your Laravel codebase, close it out and record the "no-adopt" decision — the opportunity score (1.09) and 0 dependents strongly suggest that's the right default.
• Skip it silently for greenfield work. Modern Symfony bundles and Laravel-native packages solve the same problems with active maintenance. There's no scenario where reaching for this bundle in a new build is the correct call.