React Admin Api Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for admin/back-office CRUD. This bundle supplies the server-side plumbing behind a react-admin front end (list, sort, filter, soft-delete traits). The decision it informs is whether we hand-roll CRUD endpoints or adopt a convention layer — 1.3.0 keeps that "buy" option viable rather than shrinking it.
• Feature feasibility: soft delete. Through 1.2.x, SoftDeleteTrait::delete() raised a TypeError on every call, meaning soft delete was effectively a non-shippable feature. Any prior evaluation that struck soft delete from scope (or rejected the package outright on that basis) should be re-run. It now behaves like DeleteTrait: success, or 400 for an unknown id.
• Platform roadmap sequencing. Symfony 8 support (PHP 8.4 + DoctrineBundle 3) means this package is no longer a blocker in a Symfony 8 migration plan — but it does inherit DoctrineBundle's upgrade notes, so the dependency chain, not the bundle, becomes the gating item. Symfony 6.4 and 7.x remain supported, so we are not forced to move.
• Upgrade risk budgeting. The ORM 3.7 sort-direction deprecation was handled ahead of a break (enum where accepted, string on older ORMs). That is a forward-compatibility signal we can price into a "stay current" maintenance budget rather than a forced migration later.
• Vendor footprint / packaging. Tests, CI and dev files no longer ship in the Composer package. Marginal, but it simplifies our dependency review and licence/artifact scanning — no functional change.

When to Consider This Package

Adopt when:

• We are building an admin/back-office UI on react-admin (or a comparable JSON-API consumer) against API Platform + Doctrine ORM.
• The entity model is largely conventional CRUD, and we want list/sort/filter/soft-delete behaviour off the shelf instead of a bespoke trait layer to own and test.
• We are on PHP 8.2+ and Symfony 6.4 or 7.x today (8.x only if we are already on PHP 8.4 and DoctrineBundle 3).
• The team values convention over bespoke code and can absorb a small, single-maintainer dependency.

Look elsewhere when:

• We are not on API Platform / react-admin — most of the value evaporates.
• We need capabilities the traits do not cover (complex authorization, audit trails, multi-tenancy, workflow) and would end up writing custom code anyway.
• We require vendor SLAs, paid support, or a multi-maintainer project — this is a small open-source bundle.
• We are pinned below PHP 8.2 or on Symfony <6.4.
• We need guaranteed long-term API stability; the 1.2.x soft-delete defect is evidence that trait-level correctness has not always been covered by tests, and CI hardening only landed in 1.3.0.

Conditions of adoption: pin the version, add integration tests around the traits we actually use (especially delete semantics and sort direction), and monitor releases rather than floating on ^1.x.

How to Pitch It (Stakeholders)

For executives: This is a small, free open-source component that removes a meaningful chunk of hand-written back-office plumbing from our admin tooling. The 1.3.0 release matters for two reasons: it fixes a defect that made soft delete unusable on every call, and it adds Symfony 8 support so it will not anchor us to an ageing framework version. Cost is low, reversibility is high, and the main exposure is that it is maintained by a very small team — mitigated by version pinning and our own integration tests.

For engineering: Upgrade is low risk and backwards compatible — a semver-minor with a behaviour fix (delete now returns success or 400 instead of throwing) plus an ORM 3.7 sort-direction shim that keeps older Doctrine working. Symfony 8 support requires PHP 8.4 and DoctrineBundle 3; nothing changes if we stay on 6.4/7.x. CI now covers PHP 8.2–8.5 against Symfony 6.4, 7.4 and 8.x with PHPStan 2 at level 8, which is a genuine quality step up from the release that shipped a broken soft delete — but it is new, so we should not treat trait behaviour as proven until our own tests cover it. Dev files are no longer shipped in the package, so no build changes needed.