- What is survos/js-twig-bundle used for?
- It is a Symfony bundle that renders Twig blocks in the browser from Stimulus using twig-browser. It exposes path(), stimulus_* and ux_icon helpers so client-side templates can generate routes, Stimulus attributes and icons. Routes load as JSON through AssetMapper, so there is no JavaScript build step.
- Does survos/js-twig-bundle work with Laravel?
- It is a Symfony bundle built around Twig, Stimulus and AssetMapper, not a native Laravel package. Composer can install it, but Laravel does not ship AssetMapper or the Symfony Twig bridge by default, so expect integration work. Laravel teams may prefer Blade, Livewire or Inertia for similar browser-rendering needs.
- How do I install survos/js-twig-bundle with Composer?
- Run composer require survos/js-twig-bundle and register the bundle in your Symfony application configuration. Make sure AssetMapper and Stimulus are configured, since the package relies on them to load route JSON and browser-side Twig templates. Check composer.json for PHP and Symfony version constraints before upgrading.
- Which Laravel or Symfony versions are supported?
- The release note does not state a version support matrix, so verify the constraints in composer.json before installing. The package is Symfony-oriented and does not claim Laravel framework support. Test it in a feature branch against your exact PHP, Symfony and AssetMapper versions.
- Do I need Node, npm, or a JavaScript build step?
- No build step is required according to the package overview. Routes load as JSON through AssetMapper, and Twig blocks are rendered in the browser via twig-browser and Stimulus. That makes it attractive for teams that want to avoid maintaining a separate frontend build pipeline.
- What do path(), stimulus_* and ux_icon do in browser-rendered Twig?
- These helpers mirror common Symfony and Twig helpers so client-rendered templates can generate URLs, Stimulus controller attributes and UX icons. They are the main integration points for wiring server-side Twig conventions into frontend scripts. Confirm helper parity for any custom Twig extensions your templates use.
- How should I test survos/js-twig-bundle in CI?
- Install or upgrade the package in a feature branch, run your application test suite, and smoke test pages that render Twig blocks in the browser. Verify that route JSON loads through AssetMapper and that path(), stimulus_* and ux_icon output is correct. The 1.6.0 release removed dump calls via a hack, so also grep output for debug residue.
- Is survos/js-twig-bundle safe for production after the 1.6.0 release?
- Technical risk is low because 1.6.0 is a patch that removes dump() statements, but the note describes a hack rather than a clean upstream fix. That workaround could be overwritten by a future merge or conflict with survos-based tooling. Request a changelog or commit reference, smoke test diagnostic paths, and monitor after rollout.
- What are alternatives to survos/js-twig-bundle?
- For Symfony, consider Symfony UX Twig Components, Twig.js or server-rendered Twig depending on how much browser rendering you need. For Laravel, Blade, Livewire or Inertia are more natural fits. This package is most relevant when you already use Symfony, AssetMapper, Stimulus and twig-browser.
- How is survos/js-twig-bundle maintained and what are the risks?
- Maintenance burden looks minimal, but the release note is terse and the fix is described as a hack not via survos. The main risk is silent divergence if that workaround is reverted or replaced upstream. Track whether a clean fix is planned, watch for overlap with other survos tooling, and record the dependency rationale in your team log.