Attribute Bundle Laravel Package

Product Decisions This Supports

• Kill the "build vs. buy" question for Laravel. v3.0.0 resolves the ambiguity in the original assessment: this is a Symfony bundle, not a Laravel package. Registration is via config/bundles.php, routing via config/routes.yaml, console via bin/console, forms via Symfony Form Types. There is no Laravel service provider, no config/app.php registration path, no artisan integration. The PM decision this release supports is a scope-out, not an evaluation. Any roadmap item justified by "we could use this instead of hand-rolling attribute plumbing in Laravel" is now unsupported and should be closed.
• Category correction. The original assessment assumed this sat in the attribute-based configuration category (attribute-driven routing, validation, DI bindings, serialization hints). The release notes describe something narrower and different: a CRUD admin UI over attribute records — list/create/edit/delete with Bootstrap 5, flash messages, CSRF protection, Doctrine JSON columns, SQLite/MySQL. That is a demo or reference bundle, not a configuration engine. The PM takeaway: the category framing survives, but this package is not an instance of it. Do not use it as evidence either way when scoping declarative-config work.
• Roadmap sequencing. Symfony 8.x support is promised only for "v4.0.x when available" — i.e., a future commitment against a framework version that does not yet exist, stated in a release note. For a Symfony shop, that is a no commitment answer to the only maintenance question that matters a year out. Nothing here changes the view that adoption belongs behind a timeboxed spike, not a committed quarter.
• Dependency surface decision. The release does add real hygiene artifacts that did not previously exist: INSTALLATION.md, TROUBLESHOOTING.md, a migration guide from v2.x, and a modernized PHPUnit config. That is genuine maturity signal for a solo-maintainer repo. It is still one release on one date — docs and a changelog are not a maintenance track record, and there remain no downstream consumers to surface bugs. The PM still owns residual risk if this reaches production.
• Use cases worth testing (revised). Only relevant if you are a Symfony shop and the need is an internal admin surface for attribute records — in which case this is a scaffolding shortcut to be audited, not a library to depend on. The originally listed use cases (replacing docblock annotations across a legacy codebase, consolidating scattered config) are not what this release delivers and should be struck from the evaluation brief.
• Risk items newly introduced. The release is documented in Spanish only, including the install and troubleshooting guides that constitute the "maturity" signal above. Breaking changes are real (PHP 7.4+, Symfony 5.4+, Twig 3.0+, Doctrine annotations → PHP attributes). A team that cannot read the docs is being asked to trust a breaking major with no ecosystem backstop.

When to Consider This Package

Adopt-track criteria:

• You run Symfony, not Laravel. This is now a hard gate, not a "verify compatibility" caveat. Laravel shops should stop here.
• You are already on Symfony 5.4 LTS or 6.x, on PHP 7.4–8.3, and you have a concrete need for a CRUD admin UI over attribute records — not a declarative configuration mechanism.
• You can read Spanish, or have someone who can, for INSTALLATION.md and TROUBLESHOOTING.md. The operational docs are not in English.
• Source is small enough to audit in an afternoon and the team can fork and own it if the maintainer (single author, gbenitez) goes quiet.
• It is acceptable that Symfony 8 support is a stated intention for a future v4.0.x, not a commitment.

Look elsewhere when:

• You are on Laravel. This release removes any remaining doubt: the framework mismatch is structural, not a version-pin problem.
• You need a declarative attribute-based configuration library. This is a CRUD demo; the need is unmatched.
• It sits on a production-critical path with no internal PHP capacity to own a fork.
• You need documented support, security response commitments, English-language ops docs, or long-term maintenance guarantees.
• You only need one or two attributes — hand-rolling is cheaper and lower-risk than adding a dependency.
• You are on Symfony 7.x and want a stable dependency; the notes claim 7.x compatibility but the testing statement names only 5.4 LTS and 6.1.

How to Pitch It (Stakeholders)

Executives: The new major release does not change our position, and it does close one open question. It confirms this is a Symfony component, not a Laravel one, so it is out of scope for our stack. We are not spending evaluation time on it. The release itself is well-packaged — install guide, troubleshooting guide, migration path, modernized tests — which is a good sign for a small project, but it remains a single-maintainer dependency with no downstream users, no English operational docs, and a framework-support promise for a version that does not yet exist. Recommendation: no action, no budget, remove from the roadmap candidate list.

Engineering: v3.0.0 is a breaking major on a Symfony bundle: PHP 7.4+ / Symfony 5.4+ / Twig 3.0+, Doctrine annotations migrated to PHP attributes, modernized service config, Doctrine array → JSON column types, and a v2→v3 migration path. That is legitimate work. But the two things that matter to us are unchanged or worse: it is not a Laravel package (bundles.php, routes.yaml, bin/console, Symfony Form Types, Doctrine), and the actual feature set is a Bootstrap 5 CRUD admin UI over attribute records, not the attribute-driven config layer we were hypothetically scoping. The docs and PHPUnit config raise the health signal modestly; the untested-claim on Symfony 7.x and the Spanish-only operational guides lower it. If we want a spike on declarative attribute config, this is not the input — go back to evaluating maintained libraries or build the narrow piece ourselves. Close the ticket.