Lcn Include Assets Bundle Laravel Package

Technical Evaluation

Architecture fit — poor / mismatched platform. Despite being filed under a Laravel/PHP package, locaine/lcn-include-assets-bundle is a Symfony 2 bundle, not a Laravel package. It depends on Symfony's Bundle base class, AppKernel registration, the DI container, and Symfony 2's templating helpers. Laravel's architecture (service providers, facades, Blade @push/@stack, Vite/Mix pipeline) has no interception point for this package. The concept it implements — Symfony 1-style use_javascript() / use_stylesheet() calls that register assets from anywhere in the view layer and emit them in the layout — maps cleanly to Blade stacks, but the code does not port.

Integration feasibility — effectively zero as-is. Composer install into a Laravel app will not autoload usable classes; installation into a modern Symfony app fails on framework constraints. Realistic options are (a) a ground-up reimplementation of the ~200-line concept in Laravel in under a day, or (b) using an existing maintained asset helper, or (c) if a genuine Symfony 2 legacy app is in scope, vendoring the bundle with pinned versions.

Technical risk — high.

• Symfony 2 is end-of-life; PHP constraints are almost certainly 5.3–5.6 era, blocking installation on any supported PHP runtime.
• PSR-0 autoloading, Twig 1.x coupling, and AppKernel registration are all dead patterns.
• Single star, zero dependents, no demonstrated production usage — the package is functionally abandoned with a bus factor of one.
• No indication of security handling for a component that emits markup into every page.

Key questions for the requester:

1. What problem are we actually solving — asset inclusion ergonomics, ordering guarantees, or deduplication? Each has a better native answer in Laravel.
2. Is there a live Symfony 2 application, or did this package surface from a stale dependency audit?
3. Who owns the requirement, and is there an approved decision to run EOL framework code?
4. Would a 100-line Blade/service-provider equivalent satisfy the need with zero third-party risk?

Integration Approach

Stack fit — none for Laravel. No service provider, no Blade integration, no Laravel-compatible namespace. Treat any "Laravel integration" plan as a reimplementation project, not an adoption project.

Migration path.

• Target: Laravel. Do not migrate the package. Implement the behavior natively: a small service provider registering an AssetRegistry singleton, Blade @push('scripts')/@push('styles') in views, and @stack in the layout. This delivers identical semantics (register anywhere, render once in order) with framework-native lifecycle and no dependency.
• Target: Symfony 2 legacy. Only viable path — vendor the bundle, pin every transitive dependency, freeze the lockfile, and isolate it behind an internal adapter so it can be swapped later. Do not add new call sites.
• Target: modern Symfony. Rewrite against the current AssetMapper/Webpack Encore component; the bundle's API surface is not worth preserving.

Compatibility matrix to verify before any decision: PHP version ceiling, Symfony 2.x minor range, Twig major version, autoload standard. Any single mismatch is disqualifying.

Sequencing.

1. Confirm the underlying requirement and the actual target framework.
2. Spike (≤1 day) proving the native equivalent in the real codebase.
3. Run the native implementation against the legacy bundle's output for a sample of pages to confirm ordering and dedup parity.
4. Retire the bundle reference; document the replacement in the architecture decision record.

Operational Impact

Maintenance — unsustainable. No releases, no maintainer activity, one star, zero dependents. Every future PHP or framework upgrade becomes a manual patch exercise. The long-run cost of ownership exceeds the cost of the replacement by an order of magnitude.

Support — none. No vendor, no active issue tracker, no documentation beyond the README. Any incident is debugged cold, from source, by whoever is on call.

Scaling — negligible either way. The component only emits <script>/<link> tags into rendered HTML; it has no runtime scaling characteristics. Note it provides no bundling, minification, cache-busting, or CDN support — if asset delivery performance is the actual goal, this package is the wrong tool entirely and Vite is the answer.

Failure modes to watch.

• Silent ordering drift — assets emitted in registration order; a refactor changes include order and breaks dependent scripts with no error.
• Duplicate includes — deduplication behavior is fragile and undocumented; repeated use_* calls may double-emit and cause re-execution bugs.
• Fatal on version skew — PHP/Symfony constraint violations surface as install failures or runtime fatals, usually during deploy.
• Lockfile contamination — pinning EOL dependencies can block unrelated security upgrades across the whole application.
• Output-cache staleness — if rendered HTML is cached, asset registrations from unwarmed code paths never reach the page.

Ramp-up — deceptively low, actually high. The API is trivial to learn (use_javascript, use_stylesheet), which makes it easy for a team to adopt casually and hard to notice the EOL risk underneath. The real ramp-up cost is the vetting, pinning, and eventual replacement work — all of which is avoidable.

TPM recommendation: Do not adopt. Close the request against a native Laravel asset-registration implementation (or Symfony AssetMapper if the target is Symfony), and record this package as a rejected candidate with the framework-mismatch and EOL rationale.