- Is gollumsf/controller-action-extractor-bundle a Laravel package?
- No. It is a Symfony bundle: the -bundle suffix, the GollumSF vendor namespace, and the Bundle class plus DI Extension pattern are Symfony conventions registered in config/bundles.php. Laravel has no bundle concept, and the package ships no Illuminate ServiceProvider, so nothing is auto-discovered or wired up on composer require.
- How do I install and register it in a Laravel app?
- You effectively can't without writing an adapter. There is no extra.laravel block and no service provider, so Laravel's package discovery finds nothing to register and the bundle's services would never be bound into the container. Any integration would mean authoring and maintaining a shim that translates Symfony request attributes into Laravel's route abstraction, for functionality Laravel already provides.
- How do I get the current controller class and action method from a Laravel request?
- Use the framework's native route introspection: request()->route()->getActionName() returns the Class@method string, Route::currentRouteAction() does the same statically, and Route::getCurrentRoute()->getActionMethod() gives you just the method name. The Route object also exposes structured access to the action array, and middleware receives the request context via $next($request). No third-party package is required.
- Which Laravel versions does this package support?
- None in any meaningful sense. It targets Symfony, so its composer.json constrains Symfony components rather than illuminate/support, and there is no Laravel version matrix to evaluate. Treat any Laravel compatibility claim as unverified until you see an actual service provider and a tested adapter.
- Does it handle closure routes, invokable controllers, and service-ID controllers?
- That normalization is the bundle's apparent value-add: it sorts out edge cases like closure routes, __invoke controllers, and _controller attributes that hold a container service ID instead of a Class::method string. In Laravel the equivalent is roughly 20 to 40 lines of your own code, and writing it natively keeps it idiomatic and testable against your real route table.
- What license does it use, and is GPL-3.0 a problem for a commercial Laravel app?
- It is GPL-3.0, which is copyleft. Internal-only use behind a SaaS generally does not trigger distribution obligations, but shipping an on-premises appliance, a customer-run Docker image, or embedding it in a package you publish makes the copyleft analysis live and requires legal review. That is a heavy compliance burden for a feature the framework gives you for free.
- Is this package actively maintained and production-ready?
- The public signals are thin: about 1 star, 0 dependents, and no observable production user base, which means bugs surface in your environment first. The reported last-release date of 2026-08-28 is anomalous relative to the rest of that signal and should be checked against the actual composer.json and tag list. Verify before treating it as maintained.
- Are there alternatives for extracting controller actions in Laravel?
- The framework itself is the alternative. request()->route()->getActionName(), Route::currentRouteAction(), Route::getCurrentRoute()->getActionMethod(), and iterating Route::getRoutes() cover audit logging, per-action metrics, RBAC keyed on controller/action, and feature flagging. php artisan route:list --json also gives you a structured map for docs and permission lists without adding a dependency.
- How should I test controller and action extraction in Laravel?
- Write feature tests that hit real routes and assert the resolved action name, and cover the edge cases in your own route table: closure routes, invokable controllers, resource routes, sub-domain routes, and queued jobs where there is no HTTP request at all. If you build a small helper or middleware, test it against the same fixtures. That coverage is what a shim would need anyway, so you may as well own it.
- Can I use controller/action extraction for RBAC or permission lists?
- Yes, but you don't need this bundle to do it. Permission checks keyed on controller and action are a thin middleware over Laravel's native route introspection, and permission lists for the UI can be generated from Route::getRoutes() or php artisan route:list --json. Owning that code keeps the permission model aligned with your actual routing rather than a Symfony abstraction.