Twig Extensions Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy for a trivial capability. The real decision this package surfaces is not "which library," but "do we take an external dependency for a one-line parse_url() template helper, or do we own ~20 lines of code?" For nearly every team the answer is own it — the package's entire value is saving an engineer an afternoon, weighed against indefinite license and maintenance exposure.
• Dependency-adoption governance. With 0 stars, 0 dependents, and a NOASSERTION license, this is a clean worked example for defining org-wide adoption gates: SPDX-cleared license, evidence of maintenance, version-constraint compatibility, and usage/adoption signal. Use it to calibrate the bar for all micro-dependencies, not just this one.
• Templating strategy. It tests whether the product actually needs URL parsing inside templates (display a clean host, branch internal vs. external links, populate canonical/OG tags) — or whether that logic belongs in the controller/service layer and should arrive at the view precomputed. The right answer reshapes where view-modeling work sits on the roadmap.
• Stack-fit scoping. The package is a Symfony bundle, not a Laravel package; Laravel's default view layer is Blade, and Twig only appears if a bridge is already installed. This informs platform-standardization decisions (one templating engine, one helpers package) rather than a per-feature dependency choice.
• Shared Twig/Blade helper initiative. If several products need URL/query manipulation in views, this package is evidence the need exists — but too small and too unmaintained to anchor a roadmap item. Treat it as a prompt for an internal "common view helpers" package that the team versions, tests, and secures under its own policy.
• Risk register / SBOM hygiene. Adding a NOASSERTION-licensed dependency to a Laravel codebase that doesn't even run Twig creates audit surface with zero compensating value — a concrete input to supply-chain policy and security-review criteria.

When to Consider This Package

Consider it only as a reference, not a dependency. The code is small enough to read in minutes; the honest use is to look at how parse_url() is exposed as a Twig filter and then implement that yourself. Adoption as a runtime dependency is defensible only when all of the following hold:

• You are on a Symfony + Twig stack (not Laravel/Blade) where bundle registration is the native wiring path.
• Legal has explicitly cleared the NOASSERTION license — this is a hard gate for anything distributed or commercial; unresolved, it is a blocker.
• The need is genuinely limited to URL parsing in templates and there is no existing internal helper bundle to extend.
• You accept full ownership on day one: no upstream support, no CVE response, no fix cadence — and you have a fork/vendor plan if the repo stays dormant.
• You have verified PHP/Symfony/Twig version compatibility (Twig 1/2/3 extension signatures differ; compatibility is unverified from the metadata).

Look elsewhere — or build in-house — when:

• You're on Laravel/Blade. No fit. If Twig isn't already in the stack, do not introduce a Twig bridge to justify a parse_url wrapper. A Blade directive, view composer, or controller-precomputed value delivers the same result with zero external risk.
• You need more than one or two filters. Adopt a maintained, broadly used Twig extension suite or standardize on an internal bundle.
• License clarity is non-negotiable and cannot be resolved — NOASSERTION fails distribution and commercial redistribution review.
• You require active maintenance, security responsiveness, or SLAs — 0 stars and 0 dependents means no community backstop and no signal of production use.
• The capability is needed in exactly one template — a one-off helper or precomputed variable beats a new dependency.

How to Pitch It (Stakeholders)

For executives: This is a tiny open-source utility that exposes one Twig template helper for parsing URLs. It is free, but it has effectively zero adoption (0 stars, 0 dependents) and its license could not be automatically identified — a legal red flag for shipping in a product. It is also built for Symfony, not our Laravel stack, so it wouldn't work out of the box anyway. Recommendation: do not add it as a production dependency. The capability is trivial to reproduce internally — roughly a day of engineering — which removes the legal ambiguity and the long-term maintenance risk at essentially no cost. The decision to make is a governance one: agree on adoption gates (clear license, some evidence of use, version compatibility) so micro-dependencies don't slip in elsewhere.

For engineering: The package is a Symfony bundle that registers a single Twig extension exposing parse_url(). On Laravel/Blade there is no supported path — Twig only enters the picture via a third-party bridge we don't run, and the bundle wrapper (Symfony kernel + DI concept) is dead weight regardless. The reusable part is one framework-agnostic extension class. Plan: if a product needs URL parsing in views, either precompute it in the controller/service layer, or write a small first-party helper (Blade directive or a native Twig extension registered through our view layer) with tests for valid, relative, and malformed URLs. If we choose to reuse upstream code, copy the class with attribution into our own namespace under our license header, pin it, and document ownership — no Composer dependency, no upstream support expectation, no SBOM exposure. Close the ticket outright if Twig isn't already in the target app.