Illuminate Laravel Package

Technical Evaluation

What the package actually is. yii2tech/illuminate is a Yii2 extension (not a code converter) that bootstraps a Laravel Illuminate\Container alongside a running Yii2 application. It gives Yii2 code access to Illuminate services — container resolution, database/Eloquent, support helpers, and related primitives — while Yii2 continues to own routing, sessions, identity, and the existing ActiveRecord layer. It is a coexistence shim, not an automated migration tool. Any roadmap framing that treats it as "the thing that migrates us to Laravel" is wrong and should be corrected before it reaches a steering committee.

Architecture fit. Fit is narrow and conditional. It is appropriate only for a brownfield Yii2 monolith where a full rewrite is unaffordable and the organisation wants a strangler-fig transition, adopting Laravel idioms incrementally inside the existing runtime. It is a poor fit for greenfield work, for services already behind an API boundary, and for teams that intend to reach Laravel as a final state quickly — in those cases a service extraction or parallel-run is cheaper than carrying two DI containers and two ORMs. The honest strategic read: this package buys incremental adoption of Laravel's data layer, not migration of the application framework.

Integration feasibility. Mechanically straightforward — Composer install, register a Yii2 application component, point the Illuminate database manager at the existing connection, and start writing Eloquent models next to ActiveRecord models. The friction is at the seams, not the wiring:

• Dual container / dual service locator. Two resolution roots in one process creates ambiguity about where a dependency lives. This must be resolved by convention and enforced in review, or the codebase bifurcates informally.
• Transaction and connection semantics. Yii2 beginTransaction() and Illuminate's transaction manager are separate. Read-your-writes inconsistencies and partially-rolled-back state are plausible and hard to reproduce.
• Identity, session, and CSRF. Yii2's user component and Laravel's auth guards do not interoperate. Any feature requiring Laravel-style auth needs bespoke glue.
• Events. Two dispatchers; cross-framework listeners need explicit bridging.

Technical risk (ranked).

