CLI · Winter Console

The mapping command

mapping shows the routes the application actually exposes: the verbs, the paths and the handlers. There is no need to bring the server up for it — the command scans the project itself.

Subcommand showServer not required

What mapping is and why

mapping is the route-table viewer.

The problem. Routes in Winter are not listed in one file: they are scattered across controllers as attributes, and the final path is the sum of the class prefix, the plugin prefix and the method’s path. Answering “what exactly serves /api/v1/orders” from the code means adding that sum up in your head across several files.

The solution. The command builds the table the same way the application does at startup and shows you the finished result.

Usage

bash
php call mapping             # every route
php call mapping show        # the same thing
php call mapping show api/user   # only paths containing api/user
text
 |   GET     /api/posts              → MainPostController::index
|   POST    /api/posts              → MainPostController::create
|   GET     /api/posts/{id:d+}     → MainPostController::get
|   PUT     /api/posts/{id:d+}     → MainPostController::update
|   DELETE  /api/posts/{id:d+}     → MainPostController::delete

The argument is a path fragment; leading and trailing slashes are dropped and the match is a substring one. The routes are sorted by path, so every method of one resource stands together.

What it is good for

Checking a new endpoint. You wrote a controller — one command confirms that it registered and that the path came out as intended.

Finding the cause of a 404. If the route is not in the output, the controller did not make it into the scan. That is usually one of three things: the file sits in resources/ or storage/ (those directories are excluded), the class is declared abstract, or the method is not public.

Spotting a conflict. A duplicate verb-and-path pair takes the application down at startup, and the command shows the same error — without starting the server.

Seeing what the plugins added. Their routes arrive with their own prefix and are visible in the common table alongside yours.

There is no route cache

The table is rebuilt on every invocation — and equally on every application start. There is no separate routes file, so the output has nowhere to go stale and there is nothing to “rebuild” before a deploy.

What can speed up startup is di build: it prepares the list of the project’s classes, which both the container and the route scanner use.

Next