sanpi/assetic
Laravel integration for the Assetic asset management library. Define CSS/JS asset collections, apply filters such as LESS, Sass, CoffeeScript and minification, then dump and serve compiled, cached assets via Blade helpers for a simple PHP asset pipeline.
Architecture fit. From a TPM's perspective, the first thing to establish is that this package is a library, not a Laravel package. It has no service provider, no facade, no config publishing, no Blade directives, no @vite-equivalent, and no manifest contract compatible with Laravel's asset() helper. That means every integration point is bespoke glue owned by our team. Laravel's sanctioned asset path is Vite (laravel-vite-plugin + @vite), with Laravel Mix as the legacy fallback. sanpi/assetic sits outside both. The architecture fit is therefore explicitly off the supported path — a decision a TPM must escalate to architecture rather than absorb as routine scope.
Integration feasibility. Mechanically installable via Composer, but the fork targets the Symfony ecosystem and pulls symfony/process and symfony/filesystem, which collide with the Symfony components Laravel 10/11 already pin. The realistic integration cost is "write a service provider, build a manifest adapter, wrap the dump step, and own the binary dependencies for every filter we touch." That is not a library adoption; it is a small internal project with a permanent maintenance tail. Zero stars, zero dependents, and no downstream validation mean we cannot borrow confidence from anyone else's production experience.
Technical risk. High, and concentrated in three places a TPM should flag on the risk register: (1) upstream Assetic is end-of-life, so this fork is a patch over an abandoned base; (2) single-maintainer bus factor with no security advisory channel; (3) filters shell out to external binaries (sass, lessc, uglify-js) that have drifted and in several cases are deprecated. PHP 8.x compatibility is unverified in the wild. The compounding effect is that a PHP minor bump, a Symfony component bump, or a base image change on the CI runner can break the build with no upstream fix path.
Key questions.
composer.json resolve cleanly against our pinned Symfony components, or will adopting it force a downgrade elsewhere in the stack?Stack fit. Poor for any greenfield or actively developed Laravel service. If the requirement is "combine, minify, compile CSS/JS," Vite already satisfies it with hashed manifests, tree-shaking, HMR, and first-party Laravel support at lower total cost. sanpi/assetic only earns a slot as a compatibility shim when we are porting a pre-existing Assetic configuration and the alternative is blocking a release.
Migration path (only if adoption is forced). Pin the exact fork version or commit in composer.json. Write an AsseticServiceProvider that registers collections from config. Run the Assetic dump step in CI, never at request time, emitting content-hashed files into public/build/. Publish a generated manifest and expose a single thin helper/Blade directive that maps logical names to hashed outputs. The manifest is the contract: the application runtime must never instantiate Assetic classes. If Composer constraints cannot be reconciled against Laravel's Symfony pins, isolate Assetic in a dedicated build container and ship only compiled artifacts into the app — this is the safer containment pattern and should be the default framing in the design doc.
Compatibility. Primary hazard is Composer conflict against Symfony 6/7. Secondary is filter binary drift on the CI OS (node-sass removal, uglify-js deprecation). Verify both in a spike before committing to a plan, and record the result as a go/no-go gate rather than a discovery during implementation.
Sequencing. (1) Spike: prove composer install on target PHP/Laravel versions with zero conflicts; timebox it. (2) Enumerate required filters and validate their binaries in CI. (3) Implement the build-time dump and manifest generation. (4) Wire Blade to the manifest with cache busting. (5) Set a dated deprecation checkpoint and fund the Vite migration. For a greenfield project, skip straight to step 5 — that is the TPM's fastest value-add here.
Maintenance. High burden, low leverage. Every PHP minor and Symfony component bump is a potential source-level patch. Security patching of transitive dependencies becomes our responsibility with no upstream advisory channel to monitor. This is the kind of dependency that quietly consumes a percentage of an engineer every cycle.
Support. No vendor, no active community, no roadmap, no issue-triage signal. Internal knowledge will consolidate in whichever engineer wires it up, creating a second bus factor on top of the maintainer's. If adopted, assign a named owner and budget explicit runbook documentation.
Scaling. Build-time compilation with content-hashed output and CDN caching scales fine. Runtime filtering does not — it couples request latency to disk I/O and external binary execution and degrades under concurrency. Over-bundling also hurts cache granularity (a one-character change invalidates the whole bundle), so bundle boundaries need deliberate design, which is again a TPM-visible cost.
Failure modes. Composer resolution failure against modern Symfony components (most probable). Missing or upgraded-away filter binaries breaking the build. PHP-version incompatibility inside filter classes. Silent stale assets when the dump is skipped or the manifest drifts from disk — a nasty class of bug because it ships wrong content without erroring. Maintainer abandonment mid-cycle with no security response path.
Ramp-up. Assetic's model (collections, filters, formulas, dumpers, workers) is non-obvious and documented mainly through legacy Symfony material. Expect one to two weeks before a mid-level engineer is productive — a poor return compared to Vite, which most Laravel developers already know.
TPM recommendation. Treat this as a time-boxed unblocker for legacy systems only, not a platform capability. Do not adopt it for a Laravel codebase where Vite or Mix is viable. If an existing Assetic dependency is unavoidable, contain it strictly to the build pipeline behind a manifest contract, isolate it in a dedicated build container if Composer conflicts appear, assign an owner, and fund migration to Vite on a fixed, dated timeline. Communicate to executives as a maintenance patch with a scheduled exit — not a strategic choice — and to engineering as a pinned, isolated dependency with an explicit prohibition on new Assetic-based work.
How can I help you explore Laravel packages today?