1. Vitality and bus factor. 115 stars with a composite score of ~1.2 is a weak ecosystem signal — small installed base, few independent bug reports, effectively a single-maintainer project. Assume no upstream responsiveness.
2. Version ceiling. The binding constraint is almost certainly the illuminate/* constraint range and the PHP version it permits. This is the single question that can kill the initiative, and it should be answered in an afternoon, not a sprint.
3. Framework lifecycle. Yii2 is in maintenance mode; Laravel moves fast and drops PHP versions aggressively. Sitting between them means inheriting Laravel's security advisories without inheriting its supported upgrade path.
4. Licensing. NOASSERTION means GitHub could not identify the licence. yii2tech packages are typically BSD-3-Clause, which would be permissive, but this must be confirmed from the LICENSE file by legal before any use — it is a gating item, not a formality.
5. Vendor abandonment. If the repo is archived or dormant (common for this author's packages), you own it. Mitigation is cheap here because the surface is small — budget a fork-and-vendor rather than assuming upstream support.

Key questions to resolve before commitment.

• Which illuminate/* and PHP versions does the constraint set actually permit — and does that align with the Laravel version the target architecture assumes?
• What exactly is bootstrapped: a partial Capsule-style container or a full application container? What is not available?
• Is there a maintained fork, or active recent commit activity, or is this frozen?
• What is the confirmed licence, in writing?
• Does the team have anyone who has run Yii2 and Laravel in production? If not, the bus factor problem is internal as well as external.
• What is the removal cost — how many call sites would need to change to eliminate the bridge, and is that number small enough to be a rounding error in the migration budget?

Integration Approach

Stack fit and the alternatives. The TPM's job is to position this against the alternatives rather than evaluate it in isolation.

The bridge is defensible when the organisation has a large Yii2 estate, a hard deadline for modernising the data layer, and no appetite for a rewrite — and when leadership accepts that this is scaffolding with a scheduled demolition date. Without that explicit acceptance, it becomes permanent debt by default.

Migration path (recommended shape).

1. Gating week. Licence confirmation, version-constraint audit, two-day spike: bootstrap the container, bind the existing DB, write one Eloquent read model against a real table, exercise a transaction.
2. Contained pilot. Choose a bounded, read-heavy, low-blast-radius context — reporting, an internal admin surface, an integration consumer. Do not start with auth, billing, or anything transactional multi-table.
3. Convention before volume. Publish a one-page rulebook: which container owns what, where Eloquent is permitted, how transactions are scoped, how models are named to avoid collision with ActiveRecord classes. This document is the actual deliverable of the pilot.
4. Fork and vendor. Take a pinned fork under your own namespace with CI, so upstream dormancy is a non-event. Small surface → low cost.
5. Widen or pivot. If the pilot lands cleanly, expand per-context. If transaction semantics or container ambiguity bite in the pilot, that is the signal to pivot to service extraction — cheaply, having spent weeks rather than quarters.
6. Exit plan on the roadmap from day one. Each adopted context carries a defined endpoint: extracted to a Laravel service, or rewritten in place during a Laravel-side cutover.

Compatibility work. Pin exact versions of illuminate/*, Yii2, and PHP minor; verify no Composer conflict with other yii2tech packages already in the tree; confirm the bootstrap does not collide with existing Yii2 DI container definitions or bootstrap-time configuration. Add dependency-upgrade CI early — the value of the bridge is that it lets you defer Laravel upgrades, and the risk is that you forget you deferred them.

Sequencing note. Do not sequence this in parallel with a Yii2 major upgrade or a PHP version bump. The package sits precisely on the version boundaries those projects move, and concurrent change makes attribution of failures impossible.

Operational Impact

Maintenance. Treat as internal code from day one. Ongoing cost is modest in code terms — the bridge is thin — but non-trivial in dependency terms: you inherit Laravel security advisories for whichever illuminate/* versions you pin, while being off Laravel's supported upgrade treadmill. Budget a recurring quarterly review: advisory scan, patch decision, compatibility retest. Assign a named owner; unowned bridges rot silently.

Support. No vendor, no SLA, community issues only. Realistic support model is an internal SME plus the fork. Mitigate by keeping the bridge's footprint small enough that a competent Yii2/Laravel engineer can read the whole thing in an afternoon — that is the actual resilience property, not any support contract.

Scaling. Eloquent performs; the bridge is not the bottleneck. The scaling concerns are structural:

• Memory and bootstrap. Two containers in one process raises baseline memory; matters for PHP-FPM worker density and matters more for long-running queue workers.
• Duplicate model definitions. Two ORMs over one schema means two sources of truth for the same table. Schema drift between the ActiveRecord and Eloquent views of a table is the most likely medium-term defect class.
• Worker state. Long-lived consumers with dual containers need explicit testing for state leakage between jobs.

Failure modes to instrument for.

• Transaction visibility mismatches between Yii2 and Illuminate (silent partial commits; the worst kind).
• Container drift — code resolving from the "wrong" container and behaving differently across request types (web vs console vs queue).
• Event dispatch duplication or silent loss across the two dispatchers.
• Version skew: a PHP or Laravel security patch arrives and the pinned constraint blocks the upgrade, forcing an emergency fork patch.
• Bus-factor event: the one engineer who understands the bridge leaves.

Ramp-up. The required profile — comfortable in both Yii2 and Laravel — is uncommon and expensive. Onboarding cost is real and should be priced into the business case. Documentation is thin upstream, so the pilot's convention doc and a short "how the two containers relate" primer are mandatory artefacts, not nice-to-haves. Estimate one to two weeks for a mid-level engineer to be productive in the bridged area, versus days for either framework alone.

TPM recommendation. Leverage it as a time-boxed accelerant with a pre-agreed demolition clause, gated on licence confirmation and a successful version-constraint spike. Do not adopt it as permanent architecture, do not let it become the default answer to "how do we modernise," and do not start it without naming the owner, the exit criterion, and the date at which the exit is reviewed.