Mthaml Bundle Laravel Package

Product Decisions This Supports

• Framework-fit triage (build vs. buy vs. skip). The first decision this package forces is a compatibility call, not a feature call. It is a Symfony2 bundle, not a Laravel package — no service provider, no Blade compiler, no Laravel integration surface. For any Laravel roadmap the PM decision is effectively skip; for a legacy Symfony 2.x maintenance effort it is a narrow, tactical option at best. This assessment should be recorded as supporting evidence for that call.
• Legacy sustainment vs. modernization. If we inherit a Symfony 2.x application with existing .haml templates, this bundle supports a "keep the lights on" posture: retain HAML rendering while a template-layer migration (to Twig on Symfony, or Blade on Laravel) is scoped and funded. It does not support a "standardize on HAML" decision and should never appear in a forward-looking architecture deck.
• Template-layer standardization. Informs the policy of permitting one templating standard per stack. Given HAML's thin PHP ecosystem — 38 stars, 0 dependents, a single-maintainer profile, and an EOL framework baseline — the PM decision is almost always "no, confine this to inherited code."
• M&A / technical due diligence. A useful signal when assessing an acquired or inherited Symfony2 codebase: presence of this dependency flags a legacy stack, a niche template dialect, and a real migration workstream with cost attached. Surface it in dependency-risk and SBOM reviews.
• Use-case scoping. Legitimate fit is narrow — a Symfony2 app whose templates are already HAML, whose team has Ruby/HAML fluency, and where rewriting markup costs more than carrying the dependency. Any other scenario should route to Blade (Laravel) or native Twig (modern Symfony).

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony 2.x (or a compatible legacy branch) and is in maintenance, not active feature development.
• Existing production templates are already authored in HAML; converting them is a scoped, funded project rather than a quick win.
• The team has genuine HAML familiarity and accepts whitespace-sensitive markup as a standing maintenance burden.
• The dependency is isolated behind the templating layer so it can be swapped without touching controllers or domain code.

Look elsewhere — decisively — when:

• The target is Laravel. This is disqualifying. Use Blade; consider Livewire or Inertia for interactivity, or a Twig bridge only if the team has Symfony heritage. Installing the Symfony bundle directly risks container/kernel assumptions, dependency conflicts, and DI bootstrapping errors that have no analogue in a Laravel app.
• The target is modern Symfony (5/6/7). Use native Twig. The bundle targets the Symfony EngineInterface/templating world that was removed after 2.x, so it inherits an unsupported baseline.
• Signals are thin. 38 stars and 0 dependents mean no downstream validation, no de facto community, and no observed production footprint beyond the author. Low opportunity score (~0.68) and a composite near 1.08 reinforce that this is a niche artifact, not a platform bet.
• Security or longevity review is required. An EOL-framework bundle with a single-maintainer profile is a standing risk: no guaranteed patches, no CVE response path, no upgrade runway. Treat it as vendored legacy code, not a supported dependency.
• Onboarding velocity matters. New hires will not know HAML, and HAML-in-PHP documentation is scarce relative to Twig/Blade. Debugging compiled templates is also less intuitive than debugging Blade.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, single-maintainer Symfony2 bundle for rendering HAML templates. It is not compatible with our Laravel stack, and it targets a framework generation that is no longer supported. Its ecosystem signals — 38 stars, zero dependent packages — tell us there is no community or vendor backing behind it. Recommendation: do not adopt for any new or forward-looking work. If we encounter it inside an inherited or acquired codebase, treat it as a legacy liability to be contained and scheduled for migration, not as a component to build on. Budget a bounded migration to Twig or Blade rather than ongoing investment in HAML.

For engineering (the practical brief): Not a Laravel dependency — no service provider, no Blade compiler, no integration surface. If you inherit a Symfony2 app using it, do three things: (1) pin the version and vendor it so upstream disappearance cannot break builds; (2) wrap rendering behind a single template-service boundary so the dialect is swappable; (3) open a migration ticket to Twig/Blade with a template inventory as the estimate basis. Do not extend its usage to new templates, and do not let HAML spread into new modules. If a HAML requirement genuinely surfaces on a Laravel initiative, spike the underlying mthaml/mthaml compiler behind a thin view adapter with precompiled, cached output — never install the Symfony bundle — and keep Blade as the documented fallback and exit plan.