Codeigniter4 Eloquent Laravel Package

Product Decisions This Supports

• Hybrid stack feasibility (CI4 + Eloquent): Informs the decision to keep an existing CodeIgniter 4 app while adopting Laravel's Eloquent ORM for models, relationships, and query building — instead of rewriting the app or hand-rolling a data layer.
• Incremental CodeIgniter → Laravel migration: If a full framework migration is on the roadmap, adopting Eloquent inside CI4 now de-risks and shrinks the eventual big-bang cutover. This package is the enablement lever for that strategy.
• Build vs. buy for the data layer: Replaces bespoke repositories/query abstractions with a maintained bridge, trading some control for faster delivery and Laravel-idiomatic DX.
• v2.0.1 — model lifecycle hooks are now usable: Event dispatcher + Laravel facade activation means Eloquent model events and observers (creating, created, saving, deleted, etc.) work. This unlocks audit logging, derived-field population, notification triggers, and cache invalidation without custom plumbing — a real feature unlock for domain logic.
• v2.0.1 — Microsoft SQL Server support: SQLSRV driver registration broadens database targets, which matters for enterprise/Windows-centric or .NET-adjacent environments. Can affect hosting decisions and procurement constraints.
• Use cases to validate against: teams with sunk CI4 investment, mixed Laravel/CI4 skill sets, multi-tenant apps needing soft deletes and relationships, and internal tooling where Laravel-style ergonomics shorten onboarding.

When to Consider This Package

Adopt when:

• You have a production CodeIgniter 4 application and want Eloquent models, relationships, eager loading, and soft deletes without rewriting.
• You need model events/observers (now viable in v2.0.1) for cross-cutting behavior like auditing or notifications.
• You are planning or actively executing a gradual CodeIgniter → Laravel migration and want shared data-layer semantics.
• You target SQL Server, MySQL, or Postgres and want a single ORM abstraction.
• Your team's dominant muscle memory is Laravel and you want to minimize context switching.

Look elsewhere when:

• You are greenfield — start on Laravel directly rather than paying integration tax for parity you can get natively.
• You need the full Laravel ecosystem (queues, broadcasting, service container parity, first-party packages); this bridge is partial and will create seams.
• You depend heavily on CI4's own Model/Query Builder semantics and would be running two data-access paradigms side by side.
• You require strong support guarantees — this is community-maintained with concentrated maintainer risk, and v2.x minor releases have shipped framework-glue changes (facade/event wiring, driver registration) that touch integration surfaces.
• You are on a strict upgrade cadence and cannot absorb the testing burden of validating a third-party ORM bridge against each CI4 and Laravel/Eloquent release.

How to Pitch It (Stakeholders)

For executives: This is a small, community-maintained bridge that lets our CodeIgniter 4 application use Laravel's Eloquent ORM. v2.0.1 adds two things that matter: model event hooks (so business logic like audit trails and notifications can attach to data changes cleanly) and Microsoft SQL Server support (expanding our database options). Strategic value is optionality — it keeps a future CodeIgniter → Laravel migration cheap and incremental rather than a rewrite.

For engineering: v2.0.1 wires up the Laravel event dispatcher and facade, making observers and model events first-class, and registers the SQLSRV driver. Both are additive, non-breaking on the surface — but they expand the integration surface between two frameworks. Recommendation: run a time-boxed spike, pin exact versions, isolate Eloquent usage behind repository interfaces so it can be swapped, and cover model events and SQLSRV paths with integration tests before committing. Treat this as a velocity and migration-de-risking play, not a core-platform dependency without a fallback.