Attribute Bundle Laravel Package

Getting Started

v3.0.0 settles the framework question. The release notes name config/bundles.php, config/routes.yaml, bin/console, Twig, Doctrine, Symfony Form types and an OptionsResolver — this is unambiguously a Symfony bundle, not a Laravel package. There is no ServiceProvider, no config/*.php, no vendor:publish. Before anything else:

composer show gbenitez/attribute-bundle   # verify name; GitHub repo is AttributeBundle

Inspect composer.json require for symfony/framework-bundle, doctrine/orm, twig/twig. If those are present (the notes imply all three), Composer will drag half of Symfony into a Laravel app if you force the install — don't.

Where to look first, in order:

1. INSTALLATION.md — new in v3.0.0; step-by-step, including the new-format bundles.php registration.
2. src/Entity/Attribute.php (or equivalent) — the most important file to read. The notes describe full CRUD with a JSON column and migrations, which means "attribute" here may be a domain entity persisted in a database, not a PHP 8 attribute reflector. Resolve this ambiguity before assuming the package does reflection at all.
3. src/Controller/ and src/Form/ — the Bootstrap 5 CRUD surface (list/create/edit/delete, CSRF-protected delete).
4. TROUBLESHOOTING.md — new; usually the honest list of what breaks.
5. tests/ — still the most reliable spec.

First use case: for a Symfony 5.4–7.x app, it's an admin CRUD UI over an Attribute entity with Doctrine persistence (JSON column, SQLite/MySQL). For a Laravel team the day-one use case remains unchanged: read it, confirm whether it's a reflection helper or a CRUD domain model, and port only the part you need — almost certainly not the Twig templates or Symfony Form types.

Implementation Patterns

If you run it as intended (Symfony): register in config/bundles.php, import routes in config/routes.yaml, run the Doctrine migration for the JSON column, and the CRUD works out of the box via autowired/autoconfigured services. Bootstrap 5 templates ship with it; override in templates/bundles/... only if pushed.

In Laravel — the honest port:

// Entity -> Eloquent model. Doctrine's JSON column maps to Laravel's json/array cast.
class Attribute extends Model
{
    protected $casts = ['value' => 'array'];   // replaces Doctrine json type
}

CRUD surface — rebuild, don't port. Symfony Form types, TranslatorInterface, Twig and OptionsResolver have no Laravel analogue worth carrying over. Use Filament/Nova (or Blade + Livewire) against the Eloquent model. The shape of the resource (list / create / edit / delete-with-confirmation, flash feedback) is worth copying; the code is not.

If the package turns out to also do PHP-attribute reading (verify src/), keep the prior pattern — declare attribute, scan namespace, cache the reflection map in a service provider, invalidate on deploy. Scanning is O(classes) and ReflectionClass is not OPcache-cached.

Isolate everything you borrow in app/Support/Attributes/ behind an interface you own. Bundles at this maturity get abandoned; you want to swap without a rewrite.

Prefer Laravel-native discovery (route/event discovery, #[Scope], container attributes) over standing up a parallel scanning or metadata system.

Gotchas and Tips

• Still not a Laravel package — and the gap widened. v3.0.0 adds Doctrine, Twig, Symfony Forms and a DB migration. That's a Symfony admin app, not a portable utility. Adoption cost went up, not down.
• PHP ceiling is 8.3. The release advertises "PHP 7.4 – 8.3". No 8.4 support, so it's already behind current Laravel-baseline PHP. Symfony 5.4 LTS support ends November 2025 — the widest-compat branch is on a clock.
• "Attribute" may be a domain entity, not a PHP attribute. The notes describe a persisted entity with a JSON column and CRUD around it. If you're expecting a ReflectionClass::getAttributes() helper, verify before porting anything; the previous assessment's framing may have been wrong about the package's purpose.
• Doctrine JSON → Eloquent cast. Porting the model means swapping the Doctrine json column type for Laravel's json cast and writing a normal Laravel migration. SQLite/MySQL both fine; watch JSON operator differences if you query into the column.
• CSRF is handled differently. The bundle relies on Symfony Form CSRF tokens; Laravel's VerifyCsrfToken middleware and @csrf apply instead. Don't carry token fields across.
• Breaking changes are real for v2.x users: annotations → PHP attributes, new bundles.php registration format, updated route imports, "clear cache and update the database". None of that concerns a Laravel app, but it means forks of v2.x are now diverged.
• Docs are in Spanish (INSTALLATION.md, TROUBLESHOOTING.md, README). Terminology won't match Laravel/Symfony English docs — budget for that.
• Debugging: Symfony side, bin/console debug:router, debug:container, doctrine:schema:validate; Laravel side, ground truth is var_dump((new ReflectionClass($x))->getAttributes()), and when a registry comes back empty the cause is nearly always autoload/classmap (composer dump-autoload -o) or a namespace-path mismatch.
• Attribute inheritance and repeatability still aren't automatic if reflection is involved: walk the hierarchy yourself, and confirm #[Attribute(Attribute::IS_REPEATABLE)] where duplicates are expected.
• Extension points are the Symfony Form types and Twig template overrides — both coupled to Symfony. If the reader/services are final, fork.
• Recommendation unchanged, with more confidence: v3.0.0 is a solid modernization of a small Symfony bundle, not a Laravel dependency. Treat it as reference code — possibly for the entity + CRUD shape rather than reflection — and build the twenty-line ReflectionClass scanner or a Filament resource in-house. Pin an exact commit if you vendor anything, and assume no security patches or timely PHP-version bumps.