- Is fazy/assetic-config-bundle a Laravel package?
- No. It is a Symfony 2bundle that registers an Assetic filter for replacing placeholders with Symfony dependency injection container parameters during asset compilation. Laravel does not use Assetic or a Symfony DI parameter bag for front-end assets, so the package does not integrate with Laravel's asset pipeline. Treat it as a Symfony legacy artifact, not a Laravel Composer dependency.
- Can I install fazy/assetic-config-bundle in Laravel 10 or 11?
- Realistically no. The bundle targets Symfony 2.x components and Assetic, which pin old versions of symfony/console, symfony/process, symfony/yaml, and symfony/event-dispatcher. Laravel 10 and 11 require Symfony 6 or 7 components, so Composer will usually report dependency conflicts. Forcing installation with --ignore-platform-reqs risks breaking other packages and is not a supported path.
- What does this package actually do?
- It provides an Assetic filter that rewrites placeholder tokens inside compiled CSS and JavaScript using values from Symfony 2 configuration parameters. The substitution happens during the Assetic dump or build step, so the resulting public assets contain baked-in values. It is a build-time configuration convenience for Symfony 2 applications, not a runtime Laravel helper.
- Does it work with Laravel Mix or Vite?
- No. Laravel Mix and Vite are Node-driven build tools, while this package hooks into Symfony's Assetic pipeline and DI container. There is no supported bridge between Assetic filters and Mix or Vite. You would have to run a separate Symfony-flavoured compile step alongside your normal Laravel build, which adds a second asset pipeline to maintain.
- Is Assetic still maintained?
- Assetic is abandoned and was removed from the Symfony ecosystem years ago. This bundle depends on that abandoned layer and has no active upstream maintenance, issue triage, or security response. Adopting it means owning the code and any fixes yourself with no realistic path to upstream support.
- What PHP and Symfony versions does it require?
- The package is built for Symfony 2.x and its Assetic bundle, with dependency constraints from that era. Symfony 2 reached end of life in 2018, and code of this vintage may rely on PHP constructs removed in PHP 8. Even as a reference implementation, expect to read it rather than run it on a modern Laravel stack.
- How do I substitute config values into compiled assets in Laravel?
- Use the native build pipeline. For build-time replacement, export a whitelisted subset of configuration as VITE_* or MIX_* environment variables and use a small Vite or PostCSS plugin to replace tokens such as __CONFIG__ during npm run build. For runtime replacement, ship one artifact with placeholders and resolve values at request time through Blade or a small runtime config endpoint.
- Are there security risks with baking config values into assets?
- Yes. Anything substituted into publicly served CSS or JavaScript is effectively published to every visitor. If a placeholder is misspelled or a parameter is undefined, the literal token may survive into production assets, which is both visibly broken and a soft disclosure of internal naming conventions. Never route secrets, API keys, or internal-only values through an asset placeholder mechanism.
- Can I use it as a reference for build-time placeholder replacement?
- You can read it for the pattern, but do not adopt the package. The underlying idea, substituting tokens from an environment-specific parameter map during a build, is sound and straightforward to reimplement in a Vite plugin or a small Node script. Reimplementing keeps you inside the build pipeline your Laravel team already runs and avoids legacy Symfony dependencies.
- What are alternatives for injecting environment config into Laravel front-end assets?
- The standard alternatives are Vite environment variables with import.meta.env, Laravel Mix environment variables, or a custom Vite plugin for token replacement. For values that must change per environment without rebuilding, prefer runtime resolution through a Blade-emitted meta tag or a JSON config endpoint. All of these are Laravel-native and avoid adding a parallel Symfony or Assetic compile step.