No Framework Bundle Laravel Package

Product Decisions This Supports

• Architecture / coupling strategy: This bundle is a reference implementation of the “controllers without the framework” pattern — thin HTTP entry points that delegate to framework-agnostic application code. It supports the decision of whether to keep business logic inside framework-bound controllers or extract it into plain PHP services, and how much portability you actually need.
• Framework migration and legacy modernization roadmap: Directly relevant when scoping an exit from Symfony (or, by analogy, Laravel) — incremental strangler-style moves, running old and new stacks side by side, or reusing controller-level logic across a CLI, queue worker, or second application.
• Build vs. buy vs. borrow: The correct answer here is borrow the pattern, not the dependency. Use it to price an internal abstraction layer (a small action/handler convention) against the cost of adopting and owning a third-party bundle.
• Vendor and maintenance risk assessment: A useful case study in dependency lifecycle — 123 stars, zero dependents, archived, and superseded by GyroProject MVC-Bundle. Feeds directly into dependency-approval criteria and an “abandoned package” policy.
• Use cases worth prototyping: multi-framework or multi-tenant deployments sharing a controller layer; ADR (Action–Domain–Responder) style codebases; teams standardizing invokable action classes across Laravel and Symfony services.

When to Consider This Package

Consider the pattern (not the package) when:

• You are on Symfony and want controllers that do not extend AbstractController, do not depend on FrameworkBundle, and can be unit-tested without booting a kernel.
• You are planning a migration or a multi-runtime product (web + CLI + workers) and want one controller/action contract across entry points.
• You want a compact, readable codebase to study before writing ~200 lines of your own abstraction — this is small enough to read in an afternoon and fork if needed.

Look elsewhere when:

• You are on Laravel. This is a Symfony bundle and will not install or function in a Laravel application without a rewrite. The Laravel-native equivalents of this idea are invokable controllers, form requests, the service container, and action-class packages such as lorisleiva/laravel-actions.
• You need anything production-supported. The repository is archived and the maintainers moved it to GyroProject MVC-Bundle. Zero dependents means no ecosystem pressure to fix bugs and no security patching. Do not put it in a dependency tree you are not prepared to own outright.
• You need an SLA, LTS guarantees, or a vendor to call. Not available.
• You want a framework-agnostic controller layer today. Prefer the actively maintained successor, or a first-party convention inside your own codebase.

How to Pitch It (Stakeholders)

To executives: This is not a component we should adopt. It is a small, archived Symfony bundle that demonstrates a well-known architectural idea — keeping controllers independent of the framework so business logic stays portable and testable. Its real value to us is as a cheap reference point when we decide how tightly to couple our application code to Laravel or Symfony, and as a data point in how we govern abandoned dependencies. Recommendation: no new spend, no new dependency; treat it as design input only.

To engineering: Read it, don’t require it. It is archived, has no dependents, and has been superseded upstream, so any adoption means we take full ownership of an unmaintained codebase. If the decoupled-controller pattern is valuable to us — and for migration or multi-runtime work it often is — we should either use the maintained successor bundle or implement a thin internal convention (invokable actions with no framework imports) that we control and can test without booting the framework. If a team wants to fork it as a starting point, that is acceptable only with an explicit owner and a plan to replace it, not as a long-lived dependency.

Ask: approve the pattern as an architectural guideline; decline the package as a dependency.