Micro Symfony Laravel Package

Getting Started

yceruto/micro-symfony is a thin bootstrap layer over the Symfony components (HttpKernel, Routing, DependencyInjection, HttpFoundation) that lets you stand up an HTTP application from a single entry file. In Laravel terms: think of it as the kernel + router + container, with no Eloquent, no Blade, no queue, and no service providers-by-convention.

Minimal steps:

1. composer require yceruto/micro-symfony
2. Create an entry point (e.g. public/index.php) that builds the kernel, declares routes, and runs it:

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

use Symfony\Component\HttpFoundation\Response;
use Yceruto\MicroSymfony\MicroKernel;

return MicroKernel::create()
    ->route('/', fn () => new Response('ok'))
    ->run();

3. Point your web server / PHP built-in server at that file: php -S 127.0.0.1:8000 -t public.

Where to look first:

• vendor/yceruto/micro-symfony/README.md and any examples/ directory — this package is small enough that the source is the documentation.
• The MicroKernel class itself: it is the entire public API surface and shows exactly which Symfony components get wired in and in what order.

First use case for a Laravel developer: a small, isolated endpoint that must not drag the full framework boot cost or the full dependency tree — a Stripe/GitHub webhook receiver, a health/readiness probe, an OAuth callback, or a one-off internal JSON API sitting next to an existing Laravel app. It is also a good fit for laravel/sail-style local tooling or a CLI-adjacent HTTP shim.

Implementation Patterns

Single-file-first, extract later. Start with closures in the entry file, then promote to invokable controller classes once a route exceeds ~20 lines or needs a service. The kernel does not care whether a route target is a closure or a [Controller::class, 'method'] callable, so the migration is mechanical.

Entry file as the composition root. Treat the chain of ->route(), ->withServices(), ->withConfig() calls as your AppServiceProvider. Keep it declarative: register services, register routes, run. Business logic goes in classes under src/.

Routing. Symfony's attribute routing works if you point the kernel at a directory of controllers (#[Route('/orders/{id}', methods: ['GET'])]). For anything under ~5 endpoints, the fluent ->route() form is faster to read and diff. Remember Symfony route placeholders use {id} and {id<\d+>} — not Laravel's {id} + ->where(), though the constraint syntax achieves the same result.

Middleware. There is no Laravel middleware stack. Use the kernel.request / kernel.response / kernel.exception events with an EventDispatcher subscriber, or wrap a controller. Anything you would put in a Laravel middleware group (auth, CORS, request ID) becomes an event subscriber here.

Services and DI. Register explicitly in the kernel — there is no autowiring-by-scan of app/. Constructor injection works, but every dependency must be declared. Use compiler passes only if you are building shared infrastructure; for a micro app, closure factories are clearer.

Testing. Do not spin up a web server. Instantiate the kernel in a PHPUnit test and hand it a Request:

$response = $kernel->handle(Request::create('/orders/1', 'GET'));
$this->assertSame(200, $response->getStatusCode());

This is the biggest day-to-day advantage over a full Symfony/Laravel app — a request/response test with no boot overhead.

Running alongside Laravel. Keep it a genuinely separate application: its own composer.json, its own document root, its own deploy target (subdomain or /webhooks path on the edge proxy). Do not try to share Laravel's vendor/ or bootstrap file.

Deployment. The kernel returns from the entry file, so symfony/runtime and FrankenPHP/RoadRunner workers work as expected. For a worker-mode runtime, resolve services lazily inside controllers rather than capturing them at kernel construction, or you will leak state across requests.

Gotchas and Tips

v4.2.0 is a link-only release. The published notes are just a compare URL — no migration guide, no changelog bullets. Treat it as an unverified patch bump: read the diff (compare/v4.1.0...v4.2.0) before upgrading, and pin the exact version in composer.json ("yceruto/micro-symfony": "4.1.*") if the app is in production. Given the package's small surface, the diff is short enough to actually read.

It is not a Laravel replacement. No Eloquent, no migrations, no Blade, no queues, no validation layer, no auth scaffolding. Bring doctrine/dbal or plain PDO if you need a database, and expect to write your own validation. Scope creep here is the main failure mode: once you need three of those things, you should be writing a Laravel (or full Symfony) app instead.

Cache is the number-one debugging trap. Attribute route discovery and the compiled container are cached to disk. Editing a route and seeing the old behaviour almost always means a stale cache. Clear it (rm -rf var/cache/*, or the equivalent cache:clear if a console is wired up) and, in production, make cache warmup part of the deploy rather than a first-request cost.

Autoloading matters for attribute routes. If a controller is not PSR-4 autoloadable, the route silently does not exist and you get a 404 with no warning. composer dump-autoload and check the namespace mapping before you start debugging the router.

Debugging. Enable kernel debug mode locally so exceptions render with a stack trace instead of a bare 500. When routes are missing, dump the route collection rather than guessing; when a service is not found, dump the container. There is no Telescope equivalent — plan on dump()/var_dump() plus Xdebug.

Symfony component versions are the real compatibility surface. The package constrains Symfony components loosely enough that a composer update in a shared monorepo can bump HttpFoundation or Routing underneath you. If this app lives in the same repo as a Laravel app, keep separate vendor/ directories or you will spend an afternoon on a constraint conflict that has nothing to do with your code.

Extension points, in order of preference: event subscribers → a custom kernel class extending MicroKernel → container compiler passes. Reaching for the third before trying the first is a sign the app has outgrown the micro model.

Keep the entry file thin. A 400-line index.php is the failure state. If the entry file is the largest file in the project, refactor before adding the next feature.

Logging and errors. Symfony's ErrorHandler and Monolog are not free here — register a logger explicitly if you want structured logs, and make sure uncaught exceptions in the kernel.exception listener still produce a well-formed response rather than leaking a stack trace to a webhook provider that will retry forever.