- Is jungi/framework-extra-bundle a Laravel package?
- No. It is a Symfony bundle: it registers a Bundle class, ships a Symfony DI extension and compiler passes, and hooks the kernel.request and kernel.response events. Laravel has no BundleInterface, no config/bundles.php, and no HttpKernel dispatcher with the same semantics, so the package cannot be dropped into a Laravel application. Anything you read describing it as a Laravel package is inaccurate.
- Can I install jungi/framework-extra-bundle in Laravel with Composer?
- Composer will happily download it, but the package will not function in a Laravel application. It expects Symfony's bundle registration surface, HttpKernel event dispatcher, and argument-resolver pipeline, none of which exist in Laravel. Making it work would require a compatibility shim that reimplements that registration layer, which is not a sensible investment.
- What does jungi/framework-extra-bundle actually do?
- It adds extra annotations and attributes beyond SensioFrameworkExtraBundle: route-level metadata for view and format, parameter resolution through value resolvers, and Accept-header content negotiation with q-value and wildcard handling. In short, it streamlines controller configuration with less boilerplate. All of that value lives inside Symfony's controller conventions.
- Which Symfony and PHP versions does jungi/framework-extra-bundle support?
- Release v2.1.0 moves all value argument resolvers to Symfony's ValueResolverInterface, which was introduced in Symfony 6.2, so 6.2 is the sensible known-good floor. There is no signal in the release that Symfony 6.4 or 7.x is supported, and PHP 8.3/8.4 plus PHPStan or Psalm compatibility remain unvalidated. Pin carefully and test before trusting any version ceiling beyond that.
- Does jungi/framework-extra-bundle work with Laravel 10, 11, or 12?
- No. There is no service provider, no middleware, and no binding into Illuminate\Routing, so no supported Laravel version can use it as published. Laravel's request pipeline, route-parameter injection, and container resolution differ structurally from Symfony's. The v2.1.0 change actually deepens the Symfony coupling rather than widening compatibility.
- How is jungi/framework-extra-bundle different from SensioFrameworkExtraBundle?
- SensioFrameworkExtraBundle is the long-standing Symfony bundle for controller annotations covering routing, caching, security, and template hints. jungi's package layers additional annotations and conventions on top, with a focus on richer content negotiation and attribute-driven request/response mapping. Both are Symfony-only; neither provides Laravel integration.
- How do I get attribute-driven routing and content negotiation in Laravel without this package?
- Most of it is already native: $request->prefers() and Accept-header parsing cover negotiation, and Route definitions, response macros, and form requests cover the rest. For the declarative attribute style you would extract the metadata design and reimplement it as a controller-attribute resolver plus a small middleware, roughly 200 to 400 lines. That reimplementation is the only path that holds up for a Laravel codebase.
- Is jungi/framework-extra-bundle still maintained?
- It is best-effort rather than dead. v2.1.0 is a genuine compatibility commit, so someone is tracking Symfony minor releases, but it landed after a long gap with no published cadence, no release policy, and no issue-tracker activity signal. Treat upstream as unpredictable and do not plan on a fix landing on your schedule.
- Is jungi/framework-extra-bundle safe to use in production?
- It carries real risk: around 20 stars and zero dependents means almost no ecosystem validation of edge cases such as q-value ordering, wildcard */* fallback, and 406 handling. The MIT license is clean, so forking and vendoring your own copy is legally unencumbered if you accept ownership. For a Laravel application there is no production-viable path at all.
- How would I test a Laravel reimplementation of this package's attribute behavior?
- Test at the HTTP boundary: hit routes with varied Accept headers via $this->get() and assert the status codes and selected formats, covering q-value ordering, wildcard fallback, and 406 responses. Unit-test the resolver against route parameter metadata in isolation. Keeping the attribute metadata in a plain value object makes it testable without booting the framework kernel.