Weave Code
Sonata Auto Configure Bundle Laravel Package
nucleos/sonata-auto-configure-bundle
A Symfony bundle that automatically configures Sonata Admin services and resources, cutting boilerplate so you can register admin classes with minimal setup. It simplifies service definitions and common configuration tasks, helping you get your Sonata backend running faster with less manual YAML.
Nucleos SonataAutoConfigureBundle simplifies Sonata Admin integration in Symfony by automatically discovering and registering admin classes as services. Instead of maintaining repetitive service definitions, you configure the namespaces or paths to scan and the bundle applies the required sonata.admin tags and sensible defaults.
- Convention-based discovery of Sonata admin classes
- Automatic service registration and tagging
- Configurable namespaces, paths, and admin defaults
- Reduces YAML/XML boilerplate
- Fits Symfony’s DI and autoconfiguration workflow
Frequently asked questions about Sonata Auto Configure Bundle
- Can I use nucleos/sonata-auto-configure-bundle in a Laravel application?
- No. This package is a Symfony bundle that hooks into the Symfony dependency-injection container during compilation to register Sonata Admin services, so it depends on Symfony's bundle system and SonataAdminBundle. Laravel's service container and package discovery work differently, and there is no Laravel integration. If you are evaluating PHP admin panels for Laravel, look at Laravel-native options such as Filament or Nova instead.
- How do I install nucleos/sonata-auto-configure-bundle?
- Install it with Composer using composer require nucleos/sonata-auto-configure-bundle, then enable the bundle in config/bundles.php for the environments where you use Sonata Admin. You also need a working SonataAdminBundle installation with its routes, security, and admin manager configuration already in place. Finally, make sure your admin classes live in a namespace covered by autoconfigure and autowire in services.yaml.
- Which Symfony and SonataAdminBundle versions are supported?
- The authoritative answer is in the package's composer.json, and you should read it before adopting rather than assuming broad compatibility. Sonata Admin tag names and AdminInterface signatures have changed across major releases, so verify the constraint against the exact sonata-project/admin-bundle version you run. Pin the bundle version and gate upgrades behind a container-compile test in CI.
- How does this bundle reduce Sonata Admin boilerplate?
- It is a thin Symfony DI extension that discovers admin classes and registers sonata.admin service definitions with the appropriate tags and manager wiring, instead of you hand-writing YAML or XML for every admin. That means fewer per-class service blocks and less chance of a missing tag causing an admin to disappear from the dashboard. It is an ergonomics layer, not a replacement for SonataAdminBundle itself.
- Does it support child admins, dashboard groups, and AdminExtension?
- That is one of the unknowns you must verify against your own admin features before adopting. The package is small and likely covers the happy path of registering a top-level admin, while nested child admins, custom dashboard groups, AdminInterface extensions, security voters, and translations may still need explicit configuration. Prototype with the admin types you actually use and inspect the compiled container rather than assuming full coverage.
- What happens if an admin class is also defined explicitly in services.yaml?
- You risk duplicate or conflicting sonata.admin definitions, which can surface as a container-compile error or a mis-tagged service. Test this directly by dumping the container with bin/console debug:container --tag=sonata.admin before and after enabling auto-configuration. The safest approach is to move one bounded namespace at a time and keep explicit definitions behind a feature flag until parity is proven.
- How do I exclude specific admin classes from auto-configuration?
- Use the standard Symfony services.yaml escape hatch by excluding the class or namespace from the resource block that has autoconfigure enabled, then register that admin manually. Because the bundle is a DI extension rather than a runtime feature, you can also fall back to hand-written sonata.admin tags per class at any time. Confirm the exclusion behavior with a container dump so you know the admin is registered exactly once.
- Is nucleos/sonata-auto-configure-bundle production-ready and actively maintained?
- Adoption signals are thin: roughly 3 GitHub stars, 0 dependents, and an unproven footprint that suggests a single-maintainer package. The reported last-release timestamp also looks anomalous, so confirm the real version history on Packagist before trusting it. Its blast radius is contained because failures show up as container-compile errors at build or deploy time, but you should still pin the version, review the DI extension source, and check whether CI runs a test suite.
- How does it compare with EasyAdmin or configuring Sonata Admin manually?
- Manual Sonata configuration is the low-risk baseline: explicit, well documented, and easy to debug. This bundle only removes boilerplate for teams already committed to Sonata Admin and Symfony autowiring. If you have not chosen an admin layer yet, EasyAdmin is the lower-risk default, and this package's adoption signals do not justify selecting Sonata Admin on its behalf.
- How should I test migrating existing Sonata Admin service definitions to auto-configuration?
- Create a POC branch, move one admin namespace such as App\Admin\Catalog to autoconfigure, and diff the compiled container using bin/console debug:container --tag=sonata.admin against the original. Keep the explicit definitions available behind a configuration flag so rollback is a config change rather than a code revert. Add a compile-time regression test that asserts each expected admin is registered exactly once, and watch for interactions with other compiler passes that manipulate sonata.admin tags.
Weaver
How can I help you explore Laravel packages today?