RUEN
Introduction

Ecosystem

Winter is not a monolith. The core is assembled from standalone libraries, each with its own repository, its own version and its own documentation. Any of them can be understood on its own, upgraded on its own, and used outside the framework.

Core flytachi/winter-kernelType libraryNamespace Flytachi\Winter\Kernel

The core

flytachi/winter-kernel is the only package you install yourself:

bash
composer require flytachi/winter-kernel

It pulls in the rest. What lives in the core is what makes Winter a framework:

Layer What is inside
HTTP Routing, parameter binding, validation, responses, middleware, CORS
Application The project scan, container assembly, #[Enable*] attributes, configurers
PPA Repositories, entities, query builder, migrations, connection pool
Processes The Process and Daemon stereotypes, the scheduler, parallel #[Async] calls
Console The call command, generators, shell completion

The core is type: library, not a project template: you create the skeleton yourself, out of a handful of files. How exactly — in the Installation.

The libraries

They arrive with the core; you do not install them separately.

Package What it does Docs
winter-di The container: autowiring, scopes, attributes → DI
winter-logger PSR-3 logging with channels and context → Logger
winter-cdo Type-aware PDO — the foundation PPA stands on → CDO
winter-thread Launching and controlling child processes → Thread
winter-base Base types: HTTP codes, methods, runtime modes, exceptions —
file-store File storage for the framework’s own data —

Beyond those the core uses vlucas/phpdotenv to read .env.

Installed separately

Package What it does Docs
winter-ppa The database layer: repositories, entities, migrations, pooling → PPA
winter-redis Pooled Redis: stores, hashes, lists, streams → Redis
winter-cpool A driver-agnostic connection pool → CPool
flytachi/jwt Strictly typed JWT and JWKS → JWT

Why split it up

The boundaries between packages are not cosmetic — they are how complexity is kept in check.

It ships in pieces. A fix in the logger ships as a logger release. You do not wait for a whole-framework release, and you do not have to accept twenty unrelated changes along with your fix.

It is tested in pieces. Every library has its own tests that do not depend on the others. The container is tested without HTTP; the database layer without the container.

It lives outside the framework. winter-di and winter-logger drop into any PHP project and work there on their own. That is useful in itself — and useful as a check: if a library needs the whole framework around it, the boundary was drawn in the wrong place.

Where things are documented

  • These docs cover writing an application: routes, requests, database work, processes, console, configuration.
  • Package docs are the deep reference for one library: manual container bindings, logger processors, the finer points of the query builder.

The rule is simple: the moment the subject becomes the internals of a particular library, follow the link into its own documentation.

Next