With Eloquent Laravel Package

Technical Evaluation

Architecture fit

• mod-ci/with-eloquent is a bridge, not a Laravel package: it wires illuminate/database (Eloquent + Capsule-style bootstrapping) into a CodeIgniter application so models, relationships, casts, and soft deletes are available alongside CI's native Query Builder.
• It only has architectural value if the portfolio contains CodeIgniter applications — legacy estates, acquired products, or client work. For a Laravel-first team with no CI footprint, there is no fit.
• The strategic upside is portability: Eloquent models written inside CI are largely lift-and-shift compatible with a future Laravel migration, which makes this a useful exit-ramp tool rather than an end-state architecture.
• The downside is dual-ORM coexistence on a single schema. Two abstractions writing the same tables is a permanent source of convention drift (timestamps, soft deletes, casting, transaction semantics).

Integration feasibility

• Composer-installable, but the hard dependency is illuminate/database, whose major version must be pinned against the app's PHP version. This is the single biggest integration constraint.
• Requires bootstrapping work: a service provider equivalent, a config file, reuse of CI's existing DB connection/credentials, and a shared base model. None of this is Laravel's zero-config experience.
• Support matrix is unclear. CI3 (legacy bootstrap, $this->load) and CI4 (namespaced, PSR-4, different autoload path) are materially different targets; assume CI3 unless proven otherwise and validate first.
• The supplied metadata is unreliable for this specific package: the repository URL and 18,151 stars point at the CodeIgniter core framework, not this module. Dependents = 0 and opportunity = 27.23 indicate effectively no external validation. Treat the package as unvetted third-party code until an internal code review is done.

Technical risk

• Maintenance/abandonment (high): single-maintainer, near-zero adoption. Assume no upstream fixes and plan to vendor or fork on day one.
• Security patching gap (medium-high): Eloquent CVEs arrive via illuminate/database; if the bridge pins an old major, the app inherits known vulnerabilities with no supported upgrade path until the bridge is patched internally.
• Correctness risk (high): mixed ORM usage invites inconsistent transaction handling, nested transaction behavior, connection state, charset/collation mismatches, and divergent timestamp/soft-delete conventions on shared tables.
• Tooling gap (medium): no Artisan. Schema migrations, seeders, and model generation must be handled by CI tooling or hand-rolled — Eloquent's migration story does not come along for free.
• Signal risk (medium): with inflated/mismatched popularity metadata, procurement and engineering cannot use stars as a proxy for quality.

Key questions

1. Which CI versions are actually supported — 3.x only, or 4.x?
2. What is the illuminate/database version ceiling, and does it accept a currently supported PHP/Laravel LTS major?
3. Is there a test suite, and what is its coverage of connection sharing and transactions?
4. How are transactions handled when both Query Builder and Eloquent touch the same request? Is the connection genuinely shared?
5. Who owns the fork internally, and what is the patching SLA?
6. What is the schema-change process in the absence of Artisan migrations?
7. Is there a concrete CI application in the estate that justifies adoption, or is this speculative?

Integration Approach

Stack fit

• Target profile: PHP 7.4–8.x, Composer, CodeIgniter 3.x, MySQL/PostgreSQL. Fits teams that are Laravel-fluent but must operate a CI app.
• Does not fit CI4 natively (CI4's Model layer already covers most needs with less risk), and is irrelevant to pure Laravel services.

Migration path

• Tactical (recommended if adopted): use Eloquent for new modules only, leaving legacy Query Builder code untouched. This contains blast radius and delivers the portability benefit without a rewrite.
• Strategic: Eloquent models act as the seam for an eventual move to Laravel — same models, same relationships, same casts, new framework shell. This is the main justification for the package.
• Do not attempt a wholesale Query Builder → Eloquent rewrite of a working CI app; the conversion cost is high and the value is deferred.

Compatibility gates

• Pin illuminate/database to a Laravel LTS-supported major; verify against the security advisory feed before approval.
• Validate PSR-4 autoloading coexists with CI's loader without class collisions.
• Confirm the bridge reuses CI's DB config rather than introducing a second connection pool.

Sequencing

1. Week 1–2 — Feasibility spike (time-boxed): sandbox branch, bootstrap the bridge, prove connection sharing, one transaction rollback, one relationship eager-load, one soft-delete case. Kill criteria defined up front.
2. Week 3 — Code review & fork decision: internal review of the bridge's bootstrapping and connection handling; decide vendor-in-repo vs. fork-and-publish-internal.
3. Week 4–5 — Reference module: ship one production module on Eloquent behind an internal base-model convention (timestamps, table naming, connection, transaction helper).
4. Week 6+ — Incremental rollout: module by module; no big-bang. Establish a rule that a given table has exactly one ORM owner.
5. Parallel track: document the exit path to Laravel/CI4 so the bridge is explicitly framed as transitional.

Operational Impact

Maintenance

• Budget ~0.1–0.2 FTE for the fork plus dependency currency. This is not a "set and forget" dependency; it is internal infrastructure with a third-party origin.
• Every illuminate/database security release becomes an internal patch task. Without a named owner, the fork will silently rot.

Support

• No vendor, no community, effectively no upstream responsiveness. Escalation path is internal engineering only.
• Requires a written runbook: bootstrap steps, base-model conventions, "which ORM owns which table," and the transaction helper contract.

Scaling

• Eloquent's hydration and relationship overhead is higher than CI's Query Builder; acceptable for CRUD-heavy apps, measurable on high-volume read paths.
• Lazy loading is the primary performance hazard — enforce explicit with() eager loading via code review or a lint rule.
• Connection handling is the scaling unknown: confirm the bridge does not open a second connection per request under load before committing to production.

Failure modes

• Silent schema/convention divergence between the two ORMs writing the same table (worst case: data corruption via mismatched timestamps or soft deletes).
• Transaction leakage when Query Builder and Eloquent assume different connection state.
• Upstream abandonment mid-project, leaving a pinned, unpatched DB layer.
• Version-drift breakage on a PHP or illuminate/database upgrade with no maintainer to fix it.
• Bootstrap breakage after a CI framework patch (hooks, loader, autoload order).

Ramp-up

• Laravel-trained developers: ~1–2 days, mostly learning CI's bootstrap and loader quirks.
• CI-native developers: ~1–2 weeks for Eloquent models, relationships, and — critically — the absence of Artisan migrations.
• Add onboarding cost for the internal base-model conventions and the dual-ORM ownership map.

TPM recommendation

• Conditional go, time-boxed. Adopt only if there is at least one owned CodeIgniter application with an identified future Laravel migration. Otherwise no-go — the opportunity score (27.23) and zero dependents correctly signal low strategic value.
• If approved: fork on day one, pin to a supported illuminate/database major, enforce single-ORM table ownership, and treat the bridge as a documented, sun-setting migration seam rather than a permanent layer.