- Is localfr/uberall-bundle a Laravel package?
- No. It is a Symfony bundle that registers Uberall API configuration and services through Symfony's DependencyInjection extension and services.yaml, which Laravel's container does not discover or compile. Treat it as reference material or an extraction source, not a drop-in Laravel dependency.
- How do I install localfr/uberall-bundle?
- In a Symfony application you would install it with Composer and enable the bundle in your Symfony bundle registration, then provide API credentials through bundle configuration. There is no Laravel artisan install command or auto-discovered service provider. For Laravel, plan an adapter or a rebuild rather than a direct require.
- Does localfr/uberall-bundle support Laravel 10 or 11?
- It is not built for Laravel's container or configuration system, so Laravel 10 and 11 are not natively supported. The bundle relies on Symfony bundle compilation, dependency injection extensions, and services.yaml. Using it in Laravel would require wrapping or extracting the client code, which changes the effort estimate.
- What Uberall API endpoints does the bundle cover?
- The provided context does not enumerate endpoints, so do not assume full coverage of locations, listings, reviews, insights, or directories. A short spike should read services.yaml and the DependencyInjection extension to inventory wrapped calls and payloads. Anything not wrapped becomes your responsibility.
- How are Uberall API credentials configured in this bundle?
- Credentials are expected through Symfony bundle configuration rather than Laravel's config/services.php and .env pattern. The spike should confirm whether Uberall uses an API key, private key, or both, and whether scoping is per account or per location. In Laravel you would move these values into config/services.php under a uberall key.
- Can I use localfr/uberall-bundle with Laravel's service container?
- Not directly, because Symfony bundle service definitions and extensions are not compiled by Laravel. The recommended path is a thin UberallClient over Laravel's Http facade bound as a singleton in an UberallServiceProvider. Only extract framework-agnostic service classes if the bundle encodes non-obvious payload mapping or directory-specific quirks.
- Does the bundle handle pagination, retries, and 429 rate limits?
- There is no visible evidence that pagination, retry and backoff, or 429 handling are implemented, so assume they are deferred to the caller. Laravel's Http client gives you retry and backoff primitives, but you must still design idempotency keys and dead-letter handling for writes. Validate this early in the spike.
- Is localfr/uberall-bundle actively maintained and tested?
- The signals are weak: one star, zero dependents, a single maintainer, and a 2025-01-22 release but no visible CI matrix or security disclosure path. Bus factor is one, so treat it as sample code published under MIT. The spike should check whether any tests exist and whether the Uberall client is mocked.
- What are Laravel-friendly alternatives to this Symfony bundle?
- Build a small UberallClient or typed clients per resource using Laravel's Http facade, configured from config/services.php and .env, with writes behind queued jobs. This preserves config caching, Http::fake testability, and Octane safety. Avoid booting a Symfony container inside Laravel, which adds framework-bundle weight and a permanent upgrade tax.
- What production concerns should I check before adopting it?
- Check Symfony dependency constraints, especially whether symfony/framework-bundle is hard-required and at which major version. Confirm credential scoping, observability, and whether service classes are container-agnostic or rely on ContainerAwareInterface. For Laravel, implement config caching, Http::fake tests, queued writes with idempotency, and a feature flag with shadow-run parity.