Twig Assetic Filter Bundle Laravel Package

Getting Started

This bundle is a small bridge between two legacy-but-still-deployed components: Assetic (Symfony's old asset compilation pipeline) and Twig. Its job is to expose a Twig-powered Assetic filter, so asset files (.css, .js, .svg, etc.) containing Twig syntax get rendered through Twig before being concatenated/written by Assetic.

Before writing any application code, do this reconnaissance — the repo has no stars and no dependents, so you cannot rely on blog posts or Stack Overflow:

1. Read README.md for the registered filter name (likely twig) and the config block.
2. Open DependencyInjection/ and Resources/config/services.* to find the Assetic filter service id and its tag (assetic.filter).
3. Open the filter class itself — that is the only real API surface. Note which Twig environment/loader it uses and whether it accepts options (template path, autoescape, charset).
4. Check composer.json for symfony/*, twig/twig, and php constraints. This tells you immediately whether it fits your project (this package predates Symfony Flex in all likelihood).

Minimal install:

composer require igraal/twig-assetic-filter-bundle

Register it where your Symfony version expects it. On Symfony 2/3 (AppKernel.php):

$bundles = [
    // ...
    new Symfony\Bundle\AsseticBundle\AsseticBundle(),
    new IG\TwigAsseticFilterBundle\TwigAsseticFilterBundle(),
];

On Symfony 4+ Flex (config/bundles.php), add the class manually — but confirm first that the bundle's Bundle class is autoloadable under PSR-4 and that it does not rely on removed APIs.

Your first use case should be the smallest possible: one CSS file with a Twig variable, compiled by Assetic with the bundle's filter.

{# app/Resources/assets/css/theme.css.twig #}
:root { --brand: {{ brand_color|default('#336699') }}; }

{% stylesheets filter='twig' output='css/theme.css'
    'bundles/app/css/theme.css.twig' %}
    <link rel="stylesheet" href="{{ asset_url }}">
{% endstylesheets %}

If that renders and assetic:dump writes a file with the variable substituted, the integration is working; everything else is variation on this.

Implementation Patterns

Parameterized design tokens in CSS. The highest-value pattern is keeping a single source of truth for colors, spacing, and breakpoints in Twig/PHP config, then injecting them into stylesheets at compile time. Keep the .twig files in a dedicated directory (e.g. Resources/assets/) so they never get served raw.

{# theme.css.twig #}
{% for name, color in theme.colors %}
.theme-{{ name }} { background-color: {{ color }}; }
{% endfor %}

Environment constants in JS. Emitting window.APP_ENV, API base URLs, feature flags, or Sentry DSNs into a compiled JS file avoids a runtime config endpoint. Combine with Symfony parameters passed into the Twig context.

Chaining filters. Assetic filters compose left-to-right. Put twig first (it needs the raw Twig source, not minified output), then the transform filters:

{% javascripts filter='twig,?uglifyjs' output='js/app.js' ... %}

The ? prefix means "only in debug mode" — useful while iterating, but remember it changes the dumped filename hash in dev versus prod, so validate both.

Scope the filter narrowly. Use apply_to in config.yml so the Twig filter only touches files with a .twig extension. Applying it globally will attempt to render ordinary CSS/JS as Twig, and any stray {{ or {% (common in Angular/Vue templates or documentation strings) becomes a template error.

assetic:
    filters:
        twig:
            apply_to: "\.twig$"

Deployment-time compilation. Run app/console assetic:dump --no-debug (or bin/console) as a deploy step and serve static files from web/. Do not rely on the dev controller for anything but local iteration — it is slow and should never be enabled in production.

Custom filters as extension point. If you need extra context (e.g. feature flags from a service), the cleanest approach is often to register your own Assetic filter tagged assetic.filter rather than fork this bundle; use the bundle's filter as a reference implementation for how to obtain the Twig environment from the container.

Gotchas and Tips

• The ecosystem is retired. Assetic has been removed from Symfony core since 4.x and symfony/assetic-bundle is abandoned. With zero stars and zero dependents, this package has no community safety net. If you are starting a new project, use Webpack Encore or Symfony AssetMapper (which has native importmap/asset handling) instead — you will spend less time fighting cache invalidation than adopting this bundle.
• Pin the version. composer require igraal/twig-assetic-filter-bundle:^x.y explicitly, and commit composer.lock. A silent minor bump in a package with no maintainers is a real risk.
• Autoescaping will corrupt output. Twig's HTML autoescape escapes &, <, quotes — fine for HTML, destructive for CSS/JS. In the asset templates themselves, either render with autoescape disabled or add |raw; better, configure the filter's Twig environment with autoescape: false if the bundle exposes that option.
• Cache invalidation, twice over. Assetic caches compiled assets on disk and Twig caches compiled templates. After changing asset source or the bundle's filter code, clear both: rm -rf var/cache/* plus assetic:dump. In debug mode, stale web/ output from a previous run is a common "why isn't my change showing" cause.
• Debug versus production filter syntax. In {% stylesheets %} tags, ?filter means debug-only; in the Assetic config, apply_to and filter options behave differently. Do not assume the runtime template syntax maps one-to-one onto config keys.
• Loader configuration. If a .css.twig asset uses {% include %} or {% extends %}, the filter's Twig loader must be able to resolve those paths. Check whether the bundle configures a FilesystemLoader rooted at your asset directory, and whether it inherits the application's twig.paths.
• Version compatibility traps. The bundle's composer.json is the source of truth. Look for twig/twig: ^1.x or ^2.x and old symfony/symfony constraints — Twig 3 removed several APIs, and Twig_Environment vs Twig\Environment namespace changes will break the filter class outright on modern stacks.
• Filter ordering is not optional. twig must run before minifiers; otherwise the minifier strips the whitespace inside {{ }} and the template becomes invalid. If output looks like literal {{ color }} in your compiled CSS, order is the first thing to check.
• Never feed user data into asset templates. These files are compiled at deploy time with whatever context you inject; treating them as a request-time rendering path is both a performance mistake and an injection surface.
• Debugging strategy. Isolate the filter from Assetic: instantiate the filter class directly in a small script or a test, pass a known Twig string plus a FilterCollection, and inspect the returned FilterCollection. If the filter works standalone, the problem is configuration or loader wiring, not template syntax.