- Does lmc/spirit-web-twig-bundle work with Laravel?
- No. lmc/spirit-web-twig-bundle is a Symfony bundle: it relies on a Bundle subclass, a DI extension, Twig namespace registration, and asset-resolution hints, and it ships no service provider, publishable config, or Blade surface. Laravel cannot bootstrap it, so the bundle is only relevant where a genuine Symfony and Twig application exists.
- How do I install lmc/spirit-web-twig-bundle?
- Run composer require lmc/spirit-web-twig-bundle in a Symfony application and register the bundle in config/bundles.php. You also install the @lmc-eu/spirit-web front-end package separately with npm and point the bundle's template and asset paths at it. In Laravel there is no equivalent install path, so use the npm package with Blade partials instead.
- What PHP, Twig, and Symfony versions does it require?
- The evaluation flags the declared PHP, Twig, and Symfony ranges as unverified, so open composer.json before committing. The bundle targets Symfony 6 and 7 with Twig 3, and Twig 3.x may be mandatory. Confirm the exact constraints yourself; they are not documented in the overview.
- Does the bundle include the Spirit Web CSS and JavaScript assets?
- The bundle does not ship the design system. It emits markup, meaning Spirit class names, modifier conventions, and accessible attribute wiring, against a separately installed @lmc-eu/spirit-web package. Treat the HTML, CSS, and JS contract as the real dependency and install Spirit Web yourself.
- Can I use Spirit Web components in Laravel Blade templates instead?
- Yes, because the portable part is the markup contract, not the Twig layer. Install @lmc-eu/spirit-web with npm and hand-port four to six representative components such as button, input, alert, and card into Blade partials. Do not reimplement a component library; copy the reference markup to validate the approach first.
- What is twigbridge and can it make this bundle work in Laravel?
- twigbridge can graft a Twig engine onto Laravel and register Twig extensions, but it does not emulate Symfony bundle bootstrapping. You would reconstruct extension registration, template namespacing, and asset paths by hand and run two template engines side by side. That cost is higher and less stable than porting the markup to Blade.
- Is the bundle actively maintained and safe for production?
- Signals are thin: one star, zero dependents, and no visible community backstop or release cadence. The technical capability is real, but the project's long-term release commitment is unclear. For a production Laravel codebase, do not take a dependency on this bundle; evaluate Spirit Web on its own merits.
- How do I configure the bundle's template and asset paths?
- Configuration is handled through the bundle's DI extension, which registers Twig template paths and asset paths so component templates resolve inside Symfony. Exact keys depend on the Extension class, so check the README and config reference. Laravel has no publishable config here, so any equivalent paths must be wired manually.
- What accessibility features does the bundle provide, and do they survive a Blade port?
- The bundle wires Spirit's accessible attributes and defaults into component markup, which is a real benefit. However, JS-driven behaviors such as focus management and ARIA state live in spirit-web behind an init layer the Twig bundle does not wrap. Any Blade port must keep that JS initialization or it will silently lose accessibility contracts.
- How should I test Spirit components if I port them to Blade?
- Render the ported Blade partials in feature tests and assert the class and attribute contracts, then add browser tests with Dusk or Playwright for focus and ARIA behavior. Because the JavaScript lives in spirit-web, testing the init layer separately catches regressions the markup assertions miss. Keep a small visual or snapshot check for each ported component.