Codeigniter4 Eloquent Laravel Package

Technical Evaluation

Architecture fit

• This package is a bridge that embeds Laravel's Eloquent ORM (illuminate/database) into CodeIgniter 4 rather than a native Laravel package. Fit is strong only if we maintain CI4 applications and want Laravel-style models; for a Laravel-standardized estate it duplicates capability we already have and introduces a second ORM idiom.
• v2.0.1 materially improves architectural fit: the event dispatcher brings model events/observers into play, which is the missing piece for teams relying on Eloquent lifecycle hooks (auditing, soft deletes, cache invalidation). Facade activation aligns bootstrapping with Laravel conventions and reduces custom service-wiring code.
• SQLSRV driver registration extends the package into Microsoft SQL Server shops, which is a meaningful expansion of addressable environments.

Integration feasibility

• Low-friction install path (Composer + service registration), and v2.0.1 reduces boilerplate by shipping facade wiring and event dispatch out of the box.
• Feasible for teams already fluent in Eloquent; the main effort is bootstrap/container alignment between CI4's service layer and Laravel's container assumptions.

Technical risk

• Versioning semantics risk (primary): event dispatcher and facade activation are behavioral/feature changes shipped in a patch release. Consumers pinned to ^2.0 receive them implicitly. Facade activation can register global aliases and container bindings that collide with CI4 helpers or existing class_alias usage.
• Event duplication risk: enabling a dispatcher may cause observers/listeners to fire where they previously did not, or fire twice if the host app already wired its own dispatcher.
• SQLSRV dependency risk: driver registration presumes pdo_sqlsrv / msodbcsql availability in runtime images; registration succeeding does not guarantee connectivity.
• Bus factor: single-primary-maintainer community project; patch releases carrying feature content suggest limited release-gating.

Key questions

1. What illuminate/* version ranges does 2.0.1 constrain, and does that conflict with any Laravel services we share components with?
2. Does facade activation register global aliases unconditionally, and can it be disabled via config?
3. Is the event dispatcher opt-in, and how are listener/observer registrations scoped to avoid double dispatch on upgrade from 2.0.0?
4. Is SQLSRV registration conditional on the extension being present, or does it fail hard at boot?
5. What is the supported CI4 and PHP version matrix, and is there CI coverage for the new driver path?
6. Is there a documented deprecation/support policy for the 2.x line?

Integration Approach

Stack fit

• Targets CI4 applications on modern PHP with illuminate/database and illuminate/support. The new facade support makes it a closer drop-in for developers porting Laravel patterns; SQLSRV support opens it to enterprise SQL Server environments that were previously excluded.

Migration path

• 2.0.0 → 2.0.1 is nominally a patch, so the practical migration is: bump, run the full suite, and specifically diff behavior around model events and container/facade resolution. Treat it as a minor for test purposes.
• If SQL Server is not in scope, no action beyond regression testing; the driver registration is inert.

Compatibility

• Validate illuminate/* constraints against any shared Laravel packages in the monorepo. Confirm no global alias collisions from facade activation with CI4's own helpers. Confirm pdo_sqlsrv presence in every target image (local, CI, staging, prod) before enabling that path.

Sequencing

1. Spike in a non-production branch: install 2.0.1, enable facade, assert boot succeeds and no alias warnings.
2. Enable the event dispatcher and add assertions that observers fire exactly once for create/update/delete.
3. Only then introduce SQLSRV in a single environment; verify connectivity and transaction behavior end-to-end.
4. Roll to production behind a version pin, with a rollback to 2.0.0 documented.

Operational Impact

Maintenance

• Ongoing cost is low in code volume but non-trivial in stewardship: a community package with thin release discipline means we should pin exact versions and review each bump rather than float ^2.0. Assign an internal owner for the Eloquent bridge layer.

Support

• No vendor SLA. Escalation path is upstream issues/PRs. Budget internal capacity to patch or fork if a blocking defect lands, particularly around the new dispatcher/facade wiring.

Scaling

• Eloquent's hydration overhead is real versus raw query builder for high-volume read paths; keep hot paths on CI4's builder or raw queries. For SQLSRV, confirm connection pooling and driver-level timeouts behave under load.

Failure modes

• Boot-time failure from facade/alias registration conflicts (loud, easy to catch).
• Silent non-dispatch of model events after upgrade — observers/audit logs quietly stop firing. This is the highest-severity mode; needs explicit monitoring.
• Duplicate event dispatch causing double-written audit rows or duplicate side effects.
• SQLSRV driver registered but extension absent or misconfigured → connection errors at first query rather than at boot.
• Version skew between bundled illuminate/* and shared Laravel components causing subtle runtime errors.

Ramp-up

• Laravel-experienced engineers are productive in days; CI4-only engineers need onboarding on Eloquent conventions, the container, and event lifecycle — realistically one to two sprints to competence. Document the bridge's bootstrap order and the event-dispatcher contract as part of rollout.