- How do I pass PHP variables to JavaScript in a Symfony application?
- This bundle exposes PHP arrays, scalars, and objects to the frontend through a configurable JavaScript namespace, using a Twig helper or the bundle service for programmatic binding. You register it in AppKernel, configure the namespace, and bind values from a controller or template. It targets the legacy Symfony2/3 bundle system rather than modern Symfony Flex autoconfiguration.
- Does this bundle work with Laravel, and which Laravel versions are supported?
- No. It is a Symfony bundle that wraps the Laravel-oriented laracasts/PHP-Vars-To-Js-Transformer, so it is not a first-class Laravel package and does not declare Laravel version support. In a Laravel application, require laracasts/PHP-Vars-To-Js-Transformer directly and use its Js::put facade or config instead.
- How do I install hospect/php-vars-to-js-bundle?
- Install it with Composer, enable the bundle in your Symfony AppKernel, and configure the JavaScript namespace in your application config. Because the package has no visible release cadence, pin it to a commit SHA rather than a version range if you must adopt it. Confirm PHP and Twig constraint compatibility against your lockfile first.
- Does it support Symfony 5, Symfony 6, or Symfony 7?
- It is built for the legacy Symfony2 bundle system, with a Bundle class, Resources/config/services.yml, and manual AppKernel registration, so it does not map to Symfony Flex recipes or modern autoconfiguration. It is only drop-in for hosts already on Symfony 2.x or 3.x. For Symfony 5 and later, a small internal Twig extension plus a JSON serializer is the safer path.
- How do I configure the JavaScript namespace used by the bundle?
- The bundle lets you set a configurable JavaScript namespace so exposed values do not collide with other globals, for example a namespaced object such as window.__STATE__. Bind values through the service or Twig helper, then read them from your frontend scripts under that namespace. Keep the namespace stable and document it for frontend consumers.
- How does the bundle serialize arrays, objects, and other non-scalar PHP values to JavaScript?
- It provides JSON-safe serialization of PHP values, so scalars and arrays map cleanly to JavaScript, while objects need JSON-serializable public properties or a JsonSerializable implementation. Closures, resources, and many Doctrine entities will not serialize predictably and should be converted to plain arrays before binding. Test each payload shape rather than assuming arbitrary objects will work.
- Is this bundle compatible with a strict Content-Security-Policy?
- The typical output is an inline script assignment that populates a window namespace, which a strict CSP without unsafe-inline will block. If you use a nonce, hash, or strict-dynamic policy, adjust the emitted script tag or render the JSON into a data attribute and parse it from an external script. Validate this before adopting the bundle in production.
- How do I test the PHP variables exposed to JavaScript?
- Render the Twig template or call the service in a functional test, then assert that the output contains the expected namespaced JSON assignment and decode that JSON to verify each value. Unit-test any wrapper service with arrays, scalars, JsonSerializable objects, and null values. The bundle itself has no visible test suite, so your own coverage is essential.
- What are the alternatives to PHP-Vars-To-Js for Symfony?
- Write a small internal Twig extension and serializer service backed by json_encode with JSON_HEX_TAG, JSON_HEX_AMP, JSON_HEX_APOS, JSON_HEX_QUOT, and JSON_THROW_ON_ERROR, emitting into a namespaced global. This is roughly 100 to 150 lines including tests and avoids importing an unmaintained dependency. Laravel teams should use laracasts/PHP-Vars-To-Js-Transformer directly.
- Is hospect/php-vars-to-js-bundle actively maintained and safe to depend on?
- The package has very low adoption, a single maintainer, no visible CI, no test suite, and no security policy, and its supported Symfony 2.8 runtime reached end of life in November 2018. That means no security patching and likely constraint collisions with modern PHP, Twig, and Illuminate releases. Treat it as a reference implementation, or vendor it behind an internal interface if you must use it.