Assetic Injector Bundle Laravel Package

Getting Started

This is a small Symfony 2/3-era bundle that sits on top of symfony/assetic-bundle. Its job is narrow: you declare named groups of JS/CSS files in YAML, then render a group in Twig instead of hand-writing <script>/<link> tags. Treat it as a registry + Twig helper, not a build tool — Assetic still does the dumping.

1. Install (pin your versions — the bundle has not been touched since 2017):

composer require troopers/assetic-injector-bundle
composer require symfony/assetic-bundle

You need symfony/assetic-bundle, assetic, and a Symfony version in the 2.8–3.x range. Do not attempt this on Symfony 4+ without a fork.

2. Register the bundles (order matters — Assetic first):

// app/AppKernel.php
$bundles = [
    // ...
    new Symfony\Bundle\AsseticBundle\AsseticBundle(),
    new Troopers\AsseticInjectorBundle\AsseticInjectorBundle(),
];

3. Declare an injector:

# app/config/config.yml
assetic_injector:
    injectors:
        global:
            javascripts:
                - '@AppBundle/Resources/public/js/vendor.js'
                - '@AppBundle/Resources/public/js/app.js'
            stylesheets:
                - '@AppBundle/Resources/public/css/app.css'

4. Render it once, in your base layout:

{# app/Resources/views/base.html.twig #}
<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    {{ assetic_injector('global') }}
</head>

5. Dump for production:

php app/console assetic:dump --env=prod

Where to look first in the source. Read DependencyInjection/Configuration.php before anything else — it is the authoritative list of config keys and defaults for the version you installed, and it is more reliable than blog posts or the README. Then Twig/ for the exact function name/signature and whether it returns markup (use |raw or not), then Resources/config/services.xml to see what is injectable and how the injector service is wired.

First real use case: a single global injector called from the base template, replacing a wall of hardcoded tags. That alone gives you one place to add a library site-wide.

Implementation Patterns

One injector per layout / page area, not one giant list. The bundle's value shows up when you split by context:

assetic_injector:
    injectors:
        global:
            stylesheets: ['@AppBundle/Resources/public/css/base.css']
        admin:
            stylesheets: ['@AppBundle/Resources/public/css/admin.css']
            javascripts: ['@AppBundle/Resources/public/js/admin.js']

Then admin.html.twig extends the base and adds only its own block — global assets are never duplicated.

Wrap the call in a Twig block so child templates can override or append rather than being stuck with the parent's set:

{% block stylesheets %}
    {{ assetic_injector('global') }}
{% endblock %}

Use it for the "third-party library added everywhere" problem. Analytics snippet, polyfill, icon font — add the file to the injector config once and every layout picks it up. This is the single most defensible reason to keep the bundle around.

Apply Assetic filters at the injector level so the bundle keeps ownership of the file list while Assetic does the work (cssrewrite, uglifyjs, compass). Keep the filter config in assetic: and the file lists in assetic_injector: — mixing the two makes it unclear which layer owns a given file.

Environment-split your config. Put the injector definitions in config.yml, then override in config_dev.yml — e.g. point the dev injector at unminified source files and skip the minifying filter. This is cheaper than conditional logic in templates.

Runtime injection for page-specific assets. If the version you have exposes the injector as a service, controllers/services can append a file to a named injector before the template renders (e.g. a widget that needs its own JS). Verify the service ID in services.xml first; if it isn't public, add a small compiler pass or a thin wrapper service rather than reaching into the container from Twig.

Migration path off it. Because all file lists live in one YAML file, migrating to Webpack Encore or plain asset() is mechanical: create one Twig template per injector that emits the tags, and replace {{ assetic_injector('global') }} with {% include '_assets/global.html.twig' %}. Doing this mapping up front makes the eventual removal a one-afternoon job instead of an archaeology project.

Gotchas and Tips

Assetic is abandoned; this bundle inherits that. No security fixes, no PHP 8 support, no Symfony 4+ DI compatibility. The 2017 last release means class-name string service IDs and possibly Definition\... APIs that are deprecated or removed. Budget for this being a "keep the lights on" dependency, not something you build new features against.

Production works locally and breaks after deploy — almost always assetic:dump. The Twig helper renders markup; it does not create files. If you forget the dump step in your deploy script, you get 404s on every injected asset while dev looks fine because dev serves through the Assetic controller. Add the dump to your release playbook before the cache warmup.

@Bundle notation needs an Assetic output. With cssrewrite, relative url() references inside CSS resolve against the dumped path, not the bundle path. If images break after dumping, add an explicit output: and run assetic:dump again — this is an Assetic quirk that surfaces through the injector, not a bug in the injector itself.

Ordering is config order, and there is no deduplication. Listing jquery.js in both global and admin renders it twice if both injectors are called on the same page. Keep a "loaded on this page" mental model, or centralize shared libraries in global only.

Config changes need cache:clear. Injectors are compiled into the container. Editing YAML and refreshing the browser in dev usually works, but stale-definition confusion after a branch switch is common — clear the cache before debugging anything else.

Escaping surprises. The helper returns HTML markup. Depending on the installed version it may or may not be marked safe; if you see literal <script> text on the page you need |raw, and if you don't need it, don't add it. Check the Twig extension's getFunctions() / is_safe declaration rather than guessing.

Debug mode changes the output shape. With assetic.use_controller / debug on, you get one tag per file; with it off, you get a single combined file. Don't compare dev and prod HTML and conclude something is broken.

No dependents and low stars (19). There is effectively no community to Google for error messages, and no one upstream to fix an incompatibility you hit. Read the source — it's small enough to hold in your head in an hour — and expect to vendor-patch or fork if you need it beyond Symfony 3. For new work, prefer Encore/Webpack or Symfony's native asset() + an entrypoints.json; keep this bundle only if you already have it running.