Weave Code
Common Bundle Laravel Package
anzusystems/common-bundle
AnzuSystems Common Bundle by Petit Press provides shared functionality for Anzusystems' Symfony projects. Install via Composer, extend AnzuKernel in your Kernel.php, and configure app system name, version, and read-only mode in config/packages/anzu_common.yaml.
AnzuSystems Common Bundle is a Symfony bundle by Petit Press a.s. that provides shared functionality across AnzuSystems projects. Install it via Composer, then extend AnzuKernel in your Kernel.php and initialize it on every entry point (such as public/index.php and bin/console), passing application-specific parameters.
- Extend
AnzuKernelfor consistent application bootstrapping - Configure system name, version, and read-only mode per environment
- Initialize the kernel uniformly across all entry points
- Define bundle settings in
config/packages/anzu_common.yaml - Reuse common logic across multiple AnzuSystems projects
Frequently asked questions about Common Bundle
- What is anzusystems/common-bundle used for?
- It provides common functionality shared across AnzuSystems projects, including Symfony-oriented utilities such as logging, health checks, permissions, caching, concurrency locks, and MongoDB audit or journal features. It is installed via Composer and configured through anzu_common.yaml. It is not a general-purpose Laravel package, so evaluate its fit against your application architecture.
- Is anzusystems/common-bundle compatible with Laravel 11?
- There is no official Laravel 11 support claim; this is a Symfony bundle and compatibility depends on matching Symfony component versions. The fit is partial because the bundle is tightly coupled to Kernel, Messenger, Doctrine, Security, and EventDispatcher, while Laravel uses ServiceProviders, Facades, and its own event system. You can integrate selected pieces with adapters, but extending AnzuKernel in Laravel is high friction because Laravel's Kernel is a singleton. For most Laravel apps, native packages are simpler unless the bundle's specialized features are essential.
- How do I install anzusystems/common-bundle?
- Run composer require anzusystems/common-bundle --no-scripts from your project or container. Then change your Kernel to extend AnzuKernel and pass appSystem, appVersion, appReadOnlyMode, environment, and debug. Initialize the kernel in entry points such as public/index.php and bin/console, and define configuration in config/packages/anzu_common.yaml. In Laravel you need extra bridging because Laravel does not use Symfony bundles and config/packages in the same way.
- Why must I extend AnzuKernel, and can I avoid it in Laravel?
- The bundle expects AnzuKernel to inject the app system name, app version, and read-only mode and to wire Symfony bundle behavior. Laravel's HTTP and Console Kernel are singletons and cannot be swapped without refactoring bootstrap. A workaround is a proxy or microkernel that delegates to AnzuKernel while preserving Laravel's bootProviders and registerContainerBindings, but it is non-trivial. Treat this as a major integration decision.
- How is anzusystems/common-bundle configured?
- In Symfony projects configuration lives in config/packages/anzu_common.yaml. Laravel uses .env plus config PHP files, so you need a ServiceProvider or ConfigPublisher to map YAML settings into Laravel config. Centralize values such as lock TTL and feature flags so they can be sourced from config rather than hardcoded. Validate the mapped configuration during boot.
- What changed with lock TTL in version 11.8.0?
- ResourceLocker::lock() now accepts an optional ttl in seconds, defaulting to ResourceLocker::DEFAULT_TTL, where the previous value was hardcoded at 60 seconds. This is an additive, backwards-compatible change that aligns better with Laravel's Cache::lock($name, $seconds) semantics. It removes a latent correctness risk for long-running queue jobs or commands that exceed 60 seconds. Set TTL above your maximum job runtime plus buffer.
- Are there dependency conflicts with Laravel?
- Possible dependency conflicts exist. The bundle assumes Symfony 8.x per changelog and pulls Symfony components plus MongoDB and Redis related dependencies that may conflict with Laravel's Symfony bridge or packages such as jenssegers/mongodb and predis/predis. Check composer why-not and platform requirements before adoption. Use Laravel-native MongoDB and Redis packages and wrap bundle services where possible, and pin versions for testing.
- Can I use the bundle's health checks, permissions, and logging in Laravel?
- You can reuse concepts or wrap services, but not drop them in directly. Laravel's event system is incompatible with Symfony's EventDispatcher, so exception listeners, health checks, and logging need bridges or replacement with Laravel-native packages such as spatie/laravel-health and spatie/laravel-permission. Only adopt bundle features that provide unique value over Laravel's ecosystem. Profile latency impact for health checks and locks.
- Is anzusystems/common-bundle production-ready for a Laravel app?
- It can be production-ready only after deliberate integration work and testing. Main risks are Kernel incompatibility, Symfony-Laravel abstraction gaps, configuration overhead, dependency conflicts, and long-term maintenance because the bundle is AnzuSystems-specific. Mitigate with adapters, config mapping, dependency pinning, centralized TTL settings, and integration tests. If you do not need its specialized features, prefer Laravel-native solutions.
- What are alternatives to anzusystems/common-bundle for Laravel?
- Use Laravel-native packages for common needs, such as spatie/laravel-permission for permissions, spatie/laravel-health for health checks, Laravel Cache locks for concurrency, and standard Laravel logging or MongoDB packages. If you need the bundle's exact MongoDB journal, audit logging, or multi-language permission behavior, consider a forked Laravel-compatible adapter. Compare maintenance cost against building only the missing feature.
Weaver
How can I help you explore Laravel packages today?