Weave Code
Service Alias Autoregister Bundle Laravel Package
loophp/service-alias-autoregister-bundle
Symfony bundle that automatically registers service aliases, reducing manual container configuration. It helps keep dependency injection clean by wiring aliases based on implemented interfaces and class relationships.
Auto register services aliases in the Symfony container.
Frequently asked questions about Service Alias Autoregister Bundle
- Does loophp/service-alias-autoregister-bundle work with Laravel?
- No. It is a Symfony bundle that hooks Symfony's bundle extension and compiler-pass layer, so it boots through the Symfony kernel and the Bundle interface rather than Laravel's service container. There is no Laravel service provider or container bridge, and writing one is not considered worth the effort for what the package does. In a Laravel app you should use Laravel's own bindings, contextual binding, or a small custom service provider instead.
- What does this package actually do?
- It automatically registers service aliases in the Symfony container based on implemented interfaces and class relationships. Instead of hand-writing alias entries in services.yaml, the bundle derives them from your class hierarchies so interfaces and abstract types resolve to their concrete services. That removes a whole class of boilerplate and prevents cannot-autowire errors caused by forgotten aliases.
- How do I install loophp/service-alias-autoregister-bundle?
- On a Symfony application you add it with composer require loophp/service-alias-autoregister-bundle, then enable it with one line in config/bundles.php. After that you compile the container and warm the cache as usual. The release notes do not disclose the exact PHP and Symfony constraints for version 1.0.1, so check composer.json before installing.
- Which PHP and Symfony versions are supported?
- The published 1.0.1 notes do not state the php or symfony package constraints. That release included a switch to PHPUnit 10 and a generic modernize code refactor, both of which often imply raised minimum PHP and Symfony floors. Verify the constraints directly in the package's composer.json rather than inferring them from the changelog.
- How are alias collisions resolved when several services implement the same interface?
- This is not documented in the release notes, so treat it as unknown until you verify it in the source or with a test container. Implicit aliasing can silently pick the wrong concrete class when more than one service implements a shared interface, and the collision may only surface at compile time or on an edge runtime path. Build a throwaway container with two competing implementations and diff the result before trusting it.
- Do explicit aliases in services.yaml take precedence over auto-registered ones?
- The recommended rollout keeps your existing explicit services.yaml aliases in place during the trial, which keeps the blast radius small and lets them continue to win. You then diff the compiled container against the pre-change baseline and remove the manual entries only once equivalence is proven. Confirm the actual precedence rules in code before deleting anything.
- Can I disable auto-aliasing for a specific namespace or context?
- There is no documented compiler-pass kill switch for scoping or disabling the auto-aliasing per namespace. The practical approach is to enable the bundle in one bounded context first, such as a domain module with heavy interface usage, compile, and compare the generated container against the previous one. If you need granular control, verify whether a pass or configuration option exists before adopting it broadly.
- Is it safe to run in production?
- Aliases are container metadata resolved at compile time, so there is no meaningful runtime overhead once the container is built. The real risks are selecting the wrong concrete class when multiple implementations exist and collisions appearing late, either at compile time or in a rare runtime path. Roll it out incrementally, keep existing aliases during the trial, and diff the compiled container before shipping.
- What is the Laravel equivalent for auto-registering interface aliases?
- Laravel's container resolves concrete classes automatically but does not turn every interface into an alias for its implementation. You normally write $this->app->bind(MyInterface::class, MyImplementation::class) or singleton() calls in a service provider, or use contextual binding when multiple implementations exist. Those few lines are usually simpler than adding a Symfony-oriented bundle bridge to a Laravel app.
- Is the package actively maintained?
- It is a small loophp project whose recent 1.0.1 release was almost entirely CI and dependency chores, including actions/stale, setup-php, checkout and cache updates plus Renovate configuration. Internal work covered PHPUnit 10, a code modernization refactor, and style fixes, with no new features or documented breaking changes. Expect bot-driven upkeep rather than a commercial support contract, so pin the version and review upgrades yourself.
Weaver
How can I help you explore Laravel packages today?