Easyadmin Plus Bundle Laravel Package

Product Decisions This Supports

• Back-office build vs. buy (Symfony only). This is a candidate "buy" shortcut for the admin-panel slice of an internal-tooling roadmap: MIT, zero license cost, and it packages conveniences that would otherwise be 2–5 dev-days of glue (export of list views, richer filters, batch/custom actions, an AbstractCrudController base). The decision it informs is narrow: "do we spend engineering days re-implementing admin conveniences, or take a free dependency?"
• Legacy estate keep-vs-migrate. If a maintained product is pinned to Symfony 4 + EasyAdminBundle 2.x, this is an input to the roadmap question "extend the current admin, or fund a migration to EasyAdmin 3/4?" — not to the question "should we adopt this?"
• Dependency risk register / vendor scoring. 38 stars, 0 dependents, last release 2019-08-21, single-vendor (WandiParis). Any proposal that names this package should trigger a standard "unmaintained dependency" flag and a fork-and-own plan.
• Technical due diligence. Surfacing in an acquisition or platform audit, it reads as a signal of an unmaintained Symfony 4 back-office — useful for scoping remediation cost.
• Explicitly not a Laravel decision. Despite being framed as a "Laravel/PHP package," this is a Symfony 4 bundle wrapping EasyCorp/EasyAdminBundle. It carries zero leverage for a Laravel roadmap; the honest PM output is to remove it from that backlog entirely.
• Opportunity framing. The low opportunity score matches the reality: no greenfield use case, no ecosystem pull, and its architectural premise (configuring admin via a bundle) was replaced when EasyAdmin 3 moved to a controller/dashboard model.

When to Consider This Package

Consider it — with conditions — when:

• You are already running Symfony 4.x with EasyAdminBundle 2.x in production and need a small set of admin conveniences you'd otherwise hand-roll.
• You are prepared to treat it as source, not a dependency: MIT license and a small surface area make vendoring/forking realistic. Copy the traits and controller base into your own code, keep the attribution, and own the maintenance.
• The work is time-boxed legacy maintenance with a migration off Symfony 4 already on the roadmap, so the dependency's lifespan doesn't need to exceed yours.
• You need a reference implementation of export/filter/batch-action patterns to hand to an engineer as a starting point.

Look elsewhere when:

• The codebase is Laravel or any non-Symfony PHP stack — wrong framework, full stop.
• You are greenfield on Symfony 5/6/7: EasyAdmin 3+ replaced the bundle-configuration model, so this wrapper's abstractions no longer map onto the framework. Use native EasyAdmin actions/fields or a maintained alternative.
• You have a security or compliance gate: no releases in roughly six years means no CVE cadence, no supported-version policy, and no upgrade path you can rely on.
• You need support, SLAs, or a responsive maintainer — one vendor, no dependents, no recent activity.
• Admin export/filtering is a core product surface rather than a convenience: build it in-house or buy a supported product with a maintenance contract.

How to Pitch It (Stakeholders)

For executives (one paragraph). A free, MIT-licensed Symfony add-on that can shave a few engineering days off back-office work on legacy Symfony 4 admin panels. It is also effectively unmaintained — 38 stars, zero dependent projects, no release since August 2019 — and its core premise was obsoleted by EasyAdmin 3's rewrite. Recommendation: do not adopt it as a new dependency. Its only real value is as reference code: budget the 2–5 dev-days to write the equivalent ourselves and keep ownership. Separately, note the scope correction: this is a Symfony bundle, not a Laravel package, so it contributes nothing to our Laravel roadmap and should be struck from that backlog.

For engineering. Treat it as sample code, not a library. Read the AbstractCrudController base, the export action, and the filter classes; port what's useful into our own code with MIT attribution. If someone insists on installing it, require a fork we control, a pinned version, and an explicit owner — plus a written note on what replaces it when we leave Symfony 4.