Liveigniter Laravel Package

Getting Started

First, correct the scope mismatch. The package name and prior assessments suggest Laravel, but the description is unambiguous: LiveIgniter is a CodeIgniter 4 package that brings Livewire-style reactive components to CI4 apps. You cannot composer require it into a Laravel application. The mental model transfers directly from Livewire; the install target does not. If you're a Laravel dev, treat this as "Livewire concepts, CI4 runtime."

Installation (CI4 app only):

composer require abdullahozcan/liveigniter:0.2.12-alpha

Because the only published version is alpha-tagged, Composer's default minimum-stability: stable will refuse it. You either pin the exact version in require, or set minimum-stability: dev with prefer-stable: true — the latter is the safer of the two, but see Gotchas before you do it.

Where to look first, in order:

1. composer.json — confirm the codeigniter4/framework version range and the PHP floor. This one file tells you whether the package will even install against your target app.
2. The service registrar / Config/ files — CI4 packages register via Config\Autoload::$psr4 and a Config\Services hook. Find what LiveIgniter registers and whether it publishes anything. This is your blast-radius answer.
3. The source tree, not the README. There is no meaningful README, no CHANGELOG, and the sole release note reads "pre-release." The source and any bundled example app are the only documentation.
4. Any examples/ or demo/ directory in the repo — if it exists, this is your fastest path to a working component.

First use case worth spiking: a single counter or toggle button that re-renders server-side without a full page load. It is the smallest possible exercise of the component lifecycle plus the AJAX round-trip, and it will surface whether the installation, routing, and asset/JS-injection wiring actually work in your project. Budget half a day. If it takes more than that, stop — you are debugging a pre-release package, and the cost calculus changes.

Implementation Patterns

Component + view, mirroring Livewire's shape. Expect the canonical pattern: a component class holding public state, a render() method returning a CI4 view, and a view file that binds state via Livewire-style directives. Verify the exact directive names against source before committing to them in code — the description says "Livewire-style" but does not enumerate the API surface, and at 0.2.x the directive names are a moving target.

Keep CI4 controllers, models, and views as the backbone. The package's stated value proposition is that it complements existing CI4 structure rather than replacing it. The right integration pattern is: keep your normal controller/model/view flow for page loads and non-interactive content, and reach for a LiveIgniter component only for the specific isolated interactions that need AJAX. Do not attempt to convert a whole CRUD screen into components in an early spike.

Wrap every call site behind a thin adapter. This is the highest-value pattern in the package's current maturity state:

// app/Components/CounterAdapter.php (your code, not the package's)
final class CounterAdapter
{
    public function render(array $state): string { /* delegates to LiveIgniter */ }
}

Views and controllers call your adapter. When (not if) a patch bump breaks a directive name or lifecycle hook, the fix is one file, not a grep across the codebase. This is the cheapest insurance available and it is worth doing in the same sprint as adoption.

Feature-flag the integration. CI4's Config\Feature or a simple env toggle lets you disable the reactive layer and fall back to a normal form POST without losing data. Combine this with the adapter — the adapter becomes the seam, the feature flag becomes the kill switch.

Pin and branch discipline. Commit composer.lock. Do not co-mingle the LiveIgniter install with other dependency bumps in one PR — a revert must be atomic. When upgrading, diff the source tree between tags; the release notes will not help you.

Gotchas and Tips

• Alpha tag means Dependabot/Renovate will not track it. You are on manual upgrade watch by definition. Assign one engineer as the named owner of that watch before the spike, not after.
• The release notes are unusable. v0.2.12-alpha says only "pre-release" (misspelled). You cannot know what changed from 0.2.11. Treat every release as a fresh integration decision: read the diff, run your adapter tests, re-verify directive names. Budget 2–4 hours per upgrade cycle.
• minimum-stability: dev is a supply-chain hazard. Applying it project-wide to satisfy one package quietly admits any unstable transitive dependency. If you must, scope the constraint to the single package ("abdullahozcan/liveigniter": "0.2.12-alpha" in require) and hold minimum-stability: stable globally.
• Confirm the CI4 version ceiling. CI4 has had breaking changes across majors, and a package at 0.2.x is unlikely to have a CI matrix covering all of them. Run composer why-not abdullahozcan/liveigniter 0.2.12-alpha against your app before committing — the most common pre-1.0 failure mode is an indirect constraint that silently blocks a future framework upgrade.
• Every interaction is a server round-trip. "No JavaScript required" is the selling point, but it is also the performance characteristic. If you put a component on a hot path, benchmark p50/p95 under representative load before it becomes load-bearing. Verify memory behavior under long-running workers if you use them — the package may not be worker-safe.
• Debugging the AJAX layer. When a component re-renders but the DOM doesn't update, the failure is almost always in the JSON payload shape or the front-end binding, not your PHP. Log the raw response from the component endpoint before touching the component class. You will be doing this without documentation; build a small debug view early and keep it.
• No advisory coverage at alpha stability. Security patches arrive, if at all, as unannounced commits. Subscribe to the repository's commit feed — not just releases — because the changelog carries no change information.
• Bus factor is one, and the signal is weak. Two stars, one maintainer, eleven prior patches in this minor line. Do not let this touch anything security-, payments-, or compliance-adjacent. Internal tooling, admin scaffolding, and developer-facing UI are the appropriate blast radius.
• Define your exit criteria now. "Upgrade review stays under X hours per release" and "the adapter seam holds without touching more than one file" are the go/no-go tests. If release notes are still non-descriptive after two more versions, that is the trigger to reassess — a dependency whose changes cannot be read is one whose changes cannot be governed.