Controller Action Extractor Bundle Laravel Package

Product Decisions This Supports

Feature-level decisions (where this actually earns its keep):

• Per-action observability: tagging logs, traces, and metrics with Controller::method instead of raw URLs. This unlocks dashboards like "p95 latency by action" and "error rate on CheckoutController::submit" — far more stable than route strings, which change with URL structure.
• Audit and compliance trails: recording who did what at the domain-action level (e.g., InvoiceController::void) rather than the HTTP path. Directly supports SOC 2 / GDPR access-log requirements and makes audit exports legible to non-engineers.
• Authorization and entitlement mapping: keying permission matrices, feature flags, or plan-tier gates off controller actions rather than routes. Useful when the same action is reachable via multiple routes or HTTP verbs.
• Admin/debug tooling: building an internal "what can this app do?" inventory — a controller/action catalog for support, QA, and API-surface reviews.

Roadmap and investment decisions:

• Build vs. buy (strongly build): the capability is "resolve the _controller request attribute and split it into class + method." In Symfony this is a ~20–40 line service over the framework's own ControllerResolver; in Laravel it's $request->route()->getActionName(). The package's entire value is that trivial normalization, plus edge-case handling for invokable controllers, Class::method strings, and closures.
• Cross-cutting concern placement: decide whether action-context resolution lives in framework middleware/listeners, a shared internal library, or a third-party bundle. This is an architecture decision with a long tail of consumers (logging, authz, flags, rate limiting), so it's worth making once and deliberately.
• Symfony upgrade planning: v2.0.2 adds a Symfony 8.1 job. This confirms the package is currently tracking the framework, but also confirms it must be re-released for every Symfony minor — a cost you inherit as a consumer and avoid entirely if the resolver is your own code.

When to Consider This Package

Adopt only if all of these hold:

• The stack is Symfony, not Laravel. Despite the "Laravel/PHP" framing, this is a Symfony bundle (...-bundle, GollumSF namespace, Symfony DI/service wiring). It will not drop into a Laravel app.
• Your product is GPL-3.0-compatible — internal-only tooling, or a project already distributed under GPL. The copyleft license is the single biggest adoption gate.
• You are assembling a Symfony bundle or reusable internal platform and want a ready-made abstraction rather than owning one.
• The team is comfortable with a single-maintainer, ~1-star, zero-dependent dependency and has the capacity to vendor/fork it if it goes stale.
• You pin Symfony minor versions tightly and are willing to upgrade the bundle in lockstep. Since the bundle couples to Request internals (see below), it is a per-minor-version upgrade obligation, not a drop-in.

Look elsewhere (or build in-house) when:

• Commercial/proprietary product — GPL-3.0 creates a distribution-triggered copyleft obligation that legal will almost certainly block for a tiny utility.
• Laravel or framework-agnostic stack — use native route resolution; there is nothing here to port.
• You need more than class + method — route name, HTTP verb, attributes/annotations, parameters, or middleware context. You'll outgrow this in a sprint.
• Security-sensitive use — if action identity feeds authorization decisions, you want code you own and can test, not a 1-star dependency in the trust path.
• Dependency governance matters — 0 dependents means no community validation, no downstream bug reports, and no ecosystem pressure to keep it current.

Risk notes from v2.0.2 (patch, no breaking changes, no new features):

• Coupling to framework internals is real, and it bites at minor versions. The release fixes a case where Request::$attributes — a property with hooks since Symfony 8.1 — could no longer be assigned on a PHPUnit double. Any library that has to mock or mutate Request::$attributes sits directly on framework internals; Symfony minor releases can break it silently. That is precisely the class of breakage we would rather discover in our own tests than in a third party's release cadence.
• Historical "Symfony N compatible" claims were weaker than advertised. The notes state CI only now actually pins the Symfony version via Symfony Flex (SYMFONY_REQUIRE); until this release, the symfony_* jobs installed the latest components rather than the targeted branch. So earlier compatibility guarantees were effectively untested. The new pinning is a genuine improvement, but it means the package's track record should be read from this release forward.
• Maintenance signal is mildly positive, decision unchanged. The maintainer shipped Symfony 8.1 support promptly and fixed the mock issue rather than letting the build go red. That is a credit to a single-maintainer project — but responsiveness does not offset a GPL license, zero downstream validation, and a surface area of ~30 lines.

Bottom line: this is a micro-utility, not a platform. Still treat it as a reference implementation to read for five minutes, then write the 30 lines yourself.

How to Pitch It (Stakeholders)

For executives: This is a small, single-purpose library that identifies which controller and method handled a request. Its strategic value is as an enabler of observability, audit logging, and entitlement checks — not as a product in itself. Recommendation: do not adopt as a dependency. It's GPL-3.0 licensed, has essentially no adoption (1 star, 0 dependent projects, single maintainer), and replicates functionality our framework already provides. Adopting it would add legal review, supply-chain risk, and a long-term maintenance obligation in exchange for code we can write in under an hour. The new v2.0.2 release is a maintenance patch — Symfony 8.1 support plus CI and mock fixes — which shows the maintainer is active but does not change any of the underlying economics; if anything, the fact that a framework minor required a patch illustrates the ongoing upgrade tax we would be signing up for.

For engineering: We need a stable Controller::method identifier for logs, metrics, audit records, and permission mapping. Rather than depend on gollumsf/controller-action-extractor-bundle, implement a thin resolver over the framework's native controller resolution:

• Symfony: decorate/wrap ControllerResolver, handle Class::method, invokable controllers, and closures explicitly.
• Laravel: use the route action name and strip the namespace.

Cover it with unit tests for invokable controllers, service-configured controllers, and closure routes — these are exactly the cases a small third-party bundle would get wrong silently. Budget roughly a half-day including tests, and we own the abstraction, the license, and the edge cases. Note one concrete lesson from v2.0.2: avoid assigning Request::$attributes on test doubles — with Symfony 8.1 that property uses hooks and is no longer writable on a PHPUnit mock, so build our resolver to read the resolved action rather than mutate request state. If someone wants to prototype with the bundle (v2.0.2 is Symfony 8.1-compatible) to sanity-check the API surface, that's fine — read it, don't ship it.