Template Guesser Bundle Laravel Package

Product Decisions This Supports

• Convention-over-configuration for view resolution (concept, not code): The package's only durable asset is a naming convention — ProductController::listAction() → Product/list.html.twig. A PM can use this as a forcing function for a decision we actually own: do we want implicit controller-to-view mapping at all, or do we keep explicit view() / render() calls? Answering that shapes controller contracts, onboarding, and code review standards far more than any single dependency does.
• Build vs. buy, settled toward build: This is a micro-utility — a template-name guesser of a few dozen lines. The real decision is "take an unmaintained third-party dependency" vs. "internalize ~50 lines we control." As a PM, this is a clear build: the capability is small, testable, and the dependency carries abandonment risk with zero offsetting benefit.
• Architecture and theming roadmap: The underlying idea — controllers live in a bundle/package, views can be overridden by the host app — is exactly the pattern behind themable or white-label features. If a roadmap item requires "ship controllers in a module, let customers override the view," this package is a useful reference implementation of the resolution rules, not an installable component.
• Stack modernization signal: Its presence (or appeal) indicates a bundle-era Symfony mindset — annotations, SensioFrameworkExtraBundle, Bundle:Controller:action template notation. That is a data point when prioritizing framework modernization work and when auditing legacy services.
• Dependency governance policy: 6 stars, 0 dependents, no maintainer, no advisory history. Uses a real (if low-severity) case to justify a written policy: what adoption threshold must a runtime dependency meet before it enters the SBOM?

When to Consider This Package

• Only if a legacy Symfony 2.x/3.x service on the estate already uses @Template annotations with SensioFrameworkExtraBundle and needs guesses resolved against bundle Resources/views. In that narrow case it fits as designed — pin it and isolate it.
• Only if you have controllers genuinely shipped inside bundles and want the annotation to resolve without explicit template names.
• Vet first: Symfony minor version, PHP version, Twig 1.x bundle notation (removed in Twig 2 / Symfony 3), and the annotation reader. Expect no upstream fixes; confirm someone on the team will own patching it.
• Do not adopt if:
  • You are on Laravel. It is a Symfony bundle — no service provider, no auto-discovery, no HttpKernel controller-resolution pipeline to hook into. Laravel has no equivalent extension point; any port is a reimplementation, not an install.
  • You are on modern Symfony (Flex, templates/ directory, PHP attributes) where this guessing is obsolete.
  • You are not using @Template, or you are comfortable with explicit template names.
  • Your dependency policy forbids low-adoption, unmaintained runtime code — which it probably should.
• Rule of thumb: adopt the convention, not the package. Read it once, write the naming rules down, implement natively behind your own interface.

How to Pitch It (Stakeholders)

• To executives: This is a small, MIT-licensed, zero-cost Symfony utility that makes a legacy annotation convention resolve view templates from inside bundles. It has no budget or licensing implications. Our recommendation is not to adopt it as a dependency: it is unmaintained (6 stars, no dependents, no security contact), and the capability it provides is roughly fifty lines we can own outright. The commercial value is the pattern — implicit controller-to-view mapping that supports themable, overridable modules — which we can capture natively at trivial cost and without carrying an unsupported vendor artifact in our SBOM.
• To engineering: Note the framing correction up front — this is a Symfony bundle, not a Laravel package, and it plugs into SensioFrameworkExtraBundle's TemplateListener via a service override. There is no Laravel equivalent hook. The right move is to treat the repo as a reference implementation: extract its naming rules into a one-page spec, implement a typed TemplateNameResolver (or a base controller trait / ResponseFactory macro) in our own codebase, write tests against the spec, pilot on two controllers, and measure whether it actually reduces boilerplate or merely hides the mapping. If a legacy Symfony service truly depends on it, freeze that lockfile, mark the bundle unsupported, and fold its removal into that service's framework-upgrade or decommission epic. Either way, record the decision so it is not re-litigated.