Resource Bundle Laravel Package

Getting Started

Read the code, not the README. The README is a single H1 — there is no install snippet, no config reference, no API docs. Treat the repository itself as the documentation and open these in order:

1. composer.json — the require block tells you which enhavo/* bundles and Symfony version this release is pinned to. That is your real compatibility matrix.
2. DependencyInjection/Configuration.php — the bundle's entire public configuration surface lives here. Every enhavo_resource: key, default, and required node is defined in this one file.
3. DependencyInjection/*Extension.php and Resources/config/*.xml (or .yaml) — shows which services are registered, their IDs, and what is public vs. private.
4. Resources/views/ — Twig helpers live here. If the bundle exposes rendering functions, their names and argument order are the actual API.
5. Tests/ — if present, the fixtures are the only working examples of config + usage you will get.

Framework mismatch warning. This is a Symfony bundle (Enhavo\Bundle\ResourceBundle\...), not a Laravel package. There is no ServiceProvider, no config/resource.php, no facades. If your application is Laravel, this is not a drop-in: you would be porting the resource-manager logic, not installing it.

Installation (Symfony). Enhavo is typically consumed as a full stack, not bundle-by-bundle, and this bundle is near-certainly version-locked to enhavo/app-bundle and enhavo/asset-bundle. Prefer:

"require": {
    "enhavo/resource-bundle": "dev-master"
}

and if you must add it to an existing app, require the matching Enhavo minor version rather than an unpinned dev-master. Then register it:

// config/bundles.php
return [
    Enhavo\Bundle\ResourceBundle\EnhavoResourceBundle::class => ['all' => true],
];

First use case. The bundle's job is to declare named resource collections (asset sets: stylesheets, javascripts, images) in configuration and resolve/render them from your templates and controllers. Start by declaring one collection, dumping the config to confirm the shape, then rendering it in a template — not by wiring it into a build pipeline.

bin/console config:dump-reference enhavo_resource
bin/console debug:config enhavo_resource

Those two commands are worth more than any missing README.

Implementation Patterns

Config-declared collections, code-consumed. The idiomatic Enhavo pattern is: resources are declared in YAML, and PHP/Twig only references them by name. Do not hardcode file paths in controllers. Keep the declaration in config/packages/enhavo_resource.yaml and let the manager resolve paths, ordering, and (potentially) minification.

Service injection over static access. Locate the bundle's manager service in Resources/config/ and inject it by interface where possible. Look for a ResourceManager-style class with methods like get, add, all, or render. Because the bundle registers private services by default, you will often need to either inject them or add an alias in your app config — check debug:container --show-private before assuming a service ID is usable from your code.

Twig as the primary integration point. Enhavo bundles consistently expose template helpers registered through a Twig extension class. Grep the bundle for TwigFunction to find them:

grep -rn "TwigFunction\|TwigFilter" vendor/enhavo/resource-bundle

That gives you the actual function names and their is_safe flags. Use those in your base layout instead of hand-writing <link> and <script> tags, otherwise you lose ordering and deduplication guarantees.

Ordering and dependency between collections. If the bundle supports a requires/depends key in config, express script dependencies there rather than by array position. Positional ordering is the most common source of "works in dev, broken bundle order in prod" bugs.

Pair with the asset stack explicitly. Resource declaration and asset compilation are separate concerns in Enhavo (ResourceBundle vs. AssetBundle/WebpackEncoreBundle). Decide early which layer owns the <script> tag emission. Mixing both leads to duplicate includes; a useful rule is: ResourceBundle owns which files and in what order, the asset stack owns the compiled URL.

If you are porting to Laravel. The logic is small enough to lift: bind the manager as a singleton in a service provider, move the config array into config/resource.php, and replace the Twig extension with a Blade directive (@resourceJs('app')). Keep the manager framework-agnostic so the port stays a day, not a sprint.

Gotchas and Tips

Zero stars, zero dependents, stub README. There is no community, no issue history to mine, and no third party who has hit your bug before. Consequences: pin to an exact commit or tag in composer.json, vendor the source if you cannot rely on Packagist availability, and expect semver to be advisory. Budget for reading every line you depend on.

Version lock with the Enhavo ecosystem. Enhavo bundles are released in lockstep and reference each other by tight constraints. Upgrading this one alone will almost certainly break app-bundle or theme-bundle. Upgrade the whole enhavo/* set together and run composer why-not enhavo/resource-bundle before debugging anything else.

Configuration node names drift between minor versions. Because the config is only documented in Configuration.php, copy-pasting a YAML example from a blog post or from a different Enhavo minor will silently no-op (Symfony ignores unknown keys in some setups) or throw only at cache warmup. Always verify against config:dump-reference on your installed version.

Cache is the answer to most "my config change did nothing" reports. Resource resolution is typically cached in the container or in a compiled array. bin/console cache:clear in dev, and confirm the prod cache is rebuilt on deploy — a stale resource cache after a deploy is the classic symptom of "new scripts missing in production only."

Symfony 4/5-era service definitions. If the bundle ships XML service configs and you are on a modern Symfony, private services and autowiring may not line up. Symptom: Cannot autowire service ... or "service not found" for an ID you saw in the bundle. Fix via an explicit alias in config/services.yaml rather than making the bundle's service public.

Debugging checklist. In order: debug:config enhavo_resource → debug:container | grep -i resource → debug:router if resources register routes → check var/log/dev.log for the resolution path → step through the manager with dump() in a Twig extension. The bundle is small; a debugger session over the manager class will explain more than any amount of config guessing.

Extension points to look for. Three places usually exist and are worth grepping for early: a compiler pass (for programmatic collection registration), a tagged-service convention (to add custom resource types or resolvers), and an event dispatched around render/compile. If a tagged-service pattern exists, prefer it over editing vendor config — it survives upgrades. If none exists, keep your customizations in a thin wrapper service in your own bundle, never in vendor/.

Testing posture. With no upstream test signal and no dependents, write a smoke test that asserts your configured collections resolve to real, existing files and that the rendered template contains the expected tags. That single test will catch the majority of breakage on upgrade, which is the main risk this package carries.