Easy Admin Extra Bundle Laravel Package

Getting Started

Confirm the target runtime first. tourze/easy-admin-extra-bundle follows Symfony bundle conventions (*Bundle suffix, DependencyInjection/, Resources/config/), and the easy-admin name points at EasyAdmin rather than Laravel's Nova/Filament ecosystem. Before writing a line of code, decide which of these you are actually doing:

1. Laravel app + Symfony component — you are pulling in a Symfony bundle for a specific piece of functionality. You cannot use config/bundles.php; you will need to instantiate services manually or via a small service provider.
2. Symfony/EasyAdmin app alongside Laravel — normal bundle install, follow Symfony docs.
3. Pattern extraction — you are reading the source to copy the admin-extra behaviour into a Laravel package of your own.

Minimal steps (Composer + inspection):

composer require tourze/easy-admin-extra-bundle:^1.0

Then, before integrating:

• Read composer.json for require/require-dev — note the minimum PHP version and whether symfony/framework-bundle or easycorp/easyadmin-bundle are hard requirements (which would rule out option 1).
• Read the DependencyInjection/Extension.php and Configuration.php — that is the authoritative list of every config key the bundle accepts. Vendor READMEs in 1.0.0 releases are frequently thinner than the config tree.
• Read composer.lock-adjacent changelog: https://github.com/tourze/easy-admin-extra-bundle/compare/0.1.2...1.0.0 is the only release artefact for 1.0.0, so the diff itself is the changelog. Skim it for renamed classes, removed services, and bumped dependency constraints.

First use case: wire the bundle's admin "extra" surface into a single CRUD screen end-to-end — one entity, one index/detail view, one custom action — and confirm the extension hooks fire. Do not attempt a full admin migration until that single screen behaves.

Implementation Patterns

Register, then configure, then extend. The bundle's value is in its extension points, not its defaults. The working order is:

1. Register the bundle (or the service definitions, in the Laravel case).
2. Publish/import the default configuration and diff it against your Configuration.php reading — the defaults are usually tuned for the maintainer's own apps.
3. Only then attach your own EasyAdmin field configurators, action classes, or template overrides on top.

Keep the bundle at arm's length behind your own abstraction. Because 1.0.0 is the first stable release and the 0.x line went through at least three patch releases, treat the public API as stable-but-young. Wrap calls in a thin service of your own (e.g. App\Support\AdminExtras) so a future 1.1 rename does not ripple through every controller.

Composer constraint strategy. Pin ^1.0 rather than ~1.0.0 to receive patches, but commit composer.lock and review lock diffs on every composer update — a 0.x → 1.0 jump from this maintainer frequently ships with sibling tourze/* packages that move in lockstep. If you see unexpected transitive upgrades, that is the cause.

Testing pattern. Instantiate the bundle's services directly in a unit test rather than boot-testing the whole kernel. Symfony bundles of this shape are usually plain services with no container magic beyond autowiring, so a container-less test gives you fast feedback on the extension hooks.

Integration tip for Laravel users: put the bridge in a dedicated service provider and bind the bundle's classes as singletons. Mark the provider defer-able so apps that never touch the admin surface do not pay the boot cost.

Gotchas and Tips

• The 1.0.0 release notes are empty. The published release body is only a compare link. Do not assume "1.0.0" means "no breaking changes" — it means the maintainer is now promising no breaking changes. Everything between 0.1.2 and 1.0.0 is unannounced. Read the diff or you will be surprised at runtime.
• Symfony bundle ≠ Laravel package. No ServiceProvider, no config/*.php publish tag, no facades. Any tutorial you find for Laravel packages will mislead you here. Expect services.yaml, XML/YAML service definitions, and constructor autowiring.
• Bundle registration is silent when wrong. If the bundle is not in config/bundles.php (or your manual bindings are incomplete), you get "service not found" rather than a helpful error. When debugging, run bin/console debug:container <service-id> first — it distinguishes "not registered" from "registered but misconfigured."
• Config tree strictness. Symfony's Configuration.php usually rejects unknown keys outright. If you copy a config block from an older tutorial, expect a hard failure naming the offending key. Cross-check against the Configuration.php in the installed version, not the docs.
• Asset/template publishing. If the bundle ships admin templates or assets, they live under Resources/public and Resources/views. They are only copied out on an explicit publish/install command; edits to the vendor copy will be lost on the next composer update. Always override in your app, never in vendor/.
• Watch the sibling-package graph. tourze/* packages habitually depend on each other. A version constraint conflict on one will silently constrain the others; if composer require resolves an older-than-expected version, run composer why-not tourze/easy-admin-extra-bundle 1.0.0 to find the blocker.
• Extension points to look for first: custom EasyAdmin actions, field configurators, and CRUD controller traits. These are the intended seams; subclassing the bundle's own controllers is not, and will break on minor upgrades.
• Pin your PHP version in CI to match the bundle's require.php. Version jumps of this kind often accompany a minimum-PHP bump, which is the single most common cause of "works locally, fails in CI" for bundles like this.