Mthaml Bundle Laravel Package

Technical Evaluation

Architecture fit: Disqualifying for Laravel as-is. mthaml/mthaml-bundle is a Symfony2 bundle, not a framework-neutral library. Its deliverable is Symfony wiring — bundle registration in AppKernel, DI container service definitions (mt_haml), and hooks into the Symfony\Bundle\FrameworkBundle\Templating\EngineInterface lifecycle. Laravel has no equivalent extension point: no bundle kernel, no EngineInterface, no $view['slots'] helper bag. The only architecturally portable asset is the underlying mthaml/mthaml compiler, and only if it is extracted from the bundle and wrapped in a Laravel view engine or a build-time precompile step. As a TPM, the correct framing is: we are not adopting this package, we are evaluating whether to adopt its transitive compiler and own an adapter.

Integration feasibility: Low as a package; medium-low as a compiler-plus-adapter build. Viable integration routes are (a) a custom Laravel ViewEngine that compiles HAML to cached PHP, or (b) a build-time compile step emitting Blade/PHP artifacts, or (c) a Blade compiler extension for HAML islands. All three mean the team owns the bridge, the escaping contract, the cache invalidation, and the error surface. There is no observed precedent to copy: 0 dependents and 38 stars mean no downstream validation, no community recipe, and no production footprint beyond the author. Budget this as bespoke engineering, not integration work.

Technical risk: High, and concentrated in dependency resolution rather than feature gaps. Expect Symfony 2.x-era constraints (old symfony/* component ranges, possibly pre-PSR-4 autoloading conventions in the bundle) that will collide with a modern Laravel composer.json. Direct installation risks solver conflicts, kernel/bundle bootstrapping failures, and PHP-version breakage. Layered on top: HAML is a niche, whitespace-sensitive dialect in the PHP ecosystem, the bundle targets an EOL framework generation, and the maintainer profile is single-author. Treat any adoption as vendoring legacy code, not consuming a supported dependency.

Key questions:

• Is HAML a genuine product requirement, or is this an inherited-template problem where Blade satisfies the need? (Default answer: Blade.)
• Can we consume mthaml/mthaml alone and skip the bundle entirely? If yes, the bundle is out of scope and the risk profile changes materially.
• What Laravel and PHP versions are in the support matrix, and does the compiler run cleanly on them under a pinned constraint set?
• Runtime compilation or build-time precompile? (Precompile is the only defensible answer for production.)
• Who owns the adapter, and does that owner exist on the roadmap with funded capacity?
• What are the escaping and XSS guarantees in the compiled output, and can we prove them with tests rather than documentation?
• Documentation gap: the available developer guide truncates mid-pattern (partials/layouts section ends incomplete). Assume the team will reverse-engineer behavior from DependencyInjection/Configuration.php and the core library README — that is unbudgeted discovery time.

Integration Approach

Stack fit: Weak. Laravel standardizes on Blade; Symfony bundles are not a supported extension mechanism. Do not attempt to install the bundle into a Laravel app — it will fail on kernel assumptions and pollute the container surface even if it boots. The only coherent posture is to treat mthaml/mthaml as a compiler dependency behind an internal interface, and to keep Blade as the platform default for everything new.

Migration path: Time-boxed spike first, decision gate second. Concretely: (1) confirm the HAML requirement's owner and origin (inherited templates vs. team preference); (2) audit mthaml/mthaml compatibility against the target PHP/Laravel matrix and Composer constraints; (3) compile a representative template set — layouts, partials, slots/blocks, escaping edge cases — and diff output against expected; (4) only then build a ViewEngine adapter or precompile step. Keep the spike scoped to days, not sprints, and pre-commit to "no-go" if escaping or cache semantics cannot be proven. If the work proceeds, migrate incrementally: non-critical, read-mostly views first, and never port Symfony bundle configuration — replicate only compiler behavior.

Compatibility: Assume friction and price it in. The bundle is written against an EOL Symfony generation with old component ranges; Laravel compatibility is a function of the core compiler's PHP support, not the bundle's. Pin exact versions, vendor the compiler if upstream is at risk, and keep the adapter behind a narrow interface so the dialect can be swapped without touching controllers, models, or domain code. Do not let HAML syntax leak into application-layer code, job payloads, or mail templates that might later move back to Blade.

Sequencing:

1. Requirement triage — is HAML mandatory, and who signs off? Escalate to "use Blade" by default.
2. Dependency audit of mthaml/mthaml (PHP/Laravel matrix, maintenance status, license, security posture).
3. Escaping and cache-semantics proof via a test harness, not documentation.
4. Spike the adapter or precompile pipeline on a throwaway branch.
5. Decision gate: go (bounded scope, named owner, funded maintenance) or no-go (document the migration to Blade).
6. If go: roll out to a low-traffic surface, with Blade fallback and a written exit plan.

Operational Impact

Maintenance: High and permanent. Because the bundle will not track modern Laravel, the team inherits the adapter, the dependency pins, and — realistically — a fork of the compiler when a PHP upgrade breaks it. Every Laravel or PHP minor bump becomes a compatibility review rather than a routine dependency update. That is an ongoing tax paid for a niche templating format with no ecosystem depth. A TPM should model this as standing engineering overhead, not a one-time integration cost.

Support: Low. 38 stars, 0 dependents, single maintainer, Symfony2-era scope: there is minimal likelihood of timely upstream fixes, an organized CVE response path, or Laravel-specific guidance. Support effectively comes from internal expertise or the broader MtHaml project. Flag this in dependency-risk and SBOM reviews; the EOL framework baseline plus maintainer concentration is a standing audit finding.

Scaling: Acceptable only via precompilation. Request-time HAML compilation adds CPU and latency and puts cache invalidation on the critical path; for anything high-traffic, a build-time compile step or a compiled-template cache with explicit invalidation is mandatory. Treat runtime compilation as a development convenience. Horizontal scaling is fine once templates are precompiled artifacts; the risk is cache staleness across deploys and multi-node invalidation drift.

Failure modes: Parser errors on unsupported HAML constructs; stale compiled caches producing silently wrong markup after deploy; escaping/XSS gaps where the compiler's output diverges from Blade's auto-escaping contract; Composer solver conflicts blocking unrelated upgrades; PHP-version breakage on routine platform bumps; and — if anyone installs the bundle directly — confusing kernel/DI bootstrapping failures. Missing Laravel helpers and Blade directives will force custom shims that themselves become maintenance surface.

Ramp-up: Moderate to high. Developers fluent in Blade need HAML syntax training (indentation sensitivity, attribute syntax, =/- semantics, and the PHP-mode vs. Twig-mode split, where mixing flavors is the most common bug). Debugging compiled templates is less intuitive than debugging Blade, and Laravel-specific documentation is effectively nonexistent — the available guide is truncated mid-section, so onboarding relies on reading Configuration.php and the core library README. Budget for a proof-of-concept, a security/escaping review, and an explicit fallback plan before this package is treated as a viable dependency; absent a hard HAML requirement with a funded owner, the TPM recommendation is no-go, standardize on Blade.