Lcn Include Assets Bundle Laravel Package

Product Decisions This Supports

• Asset-delivery strategy for legacy PHP apps — specifically whether to replicate Symfony 1's use_javascript() / use_stylesheet() ergonomics inside a Symfony 2 codebase, so templates declare their own CSS/JS instead of relying on a global layout.
• Build vs. buy (leans hard to "build") — the whole feature is an ordered asset registry plus a couple of Twig helpers, on the order of a hundred lines. Taking a dependency on a 1-star, zero-dependent, dormant repository is the worse half of that trade.
• Roadmap triage — this is a stopgap for teams stuck on Symfony 2, not a platform bet. Its existence is a useful prompt: "what is our Symfony 2 exit date, and does this patch shorten or lengthen it?"
• Developer-experience bets for Symfony 1 migrations — real but narrow: reducing template churn when porting a large Symfony 1 app that leaned on per-template includes.
• Explicitly not supported: any Laravel project. This is a Symfony bundle (note the *Bundle suffix and framework-specific registration), not a Laravel package — it will not install or run there. Laravel's equivalents are laravel-vite-plugin / the @vite directive, or Laravel Mix on older apps.
• Not supported either: CSP nonces, subresource integrity, cache-busting/versioning, bundling, minification, or a module graph. If any of those are on the roadmap, this package is off the table.

When to Consider This Package

Adopt only if all of the following hold:

• You are maintaining a Symfony 2.x application (end-of-life since late 2018) that you cannot migrate this quarter.
• You have developers with Symfony 1 muscle memory and a genuinely large number of templates using per-template asset inclusion — enough that a mechanical port saves real hours.
• You are willing to vendor or fork the code and own it. Upstream is effectively dormant: 1 star, 0 dependents, no release cadence, and a health score in the noise (0.005). Treat the repo as reference code, not a library.

Look elsewhere when:

• Framework is Laravel — use Vite via laravel-vite-plugin, or Mix on legacy apps. Framework mismatch is disqualifying.
• Framework is Symfony 3/4/5/6/7 — use Webpack Encore, Symfony AssetMapper, or a Vite bundle. Native, maintained, and covers everything this does plus versioning and integrity.
• You need security responsiveness, vendor support, or an active maintainer — none are available here.
• You're greenfield — this solves a 2011 problem with 2011 tooling.

How to Pitch It (Stakeholders)

One-liner: a small community bundle that brings Symfony 1's per-template CSS/JS include helpers to Symfony 2.

For executives: negligible cost, negligible upside. It's an unmaintained, single-star bundle tied to an end-of-life framework. Don't put it on a roadmap. If a team wants it, treat it as a tactical patch inside a legacy app — not a strategic dependency — and route the conversation to the real decision it surfaces: when do we fund the Symfony 2 exit? Spending here should be capped and time-boxed.

For engineering: the feature surface is tiny — an ordered asset registry plus Twig helpers. Fork or reimplement rather than depend, and treat the upstream repo as a readable spec. Also correct the framing early: this is Symfony-only; Laravel teams should already be on Vite or Mix. If someone proposes this for a new build, that's a signal the asset strategy conversation hasn't happened yet — have it before writing code.