Framework Extra Bundle Laravel Package

Product Decisions This Supports

• Scope check first: this is not a Laravel package. It is a Symfony bundle (jungi/framework-extra-bundle). If the product is built on Laravel, the decision is a near-automatic "no" — record it as a rejected candidate and move on. Its functional analogues in Laravel are Form Requests, API Resources, and middleware-driven Accept handling.
• API contract and content-negotiation strategy. The package's core value is PHP 8 attributes for request/response mapping and content negotiation (e.g., deciding JSON vs. XML representations per controller action). This informs roadmap decisions about whether the product exposes a single representation or negotiated representations, and whether versioning lives in attributes, routes, or media types.
• Controller ergonomics / time-to-market. Attribute-driven binding of request payloads and response formatting reduces per-endpoint boilerplate. The PM decision is whether that velocity is worth a dependency — here, the answer is to capture the pattern, not the package.
• Build vs. buy vs. adopt-native. Given the 2022 last release, archived status, 20 stars, and zero dependents, "buy" (i.e., depend on it) is off the table. The real decision is: use native Symfony 6.3+ attributes (#[MapRequestPayload], #[MapQueryString], #[Route], #[IsGranted]), or use FOSRestBundle for negotiation, or build a thin internal attribute layer.
• Modernization roadmap. Useful as a migration reference for teams moving off SensioFrameworkExtraBundle annotations to attributes — a concrete diff of what attribute-based controllers look like, without committing to the dependency.
• Dependency governance / supply-chain policy. A useful forcing function: does the org's policy permit archived, single-maintainer dependencies in production paths? If yes, define the exception criteria; if no, this becomes a documented precedent.

When to Consider This Package

• You are on Symfony 5.x/6.x, PHP 8+, and specifically want attribute-based content negotiation at the controller layer that native Symfony attributes still don't cover cleanly.
• You are mid-migration from SensioFrameworkExtraBundle annotations and want a reference implementation to copy patterns from — read, don't require.
• The team accepts the maintenance burden: fork it, vendor it, or pin it, with an explicit owner and a plan to replace it.
• You need its exact API surface for a short, isolated, throwaway internal tool where durability is irrelevant.

Look elsewhere when:

• The stack is Laravel, Slim, or plain PHP — different idioms entirely.
• You are on Symfony 6.3+, where request mapping and routing attributes are native and this becomes redundant surface area.
• You require security patching, PHP version currency, or vendor responsiveness — an archived repo offers none.
• You need broad ecosystem validation — 20 stars and 0 dependents means essentially no production hardening, no community bug reports, no third-party integration testing.
• You need content-negotiation depth (HAL/JSON:API, hypermedia, format-specific serialization groups) — FOSRestBundle, API Platform, or a custom negotiator will serve better.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed, archived open-source Symfony bundle — not a Laravel package. It costs nothing but carries no support. We are not adopting it as a dependency; we are using it as a design reference for how to cleanly express request/response behavior and content negotiation in controller code. The business outcome is lower per-endpoint boilerplate and a faster path off legacy annotation-based controllers, achieved using Symfony's own supported attributes instead of unmaintained code. Net: no license cost, no new vendor risk, modest engineering-velocity gain.

To engineering: Treat jungi/framework-extra-bundle as documentation, not a dependency. Last release was December 2022 and the repo is archived — no CVE response, no PHP version guarantees, and effectively zero downstream users to shake out bugs. Implement the equivalent using native Symfony attributes (MapRequestPayload, MapQueryString, Route, IsGranted) plus FOSRestBundle or a small internal negotiator if we need richer media-type handling. If we must consume the package, isolate it behind our own attribute or interface layer so removal is a one-file change.