Micro Framework Bundle Laravel Package

Technical Evaluation

Architecture fit. Unchanged by v0.8.0. gnugat/micro-framework-bundle remains a Symfony bundle that replaces FrameworkBundle with a curated minimal service set (kernel, event dispatcher, router, config/DI wiring). Nothing in the release targets Laravel's HTTP kernel, container, facades, Eloquent, or Artisan. The only viable fit is still out-of-process: a small standalone Symfony-based service, worker, or CLI beside a Laravel monolith, communicating over HTTP, a queue, or shared storage. In-process adoption remains a category error, not an integration task — two kernels, two containers, two config systems in one runtime.

Integration feasibility. This is where the release materially changes the picture, and only partially. The prior blocker was a constraint set pinned to Symfony 4.4/5.x and PHP 8.0/8.1, which could not resolve against Laravel 10/11 (Symfony 6/7). v0.8.0 moves to Symfony 6 / PHP 8.0 floor / PHPUnit 9, which means:

• Laravel 10 vendors Symfony 6.x transitively, so a Composer co-install spike is now plausible where it previously was not. This upgrades the gate from "expected to fail" to "must be tested."
• Laravel 11 tracks Symfony 7. Symfony 6-only support still will not resolve. The incompatibility is deferred, not eliminated.
• The BC breaks (drops Symfony 5, drops PHP 7) are irrelevant to us — we have no existing install — but they confirm the bundle is not carrying an LTS branch.

Feasibility still ultimately reduces to "separate deployable, separate composer.json, separate image." A passing Composer resolution does not create an in-process path.

Technical risk. Still high relative to value, but the risk profile shifted in two directions.

• Improved: the Symfony 5 end-of-security-support clock — previously the dominant compliance liability — is retired. If the constraint resolves to Symfony 6.4 LTS, the security runway extends to roughly late 2027. The PHP floor of 8.0 is itself EOL, but a floor does not force an EOL runtime; confirm the bundle is clean on 8.2/8.3.
• Worsened as a signal: this is the first release since 2022-02-25 — a gap of over three years — and it lands on Symfony 6 at a point when Symfony 7 is already current. A single catch-up release after a multi-year silence is evidence of sporadic maintenance, not a revival. Star count (37), zero dependents, and single-maintainer status are unchanged by the release. An overall score of 0.275 with opportunity at 0.16 is not overturned by one tag.
• The underlying documentation gap is unchanged: services normally supplied by FrameworkBundle (validation, serializer, security, profiler, form) must still be hand-wired.

Key questions.

• Does the tag declare ^6.0 or ^6.4? Only 6.4 is LTS; a ^6.0 constraint does not guarantee a supported install.
• Re-run composer why-not gnugat/micro-framework-bundle against Laravel 10 and Laravel 11 specifically — the answer now differs between them.
• Is v0.8.0 a one-off catch-up or the start of a cadence? Is there a Symfony 7 plan, and on what timeline relative to our Laravel 11 upgrade?
• Is the intent in-process (still reject) or a bounded sidecar/CLI (evaluate)?
• Who owns the fork — is there an internal PHP/Symfony owner, or a Laravel-only team?
• Does Laravel Zero, Slim 4, or a stock symfony/skeleton on Symfony 6.4 already cover the concrete use case with better support?
• What is the exit plan if the maintainer goes quiet again for another three years?

Integration Approach

Stack fit. Unchanged. PHP 8.x is shared and the bundle's PSR-11 posture is compatible in spirit, but only at the process boundary. Its own repository, composer.json, container image, and deploy pipeline. Do not load the bundle's kernel inside an Artisan command or a Laravel service provider — the new Symfony 6 constraint does not make that any less of a category error.

Migration path. Still none from Laravel to this bundle, and none should be attempted. The path remains additive: one narrow workload (health/metrics endpoint, webhook receiver, scheduled maintenance CLI), one deployable, prove the boot-time and footprint claims. If the pilot succeeds, the decision is "adopt and fork," not "adopt and depend."

Compatibility. The constraint spike is now the decisive test and must be run per-Laravel-version:

