CodeIgniter 4 joins the roadmap: password, hash, sessions, MySQL, and an opensourcepos POC

Pext now tracks a second framework. CodeIgniter 4 has been added as a side roadmap running in parallel with Laravel, on the roadmap page. The motivation is partly diversification (CI4's dependency footprint is famously smaller, and its testing stack stresses a different mix of language features), and partly to give Pext an end-to-end target it can boot and click through, not just a unit-test pass rate.

Why CodeIgniter 4 as a side roadmap

The Laravel roadmap remains the headline target. It is the largest and the noisiest, and clearing its dependency tree is the only way to validate Pext against the biggest single chunk of PHP in the wild. CodeIgniter 4 is the side roadmap for three reasons.

First, CI4's runtime dependency footprint is tiny. The production require is essentially laminas/laminas-escaper, psr/log, and the extensions. That makes it a cleaner conversion target for the framework itself, with less dependency surface to clear first. Second, the testing and static-analysis stack on the dev side is heavy and overlaps with Laravel's: PHPUnit, sebastian/*, PHPStan, Rector. Work that lands for one roadmap usually lands for the other. Third, the framework's request lifecycle is meaningfully different (no service container the same way Laravel uses one, a different config and autoload story, a different MVC shape). Hitting both shapes is the way to make sure Pext is not accidentally Laravel-specific.

The new roadmap is live on the roadmap page behind the framework selector at the top. Switch between Laravel and CodeIgniter 4 to see the per-framework phase plan and the current state of each package.

New runtime: password, hash, sessions, MySQL

Four runtime areas landed this week to support CI4 boot. password_hash, password_verify, and the option-array forms behind them, mapped onto a JS-native implementation that returns the same hash format PHP produces. hash, hash_hmac, hash_equals, and friends, covering the algorithm surface that CI4's encryption and session signing rely on. The sessions module: session_start, session_id, session_regenerate_id, session_destroy, the $_SESSION superglobal, and a pluggable handler interface so CI4's session handlers (file, database, redis, memcached at the framework level) can register against it.

The MySQL client is the largest new piece. It implements the mysqli and PDO surfaces that CI4 uses, wired against a connection-pooled JS driver. Prepared statements work, parameter binding works, transactions work, the row-fetching shapes that CI4's query builder expects all return what they should. There are still rough edges (some of the exotic charset and timezone handling has not been exercised yet), but the common path is in.

Bringing the framework up

The first thing a framework conversion needs is the framework's own bootstrap to run without dying. For CI4 that meant the autoloader, the CLI entry point (spark), the configuration loader, and the command discovery process. None of these touch the database or the request handler; they are the cold path before anything else can happen.

The autoloader was straightforward once the PSR-4 resolver in the transpiler agreed with CI4's path conventions for the App\\ namespace and the framework's own CodeIgniter\\ namespace under system/. The configuration loader exercised PHP's array-merge semantics in a couple of corners that had not been tested before. The CLI surface (spark list, spark migrate, spark routes) runs end to end, which means the entire command discovery, the registry of CI4's Commands class, the argument parsing, and the help formatter are all on the converted runtime.

The unit test suite is the next step and will get its own write-up once the numbers are worth printing.

A POC against opensourcepos

opensourcepos is an open-source point-of-sale application built on CodeIgniter 4. It exercises the framework the way a real production application does: routing, controllers, models, sessions, authentication, MySQL, file uploads, view rendering. It was picked as the POC because if Pext can boot it and log in, the conversion has touched every major framework subsystem at least once.

The POC boots. The login page renders. Submitting valid credentials authenticates the session and redirects to the dashboard. Submitting invalid credentials produces the framework's error response. Logging out clears the session and redirects to the login page. That is a small surface and a meaningful one. Getting it to work exercised the full request lifecycle (HTTP entry, router resolution, controller dispatch, response rendering), the database (user lookup, session persistence), the file system (config reads, view templates), the bootstrap (config, services, autoload, env loading), and the auth subsystem (password verification, session signing, CSRF tokens).

The next milestone for opensourcepos is the rest of the application: actually ringing up a sale, recording it in the database, generating a receipt, and clicking through the back-office reports. The login flow proves the runtime is there; the rest of the application proves the integrations are.

What's next

Two threads this coming sprint. On the runtime side, finishing the gaps the POC surfaced (a few mysqli edge cases, a couple of session handler refinements, and the long tail of charset and encoding behaviour). On the conversion side, getting the CI4 PHPUnit suite to run end to end so the pass-rate number can join its Laravel counterpart on the roadmap page.

If your stack is on CodeIgniter 4 and you want to be in early on this work, book a demo.