Weave Code
Eip Bundle Laravel Package
enabel/eip-bundle
The Enabel EIP Bundle provides a basic integration of EIP in Symfony 6.4+ projects. Install it with Composer, then configure EIP_BASE_URI and EIP_TOKEN in your .env.local file to connect. The project follows SemVer and is released under the MIT license. Created by Enabel.
At a glance
Frequently asked questions about Eip Bundle
- Does enabel/eip-bundle work with Laravel out of the box?
- No. Despite often being listed alongside Laravel packages, enabel/eip-bundle is a Symfony bundle and its README explicitly targets Symfony 6.4+. It ships no Laravel service provider, no publishable config/eip.php file, and no facade, so composer require alone will not give you a working integration. On Laravel you should treat adoption as an adapter project rather than an install. The bundle's realistic value on Laravel is as a reference implementation of the EIP request shapes.
- How do I install and configure enabel/eip-bundle?
- Run composer require enabel/eip-bundle, then add EIP_BASE_URI and EIP_TOKEN to your .env.local file. Those two environment variables plus Symfony container autowiring are the entire documented surface of the bundle. There is no other published configuration step in the README, so any further wiring has to be read from the source.
- Which Symfony and Laravel versions does enabel/eip-bundle support?
- The README states the current version works with Symfony 6.4+ and that the project follows SemVer. It says nothing about Laravel, which is the deciding factor: Symfony 6.4+ admits Symfony 7 components, so it may coexist with Laravel 11 or 12, but a ~6.4 style constraint would hard-conflict. Check the actual composer.json constraint before committing, because ^6.4 and ~6.4 produce very different outcomes.
- How do I use enabel/eip-bundle in a Laravel 10, 11 or 12 application?
- The recommended pattern is a thin adapter: install the bundle only to obtain its client and transport classes, bind them into Laravel's container from a ServiceProvider, and never boot the bundle's Symfony DI extension. Map config('services.eip.*') onto the EIP_BASE_URI and EIP_TOKEN values so configuration stays Laravel-idiomatic. This is feasible but it is glue code you own indefinitely, including every upstream breaking change to the client's constructor signature. If the client is tightly coupled to Symfony DI or the constraints conflict, reimplementing a small HTTP client against the EIP contract is cheaper to own long term.
- Is EIP a public API, or do I need separate access and credentials?
- The bundle is a thin client wrapper, not the service itself. If EIP is an Enabel-operated or internal API, you must independently have credentials and an agreement to use it before this package does anything useful. Confirm service availability, access terms and any SLA first, because without them the bundle is inert regardless of code quality. The architectural decision that matters is whether you depend on the EIP service, not whether you depend on this bundle.
- How does authentication work, and can the EIP token be rotated?
- Authentication is a single static bearer token supplied through the EIP_TOKEN environment variable. The README documents no rotation mechanism, no scoping or per-tenant credentials, and no refresh flow. That is a secrets-management and blast-radius concern at any real scale, so plan your own rotation process around the token. Review the source to see exactly how the token is attached to requests before you design that process.
- Is enabel/eip-bundle actively maintained and safe for production?
- Adoption signals are essentially zero: no stars, no dependents, two named authors and a single-vendor origin, so there is no external validation that it works outside Enabel's own projects. The project is MIT licensed and follows SemVer, and the contributing section invites pull requests to add features and tests, which suggests tests exist but are not advertised. There is no published CI or coverage badge. Ask who the accountable owner at Enabel is if you hit a defect, and pin your Composer constraint accordingly.
- Does enabel/eip-bundle handle timeouts, retries, pagination and API errors?
- The README is silent on all of these: no timeouts, retries, idempotency guidance, pagination model, exception contract or API version negotiation are documented. Failure semantics are therefore unknown until you review the source. For a production integration you should assume you may need to configure the underlying HTTP client yourself. Verify which HTTP layer the bundle wraps before you plan for mockability.
- Will enabel/eip-bundle conflict with the Symfony components already in my Laravel app?
- Possibly, and it is worth a ten-minute composer audit before any deeper evaluation. The Symfony 6.4+ statement is ambiguous: a caret constraint like ^6.4 admits Symfony 7 and will likely co-install with Laravel 11 or 12's Symfony 7 components, while a tilde constraint like ~6.4 will hard-conflict. Run composer require with --dry-run or inspect the package's composer.json directly. This single check should gate the whole adoption decision.
- What alternatives exist if enabel/eip-bundle does not fit my stack?
- There are three practical paths. On Symfony 6.4+ it is a near drop-in install with two env vars and autowiring, which is the only clean story. On Laravel, write a thin adapter in a ServiceProvider that binds the bundle's client classes without booting the Symfony DI extension. If constraints conflict or the client is inseparable from Symfony DI, skip the package and write roughly 200 lines of Laravel HTTP client against the EIP contract, which is cheaper to own than fighting Composer indefinitely.
Weaver
How can I help you explore Laravel packages today?