Micro Framework Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a minimal PHP service scaffold. This bundle answers a narrow question: can we stand up routing, a DI container, and controllers without pulling the full Symfony FrameworkBundle? It is a reference implementation for that trade-off, not a dependency you adopt.
• Framework-lite architecture evaluation. Useful as a case study when we're deciding how much framework to pay for in small internal services, CLIs, or edge workers — it shows the floor of what Symfony needs to function.
• Not a Laravel decision, and v0.8.0 does not change that. This is a Symfony bundle. Laravel does not use the bundle system; it consumes Symfony components directly. The new release moves the Symfony version target, not the integration model. If the question on the table is "which packages do we add to the Laravel app," this stays out of scope and should be removed from the candidate list early.
• Roadmap signal, still weak but no longer stale. v0.8.0 is a real maintenance action — Symfony 6 and PHP 8 support, PHPUnit 9 — which retires the "abandoned since 2022" objection but does not establish a cadence. One dependency-bump release after a long quiet period is a data point, not a commitment. Keep treating it as an input to an internal spike, not a strategic bet.
• Due-diligence triage, revised. The prior call was "note and move on" on the grounds that the package was pinned to an ageing Symfony. That specific objection is now resolved. The remaining objection — no vendor, no support path, tiny adoption — is unchanged, so the call is still "note and move on" unless a concrete microservice need appears. Update the note so the next reviewer doesn't re-litigate a stale version argument.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is Symfony-based and on Symfony 6 (v0.8.0 dropped Symfony 5 support entirely; there is no dual-version path). Note this is a breaking change — any Symfony 5.4 LTS service must stay on the previous release line and is now on an unsupported branch of this package.
• Runtime is PHP 8.0+. Verify against our actual target (8.2/8.3) rather than assuming — the release notes state a floor, not a tested ceiling — and confirm PHPUnit 9 satisfies our test tooling if we vendor the suite.
• The service is genuinely tiny — a handful of routes, no auth stack, no ORM-heavy domain, no mail/queue/messenger requirements.
• Footprint or cold-start matters more than ecosystem access (e.g. small container image, low-traffic internal endpoint).
• We are prepared to vendor the code and own it. A version bump is not a maintenance guarantee; there is still no security-patch flow or escalation path.
• It is a prototype, spike, or throwaway internal tool — not a customer-facing critical path.

Look elsewhere when:

• The stack is Laravel. Use Laravel's own bootstrapping, or a plain Slim/PHP-DI composition if we want something lighter. There is still no integration path here.
• We are still on Symfony 5.4 LTS. v0.8.0 is a hard break in our direction; adopting it would force a Symfony upgrade as a prerequisite, which inverts the cost/benefit for a "we just want something small" decision.
• We need bundles, security, Doctrine, Messenger, or any standard Symfony ecosystem package — the whole point of this bundle is to omit those.
• We need long-term support, security patch flow, or a vendor we can escalate to. MIT license gives us the code, not a maintenance commitment, and one release does not change that.
• The service is expected to grow. The migration cost from a micro-framework to a full one is real and usually paid at the worst time.
• We need confidence in PHP 8.3/8.4 compatibility. The release only certifies an 8.0 floor; treat newer-runtime support as unverified until we test it ourselves.

How to Pitch It (Stakeholders)

To executives: This is a very small, MIT-licensed Symfony add-on that lets a PHP service run with a stripped-down framework. It shipped a new version that adds Symfony 6 and PHP 8 support — which clears the main objection from our last review, that it was stuck on an outdated Symfony. It does not change the recommendation. Adoption is still minimal, there are no downstream dependents, and there is no vendor to escalate to, so using it would mean we own maintenance ourselves. It also has no application to our Laravel codebase. Treat it as a reference design, not a dependency.

To engineering: v0.8.0 is a maintenance release: Symfony 6, PHP 8.0 floor, PHPUnit 9, with BC breaks dropping Symfony 5 and PHP 7. That makes it viable on a current Symfony 6 service where it previously wasn't, so we should retire the "it's pinned to Symfony 5" talking point. It's still a thin replacement for FrameworkBundle — container, routing, controllers, nothing else. Worth reading if we're sizing framework overhead for a small service; only worth installing if we're on Symfony 6, the service is trivial, and we're comfortable vendoring and owning a package whose release cadence is one bump after a long gap. If we still run Symfony 5.4 anywhere, this release makes it a non-starter rather than a maybe. For Laravel work, nothing changed — close the tab, bundles aren't our extension model.