README

📖 winterframe.net/docs · Install · Quick start · Key concepts

Every link here points at winterframe.net and is language-neutral — the site serves the page in your language, RU or EN. Both are complete.

The kernel of the Winter framework: the package you install, and the only one you install directly. It turns a directory of classes into a running application — routing, request binding and validation, responses, dependency injection, managed processes and daemons, scheduling, localization, diagnostics and the console.

It is a library, not a skeleton. There is nothing to scaffold and no directory tree to create: you add it to a project, write one class saying what the application contains, and run it.

What is not in it

The database layer and the Redis client are separate packages, installed on demand. The kernel knows just enough about them to find your classes and hand them over when the package is there — an application that talks only to an external API should not carry an ORM, a connection pool and a migration engine it never loads.

Package	What it adds	Docs
`flytachi/winter-ppa`	Repositories, entities, query builder, migrations, DB pool	PPA
`flytachi/winter-redis`	Pooled Redis: prefixed stores, hashes, lists, streams	Redis

See Ecosystem for the full picture, including the libraries the kernel already brings with it (DI, logger, CDO, thread).

Requirements


PHP	8.4+
Required extensions	`pcntl`, `posix`, `fileinfo`
For the HTTP server	`swoole` — coroutines, connection pooling, static files
Optional	`pdo` (database) · `bcmath`, `decimal` (exact numbers) · `simplexml` (XML bodies)

Everything else comes from composer. Details: Installation.

Install

composer require flytachi/winter-kernel

Mini start — two files

bootstrap.php — loads the autoloader and declares what the application contains:

<?php

declare(strict_types=1);

use Flytachi\Winter\Kernel\App\Attribute\EnableWeb;
use Flytachi\Winter\Kernel\WinterApplication;

require __DIR__ . '/vendor/autoload.php';

#[EnableWeb]
final class Application extends WinterApplication
{
    public static function main(array $argv): never
    {
        parent::run($argv);
    }
}

call — the single entry point for everything, the server included (chmod +x call once):

#!/usr/bin/env php
<?php

chdir(__DIR__);
require './bootstrap.php';

Application::main($argv);

chdir() is not decoration: it ties .env, storage/ and resources/ to the project rather than to wherever the command was typed, which is what makes calls from cron, systemd and docker exec predictable.

That is a working project — no .env, no directories. The kernel creates what it needs when it needs it.

php call            # the command list
php call run        # bring the application up
php call run dev    # same, restarting when a .php file changes

Add a controller anywhere under the project; the scan finds it, no registration:

use Flytachi\Winter\Kernel\Http\Stereotype\Controller;
use Flytachi\Winter\Kernel\Route\Annotation\GetMapping;

final class PingController extends Controller
{
    #[GetMapping('/ping')]
    public function ping(): array
    {
        return ['pong' => true];
    }
}

curl http://localhost:8000/ping     # {"pong":true}

Walk-through with a path variable, a query parameter and the JSON it returns: Quick start.

What the application contains — `#[Enable*]`

The attributes on the application class are the manifest. Each adds a component; declare none and boot fails rather than starting an application that does nothing.

Attribute	Effect	Docs
`#[EnableWeb]`	the Swoole HTTP server	Routing
`#[EnableScheduler]`	runs `#[Scheduled]` methods on their triggers	Scheduler
`#[EnableProcess(Foo::class)]`	a managed worker beside the server	Processes
`#[EnableDaemon(Bar::class)]`	a supervised fleet of workers	Daemons
`#[EnableAsync]`	proxies `#[Async]` methods so they run off the request	Async
`#[EnableActuator]`	`/actuator` — health, pools, metrics, mappings	Actuator
`#[Import('vendor/pkg', '/prefix')]`	mounts a package under a URL prefix	Packages

Everything else is an ordinary class the scan finds — there are no configuration hooks to override:

#[Configuration] / #[Bean]   // DI factories            → dependency-injection
WebConfigurer                // host, port, CORS, static → web-configuration
LoggingConfigurer            // extra log channels       → logging

Full list and the rules: Components.

Documentation map

The whole reference lives at winterframe.net. The tree below mirrors the site's own navigation.

1. Introduction — what this is, and whether it fits you

2. Getting started — from an empty directory to a served request

3. Web basics — everything between the request and the response

4. Background components — work that outlives a request

5. Database (PPA) — needs flytachi/winter-ppa

6. Redis — needs flytachi/winter-redis

7. CLI — the call command and everything under it

Overview
make — generate a component
cfg — .env, keys, Docker, completion
run — serve the application
db — ping, migrate, SQL preview, pools
mapping — the route table
storage — service directories
script — your own commands
di — scanner cache and #[Async] proxies
process — start, stop, status
daemon — fleets of workers
schedule — the scheduler

8. Advanced — the parts you reach for later

License

MIT — see LICENSE.

flytachi / winter-kernel

Maintainers

Package info

Statistics

Security

README

What is not in it

Requirements

Install

Mini start — two files

What the application contains — `#[Enable*]`

Documentation map

License

flytachi / winter-kernel

Maintainers

Package info

Statistics

Security

README

What is not in it

Requirements

Install

Mini start — two files

What the application contains — #[Enable*]

Documentation map

License

What the application contains — `#[Enable*]`