Redirect Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy for redirect management — and the answer it points to is build. The entire functional surface is a source path, a target path, a status code, and a listener that emits a RedirectResponse. In Laravel that is one migration, one Eloquent model, one global middleware, and a small CRUD screen — roughly 150–300 lines. Buying this package saves days at most, imports a dependency you own forever, and still leaves you auditing unaudited source.
• Stack-fit triage, as a worked rejection example. The intake record lists this as a Laravel/PHP package; it is a Symfony2 bundle (EoRedirectBundle, registered in AppKernel::registerBundles(), Symfony 2.1+). There is no service provider, no config/redirect.php, no publishable migration. As PM, treat that as a disqualifier before an engineering spike is scheduled, and correct the catalogue entry so it isn't re-evaluated next quarter.
• SEO and information-architecture roadmap ownership. Redirects are not a convenience feature; they are the mechanism that preserves link equity and prevents soft-404s across URL migrations, replatforms, content consolidation, and campaign/vanity URLs. This evaluation is the argument for putting redirect management on the roadmap as an owned capability with tests, hit logging, and 404 monitoring — not as a third-party convenience bolted on during a launch.
• Legacy-portfolio triage. If any team still runs a Symfony 2.x service, the relevant finding isn't "adopt this bundle" — it's that the service sits on a framework that reached end of life in 2019. That becomes a migration line item with a budget, not a dependency decision.
• Dependency-policy precedent. Zero stars, zero dependents, one maintainer, dev-master as the only documented install target, and readme-level maturity (no tests, no CI, no changelog, no security policy). That's a clean worked example for codifying an internal adoption bar: pinned releases, tests, maintained upstream, audited license, named escalation path.
• Risk-surface recognition for request-path code. A redirect subsystem is, by nature, an open-redirect and header-injection surface and a potential per-request latency tax. Deciding that unmaintained code never enters the request path is a policy decision this evaluation supports directly.

When to Consider This Package

Adopt only if all of the following hold — and expect the answer to remain no:

• The codebase is a Symfony 2.1–2.8 application (not Laravel) and will stay there for the dependency's lifetime.
• Requirements are genuinely trivial: static exact-path → path mappings. No wildcards, no regex, no query-string preservation, no per-locale routing, no analytics, no editorial UI.
• You accept dev-master with no tagged release, and will vendor-pin a specific commit hash, read the source yourself, and fork it if needed — there is no community review, no security disclosure channel, and no upgrade history.
• A named internal owner exists who will maintain the fork, because upstream is one person with no downstream users to surface defects.

Look elsewhere — or build — if any of these are true:

• Laravel or any non-Symfony stack. Hard stop. This is not a Laravel package and cannot be installed without rewriting the integration layer.
• You need redirects to be observable and correct: 301-vs-302 semantics and their caching consequences, loop detection, chain flattening, hit logging for SEO reporting. An unmaintained bundle gives none of this, and a subtle bug here silently damages search rankings.
• You need scale or governance: hundreds of rules, bulk import, approval workflow, audit trails, staged rollouts.
• Your dependency policy requires tagged releases, a test suite, an active maintainer, or a security response commitment — this fails all four.
• You want to avoid inheriting an EOL framework's constraints inside an otherwise modern stack.

How to Pitch It (Stakeholders)

To executives: We evaluated eo/redirect-bundle for redirect management and recommend against adoption. It is a Symfony2 component being considered for a Laravel codebase — it will not run on our stack without a rewrite. Beyond the mismatch, it is effectively unmaintained: no stable release, no tests, no changelog, no dependents, a single author. The capability itself is small: a redirect table plus a middleware. We can own it internally in a few days, with tests and monitoring we control. Recommendation: build it, keep the SEO-critical path in-house, and record this as a rejected candidate with the reason so we don't re-evaluate it.

To engineering: This is a Symfony2 bundle, not a Laravel package — do not schedule a spike against it. Even on Symfony it ships as dev-master only, with installation-only documentation and no test suite, so we'd be reviewing and pinning source ourselves anyway. Implement natively: a redirects table (source path unique-indexed, target URL, status code default 301, active flag, hit count, last hit), a model with a cached lookup, and a global middleware registered ahead of the router that redirects on match and passes through otherwise. Add loop/cycle detection at write time, restrict targets to relative paths or an allowlisted host set to close the open-redirect hole, collapse chains on save, and test 301-vs-302 caching semantics. Optionally log unmatched paths to a redirect_candidates table for editorial review. That is less work than porting and auditing the bundle, and it leaves us with something we can monitor and evolve.

Risk summary for the record: platform incompatibility, unmaintained upstream, unstable dev-master constraint, zero community validation, EOL framework lineage, and SEO-critical, security-sensitive behaviour with no correctness guarantees. If a legacy Symfony app must temporarily retain it, pin to a commit hash and gate any replacement behind a shadow-run against production access logs before cutover.