10: Tooling & CLI

Phlo apps have a CLI layer for build, lint, release and reflection. Always use it through the app's dev entrypoint.

10.1: Build commands

php www/app.php build::run
php www/app.php build::lint
php www/app.php build::release
php www/app.php build::config
php www/app.php build::changed

build::lint should return an empty array:

[]

If lint reports errors, fix the .phlo source and build again. Never patch the generated PHP.

10.2: Reflect commands

Reflection helps you understand an app before you change it:

php www/app.php reflect::context
php www/app.php reflect::compactRoutes
php www/app.php reflect::compactViews
php www/app.php reflect::resourceSummary
php www/app.php reflect::objectIndex
php www/app.php reflect::functionIndex

These commands return JSON and are intended for development environments with build: true.

The same introspection drives the Graph view of the Phlo Control Center: every class, resource and dependency edge of your app, rendered live from reflect::graph:

Full reference:

10.3: General CLI dispatch

build:: and reflect:: are just two examples of a more general mechanism. Phlo's CLI can call any static, method or function in your app:

php www/app.php tasks::run                   # static method on a class
php www/app.php app.heartbeat                # method on a Phlo instance
php www/app.php answer "is an eel a fish"   # global function

Three patterns:

Output goes to stdout as JSON, errors go to stderr with a non-zero exit code. That makes every routine in your app directly usable from cron, deploy scripts, monitoring or a terminal, without building a separate CLI layer for it.

phlo_eval: run Phlo against the live app

The most powerful function dispatch is phlo_eval, which transpiles a string of Phlo and runs it in the live app. It is the runtime complement to reflect::: reflection reads the static source, phlo_eval executes against real data, resources and views.

php www/app.php phlo_eval "user::recordCount()"          # 38, no return keyword
php www/app.php phlo_eval "%app->title"                  # "App"
php www/app.php phlo_eval "echo %app->error('boom')"     # raw HTML, not JSON

A single line auto-returns like a => arrow body, so you write just the expression, no return (unless it starts with return/apply/echo/unset/yield); only a multiline block needs its own return. return prints the value as JSON (type-safe, non-scalar, errors as {"error": ...}); echo prints raw to stdout, handy for viewing rendered markup as-is.

phlo_eval runs arbitrary code with full app privileges: it can read secrets and mutate the database. It is CLI-only and build-only, never present in release/production. Treat its input as developer-authored only, never untrusted.

Only available with build: true in www/app.php. Do not run against a live production environment.

10.4: Debug helpers

With debug: true in phlo_app(...), Phlo activates a set of helpers for inspection during dev. In production they are inert.

The lifecycle: helpers collect during the request (%res->dump, %res->debug); at the end of a sync page an inline script logs everything to the browser console together with memory, duration and trace metadata, and async responses carry the same data in their apply payload. Objects are unwrapped via objInfo(). Runtime errors accumulate in data/errors.json (message, source-mapped file and line, count, last occurrence); read them with reflect::errors or in the Phlo Control Center.

method buildReport {
	$data = $this->load
	debug('loaded', count: count($data))
	if (!$data) error('No data to report')
	dx($data[0])
}

dx() is your primary "stop and look at what's there" tool during development. Forgot a dx() in code that ships to release? In debug: false mode it behaves just like error(), no silent passthrough.

10.5: Workflow

In a dev environment the Phlo Control Center (at /phlo) puts this whole loop in the browser: source, build, release and errors, with every file one click away:

1. Read the source and the reflection output first.
2. Only modify .phlo, data/app.json or entrypoints.
3. Run build::run.
4. Run build::lint.
5. Test the relevant HTTP routes.
6. Run build::release when the stage/release output needs updating.

10.6: Dev, stage and production

Dev typically has:

auth: true,
build: true,
debug: true,

In build+debug mode, the built-in control UI lives at /phlo by default; use control: 'path' in phlo_app(...) to pick a different path. Stage/production typically runs without build and without debug. The webroot points to release/www/.

10.7: HEAD and async

The current runtime supports the normal HTTP methods, including HEAD. Async requests are handled by the frontend resource and use the same routes as sync requests, unless you explicitly declare a route otherwise.