- Can I install mthaml/mthaml-bundle in a Laravel application?
- No. It is a Symfony2 bundle that relies on AppKernel registration, Symfony DI services, and EngineInterface, none of which Laravel provides. Installing it directly will not give you a Laravel view engine and is likely to cause Composer and bootstrap failures.
- Does MtHamlBundle support Laravel 10, Laravel 11, or modern PHP versions?
- There is no Laravel support matrix for this bundle; it targets Symfony2-era components. Its Symfony constraints and older autoloading conventions can conflict with modern Laravel and PHP versions. Treat Laravel compatibility as unproven unless you isolate and test the underlying compiler yourself.
- What is mthaml/mthaml-bundle used for?
- It integrates the MtHaml PHP implementation of HAML into Symfony's templating layer so .haml views can compile to HTML. It provides bundle wiring, configurable engine options and filters, reusable templates and partials, and compiled-template caching. It is not a Laravel package.
- How do I install and register MtHamlBundle in Symfony?
- Install it with Composer, then register the bundle in the legacy Symfony AppKernel and configure the MtHaml engine options. Because this is a Symfony2-era bundle, use it only in a matching legacy Symfony project and verify the exact service and configuration names against the bundle's DependencyInjection files. The available documentation is incomplete, so expect discovery work.
- Can I use the mthaml/mthaml compiler without the Symfony bundle?
- Yes, that is the only portable path for Laravel. The bundle is Symfony wiring; the underlying mthaml/mthaml compiler can be evaluated separately behind an internal interface or adapter. You would own the view engine or precompile step, cache invalidation, escaping contract, and error handling.
- How would I integrate HAML templates with Laravel's view system?
- You would need bespoke engineering: a custom Laravel ViewEngine that compiles HAML to cached PHP, a build-time precompile step that emits Blade or PHP artifacts, or a Blade compiler extension for HAML islands. Do not install the Symfony bundle into Laravel. Keep Blade as the default and time-box a spike before committing.
- How does template caching work with MtHamlBundle?
- The bundle provides compiled-template caching for production, so HAML is compiled once and reused rather than parsed on every request. In a Laravel adapter scenario, you would have to recreate that cache layer and define invalidation rules for template changes, partials, and configuration. Test cache clearing and deployment behavior explicitly.
- What are alternatives to MtHamlBundle for HAML templates in Laravel?
- For Laravel, Blade is the default and lowest-risk choice for new work. If HAML is a hard requirement, evaluate mthaml/mthaml directly behind a custom adapter or a build-time precompile step. Other PHP template engines such as Twig or Latte are alternatives only if the requirement is concise templating rather than HAML syntax specifically.
- Is MtHamlBundle maintained, and will it conflict with modern Composer dependencies?
- It is a single-author Symfony2-era bundle with no dependents observed, so assume legacy status and high risk. Old symfony/* constraints, pre-PSR-4 conventions, and PHP version limits can conflict with a modern Laravel composer.json. Vendor and pin the compiler if you must use it, and budget for solver and bootstrap failures.
- What should I test before using compiled HAML in production?
- Compile a representative template set covering layouts, partials, slots or blocks, helpers, and escaping edge cases, then diff the HTML against expected output. Add XSS tests for variable interpolation and attribute contexts, and verify cache invalidation across deployments. Also test error reporting for malformed indentation and missing partials.