Assetic Config Bundle Laravel Package

Getting Started

This bundle is a thin Assetic filter: at asset compile time it scans your CSS/JS for placeholders and substitutes values pulled from the Symfony container's parameters. It is a Symfony 2-era package (Assetic, AppKernel, parameters.yml), so treat it as legacy tooling you inherit rather than something to adopt on a new project.

Minimal steps:

1. composer require fazy/assetic-config-bundle (or add to composer.json and run composer update — the package is old enough that you may need --ignore-platform-reqs or a manual VCS entry if Packagist metadata has drifted).
2. Register the bundle in app/AppKernel.php:

   $bundles = array(
       // ...
       new Fazy\AsseticConfigBundle\FazyAsseticConfigBundle(),
   );
   

3. Wire the filter into config.yml under assetic.filters and apply it to the relevant assetic.assets entry or in your Twig {% stylesheets %} / {% javascripts %} blocks with filter="fazy_config" (confirm the exact service id in Resources/config/services.xml — it is the source of truth, not the README).
4. Put a placeholder in your asset and run app/console assetic:dump --env=prod.

Where to look first:

• Resources/config/services.xml — the actual filter service id and any constructor args (this tells you whether it reads from %parameters%, the container directly, or a configured map).
• The filter class itself (typically Assetic/Filter/...Filter.php) — to see the exact placeholder regex and whether it uses preg_replace with a container lookup per match.
• DependencyInjection/Configuration.php — for any bundle-level config keys.

First use case: a brand color or API base URL that lives in parameters.yml and needs to land in compiled CSS/JS without hardcoding it in two places:

/* web/css/app.css */
.header { background: {{ brand_color }}; }

Then assetic:dump emits the literal value. That single round-trip validates the whole install.

Implementation Patterns

Twig-first usage. The most common day-to-day invocation is inline in templates, since that is where Assetic is normally driven:

{% stylesheets filter="fazy_config" output="css/app.css"
    '@AcmeBundle/Resources/public/css/app.css' %}
    <link rel="stylesheet" href="{{ asset_url }}">
{% endstylesheets %}

Chaining filters matters here — put fazy_config before any minifier so placeholders are resolved against readable source, then cssrewrite/yui_css/uglifyjs run on the substituted output. Ordering after a minifier risks the regex missing a placeholder that got mangled.

Centralised asset definitions. For anything reused across templates, define assets in config.yml instead of inline Twig, so the filter config lives next to the parameters it consumes:

assetic:
    filters:
        fazy_config: ~   # or the service id, depending on registration style
    assets:
        app_css:
            inputs: ['@AcmeBundle/Resources/public/css/app.css']
            filters: ['fazy_config']
            output: 'css/app.css'

Environment-specific values. Because the filter reads from container parameters, the same template produces different output per environment for free — parameters.yml in dev, parameters_prod.yml (or a %env()%-backed parameter, if your Symfony version supports it) in prod. Use this for API endpoints, feature flags, CDN hostnames, and analytics IDs.

Consuming the same value in PHP and assets. Define the value once as a parameter, inject it into a service where needed, and let the filter pick it up for the front end. That is the whole value proposition of the bundle — one source of truth across server and client.

JS config objects. A small pattern that works well: keep a config.js template with placeholders for a handful of values and include it before your app bundle, rather than scattering placeholders through app code.

Gotchas and Tips

• Assetic itself is deprecated/abandoned. Symfony moved to Webpack Encore and then AssetMapper. If you are evaluating this for new work, the honest answer is no — use Encore/AssetMapper with DefinePlugin or equivalent. This bundle only makes sense inside an existing Symfony 2 Assetic setup.
• You must re-dump when config changes. Substitution happens at dump time, not request time. Changing a parameter in parameters.yml does nothing until assetic:dump (or assetic:watch in dev) runs again. In dev, keep assetic:watch running or you will chase phantom bugs. In deploy pipelines, make assetic:dump --env=prod --no-debug a mandatory step after config is written.
• Missing parameters fail quietly or loudly depending on implementation. Most naive implementations use preg_replace_callback and either leave the placeholder untouched or throw on an unknown key. Test with a deliberately bogus placeholder once, so you know which behaviour you are dealing with — silent passthrough means broken values can ship to production and only show up as literal {{ foo }} in a browser.
• Placeholder syntax collisions. If the filter uses {{ ... }} or %...%, it will collide with Twig or Symfony's own parameter syntax inside templates, or with template engines (Handlebars, Vue) embedded in your JS. Pick a distinctive delimiter if the filter allows it, or restrict the filter to plain .css/.js files that are never processed as templates.
• Never let secrets into public assets. Anything substituted here is served to browsers. Audit which parameters are reachable — do not point the filter at a container-wide lookup if that means database passwords become substitutable in a stylesheet.
• Quoting and escaping. Values containing quotes, semicolons, or newlines will break CSS/JS. The filter does plain textual substitution; it does not know about your target language's escaping rules. Keep substituted values single-token (colors, hosts, numeric IDs) and avoid free text.
• Cache busting. Assetic's output filenames and any ?v= query params do not automatically incorporate your parameter values. A changed color with an unchanged output filename will be served from browser cache. Version the output name or add a cache-busting query tied to the parameter.
• Debugging approach. Dump once with --no-debug, then grep the output file for your placeholder string. If it is still there, the filter was not applied (wrong service id in filter="...", or the asset definition bypassed it). If it is gone but wrong, the parameter resolution is picking the wrong value — check environment and parameters.yml precedence. assetic:dump -v and clearing app/cache are your first two moves.
• Extension points are minimal. This is a regex-substitution filter, not a framework. If you need more than "parameter in, string out" — defaults, formatting, conditional blocks — fork the filter or wrap it in your own Assetic filter rather than trying to bend this one.
• Maintenance risk. Zero stars, zero dependents, no recent activity. Expect no upstream fixes. Vendor the source or fork it into your own namespace so a future Composer hiccup does not block a deploy; the whole filter is likely under a hundred lines.