Before After Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. use the framework: This package exists to solve one narrow need — run shared code before every action in a given controller (auth checks, audit logging, tenant scoping, feature-flag gates, request instrumentation). Evaluating it forces the decision that matters: do we add a dependency for this, or use the framework's own extension point?
• Closing out a recurring requirement: The underlying need ("cross-cutting behavior on every endpoint of a resource") will reappear in nearly every CRUD or API surface. A decision here becomes a reusable standard for how the team handles all cross-cutting concerns, not just this one.
• Platform/roadmap hygiene: The description and README are Symfony 2/3, not Laravel. Symfony 2/3 are end-of-life. This is a signal to check whether any part of our roadmap still runs on unsupported Symfony, which is a much bigger decision than this bundle.
• Dependency policy calibration: Two stars, zero dependents, one author, archived, README-level maturity, and an unfinished executeAfter() in the TODO list. This is a useful test case for setting a minimum bar (maintenance signal, test coverage, license, security response) before we accept any third-party package.
• Prioritization of the "after" case: The author never shipped the after-action hook. If our use case needs teardown/response mutation, this package is out of scope by definition — that's a scope decision we can make in minutes rather than after a spike.
• Not a differentiator: Nothing here is product-visible. It should never appear on a roadmap as a feature; at most it's an internal enabler with an estimated cost of hours, not sprints.

When to Consider This Package

Consider it only if all of the following are true:

• The codebase is a legacy Symfony 2.x/3.x application that is still in production and deliberately frozen.
• You need pre-action logic scoped to a single controller, and you want it declared in the controller class rather than wired as a service.
• The team has decided not to introduce a kernel.controller event subscriber or a shared base controller, perhaps because the existing code has no service wiring for that controller.
• The logic is trivial, side-effect-only, and non-critical (e.g., debug logging), so an unmaintained dependency carries no real blast radius.
• You are comfortable vendoring or forking the ~single class this package amounts to, since upstream support will not arrive.

Look elsewhere — and in practice, do look elsewhere — when:

• You are on Laravel, which is the framing of this assessment. Laravel middleware covers this need natively, with per-route granularity, ordering, termination hooks (terminate()), and zero new dependencies. There is no reason to port a Symfony 2/3 bundle into a Laravel app.
• You are on Symfony 4+ or any supported framework version. Use a kernel.controller event subscriber or a kernel.controller_arguments listener; both are first-party, typed, testable, and maintained.
• You need the "after" half. executeAfter() is unimplemented per the README TODO. Laravel middleware terminate(), Symfony kernel.terminate, or a response listener are the correct tools.
• You need per-action rather than per-controller granularity, ordering guarantees, or configuration via attributes/annotations/routes.
• Your dependency policy requires maintenance signals: active releases, CI, tests, a security contact, or more than zero downstream dependents. This package fails all of them and is explicitly archived.
• The behavior is security-relevant (authorization, tenancy isolation, rate limiting, PII scrubbing). Never build those on an archived, untested, single-author package.

How to Pitch It (Stakeholders)

One-line summary: This is a tiny, archived Symfony 2/3 helper for running code before controller actions; the need is real, but the package is not the answer, and the capability is already built into the frameworks we use.

For executives: We evaluated a third-party package for a recurring internal need — running shared logic on every endpoint of a given screen or API resource. Recommendation is do not adopt. The package is archived, effectively unmaintained (last activity predates the framework versions we target), has no meaningful usage base, and is missing half its advertised functionality. The good news is that the same outcome is available from the framework itself at roughly a half-day to one-day of engineering effort with no new dependency, no security surface, and no vendor risk. Net: no roadmap impact, no budget ask, and we avoid a long-term maintenance liability for a few hours of saved work.

For engineering: If the requirement is "run code before/after every action in this controller," implement it with the platform's native mechanism — Laravel middleware (with terminate() for the after case) or a Symfony kernel.controller event subscriber on supported versions. That gives us type safety, unit-testable units, explicit ordering, per-route control, and coverage in CI. The package's only distinct idea is opting in via an interface on the controller; we can reproduce that with a marker interface plus a listener if the team prefers that ergonomics. Please also confirm whether any service still runs Symfony 2/3 — that's the actual risk surfaced by this evaluation, and it should be tracked separately as technical debt.

Ask: No purchase, no adoption. Close the requirement as "solved by framework primitives," and add a line to our dependency intake checklist requiring maintenance and usage signals before any future third-party evaluation reaches a spike.