Easyadmin Plus Bundle Laravel Package

Product Decisions This Supports

• Scope check first: this is not a Laravel package. protrung/easyadmin-plus-bundle is a Symfony bundle that extends EasyAdmin. If our admin/back-office surface is Laravel (Filament, Nova, custom Blade), this package is out of scope and the decision is closed. It is only relevant if we run a Symfony/EasyAdmin back-office alongside (or instead of) the Laravel product.
• Build vs. buy for back-office ergonomics: the bundle is a thin add-on layer over EasyAdmin, not a framework. The real decision is "EasyAdmin + this bundle" vs. "EasyAdmin alone" vs. "build our own admin." It only wins if it removes small, recurring custom work — which is exactly what v0.4.1's ConfirmationModal does.
• Roadmap: safer destructive actions in internal tooling. ConfirmationModal lets custom EasyAdmin actions declare a confirmation dialog with a title and body. That directly supports shipping higher-risk operator actions (refunds, deletions, impersonation, bulk state changes, permission grants) with an explicit "are you sure, and here's why" step — without bespoke Twig/JS per action. This is a safety/UX enabler for ops-facing features, not a customer-facing capability.
• Upgrade planning, not a feature bet. The EasyAdmin 5.7 allowance is maintenance work: it keeps the bundle installable on a current upstream. Treat it as part of the next EasyAdmin minor upgrade, not as a reason to adopt.
• Vendor/dependency posture: a 0.x, single-maintainer package with modest PR volume. That is a deliberate "small, cheap, replaceable" dependency decision — acceptable to reduce glue code, unacceptable as a load-bearing part of the admin platform.

When to Consider This Package

Consider it when:

• We have a Symfony application on, or actively migrating to, EasyAdmin, and the team is already comfortable with Composer-pinned PHP dependencies.
• The gap we want closed is narrow and ergonomic — e.g., consistent, titled confirmation dialogs on custom admin actions — rather than a whole admin framework or workflow engine.
• We accept the constraints of a pre-1.0 package: possible breaking changes on minor bumps, a single primary maintainer (bus factor of one), and a need to read the source when docs are thin.
• We can absorb a fast cadence of upstream compatibility bumps (v0.4.1 exists specifically to unblock EasyAdmin 5.7), meaning someone owns the upgrade.

Look elsewhere when:

• The stack is Laravel — use Filament/Nova or in-house; this bundle provides nothing here.
• We need contractual stability, LTS support, security SLAs, or an audited release process. Upstream EasyAdmin alone, or a commercially supported admin platform, is the safer call.
• The requirement is deep: audit trails, approval workflows, RBAC matrices, compliance logging. Those belong in our application code, not in a UI convenience bundle.
• Adding any 0ver dependency requires a formal security/procurement review that the package's size cannot justify.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source add-on for Symfony admin back-offices — not for our Laravel product. The new v0.4.1 release does two modest things: it keeps the package installable on the current EasyAdmin version, and it adds a reusable confirmation dialog so operators get a titled, explanatory prompt before risky actions. There are no breaking changes and no action is required. My recommendation is to treat it as an optional, low-cost convenience layer for internal tooling only — worth a short timeboxed trial if and when we next touch a Symfony admin surface, and explicitly not a platform commitment.

For engineering (talking points):

• What shipped in v0.4.1: (1) EasyAdmin 5.7 installability — a compatibility fix that unblocks the upstream upgrade; (2) ConfirmationModal — custom action confirmations now carry a title and body, replacing per-action hand-rolled dialogs.
• No breaking changes, no deprecations in this release; nothing forces an upgrade. Adopt during the next EasyAdmin bump rather than as a standalone migration.
• Integration cost is low but non-zero: pin an explicit version constraint, add a smoke test that an action's confirmation renders with title/body, and note the bundle's coupling to EasyAdmin minors — every upstream bump may require a matching bundle release.
• Risk to manage: single maintainer, 0.x versioning. Keep it behind an interface/isolated to admin config so it can be swapped for native EasyAdmin behavior or removed in an afternoon.
• Ask: a half-day spike on one non-critical destructive admin action to validate the confirmation UX and the upgrade path; decision gate is whether it removes more custom Twig/JS than it adds in dependency overhead.