• Laravel 10 / PHP 8.1–8.3: expected to resolve; verify at boot, not just at install.
• Laravel 11 / Symfony 7: expected to fail; record the exact conflict so the result is documented rather than rediscovered later.
• Check whether the tag pulls Symfony 6.4 (LTS) or an earlier, already-EOL 6.x minor.
• Boot the kernel on our actual runtime (8.2/8.3) — a bundle validated only against PHP 8.0 may surface deprecations at boot.

Sequencing.

1. Constraint and viability spike — one engineer, one day: dry-run against both Laravel 10 and Laravel 11, plus a boot smoke test on our PHP runtime. Resolve the exact Symfony 6.x minor.
2. Maintenance-signal check — has a Symfony 7 branch, issue triage, or roadmap appeared since v0.8.0? Weight this heavily; it determines whether the fork is a one-time cost or a standing one.
3. Build-vs-adopt comparison against Laravel Zero, Slim 4, and symfony/skeleton on Symfony 6.4 — boot time, LOC, dependency count, support commitment. Note that the release narrows but does not close this gap.
4. Isolated proof-of-concept deployable behind the monolith's observability stack.
5. Go/no-go with an explicit fork-and-own commitment.
6. If adopted, pin the fork, add a private security-patch cadence, document the service graph, and record the Symfony 7 migration as known future work.

Operational Impact

Maintenance. Adopting this still means owning it. Zero dependents and a single maintainer mean no community patch pressure. The release removes the immediate Symfony 5 EOL emergency and replaces it with a longer but still finite clock: Symfony 6.4 LTS security support runs to roughly late 2027, and there is no published Symfony 7 path. Combined with a three-year release gap, the correct planning assumption is that the next major-version bump is also on us. Budget a fork, a pinned tag, and a standing line item to track advisories.

Support. Community-only via GitHub issues, no commercial backing, no LTS commitment, no security policy. Unchanged by the release. Internal support must come from whoever owns the PHP service; a Laravel-centric team has no natural on-call owner for a Symfony micro-kernel. Still the largest organizational cost, still to be priced before the pilot.

Scaling. Upside unchanged and real: minimal boot, low memory, fast cold start, few moving parts — attractive for CLI workers, cron jobs, and serverless handlers. Downside unchanged: horizontal scaling is trivial, feature scaling is not. Every new capability (auth, validation, serialization, queue integration) is hand-wired and hand-tested because FrameworkBundle is absent. The complexity curve stays steeper than a conventional Symfony or Laravel app.

Failure modes.

• Composer resolution failure on Laravel 11 (Symfony 7) — the blocker is deferred, not removed, and recurs at our next major upgrade.
• Constraint resolving to a non-LTS Symfony 6.x minor, quietly reintroducing the EOL exposure the release was meant to fix.
• Another maintenance gap: a single catch-up release after three years is not a cadence, and the next gap may outlast the Symfony 6 window.
• Missing services normally supplied by FrameworkBundle, surfacing as runtime ServiceNotFoundException in paths outside the PoC.
• Silent convention drift — no profiler, no debug toolbar, a service graph new engineers cannot debug with familiar tooling.
• Security exposure from EOL transitive dependencies with no upstream patch channel, on whatever timeline the resolved Symfony minor dictates.

Ramp-up. Unchanged. Laravel-only engineers face a real curve on Symfony's DI extension, compiler passes, and config loading; the bundle removes documentation and conventions rather than adding them, making the curve steeper. Estimate one to two weeks to productive contribution for a strong PHP engineer with no Symfony background, plus ongoing context held by a single owner.

Verdict. The release removes the hardest blocker — Symfony 5 end-of-life — and makes Composer co-installation with Laravel 10 plausible for the first time. It does not change the architectural verdict, the ownership burden, or the comparison against alternatives. Do not introduce this as a dependency in a Laravel codebase. Re-run the constraint spike so the decision is documented against the current tag rather than the 2022 one, but the recommendation stands: Laravel Zero (team idioms), Slim 4 (larger community, active maintenance), or a stock symfony/skeleton on Symfony 6.4 (supported components, standard conventions, no fork obligation) remain the better answers for any workload that genuinely justifies a micro-kernel. Treat this bundle as an architectural reference for which services a minimal kernel needs, not as a dependency — and revisit only if a Symfony 7 release and a credible release cadence both appear.