Twig Extensions Laravel Package

Technical Evaluation

Architecture fit. This package operates at the Twig layer, not the Laravel layer. Laravel's first-class view engine is Blade; Twig is only reachable through a community bridge (rcrowe/twigbridge and its forks), which has historically lagged Laravel majors. Stinger Soft is a Symfony-oriented shop, so the artifact is likely shaped as a Symfony Extension plus Bundle — the Bundle has no meaning in Laravel, and package discovery will not wire it. The realistic integration is "instantiate the extension classes and register them on the Twig\Environment that the bridge builds," which is manual glue, not a supported integration. That is acceptable for a small, well-audited extension; it is not acceptable for something you expect to Just Work.

Integration feasibility. Feasible with effort. Two paths: (a) adopt twigbridge, publish its config, and add the extension classes to the extensions array; (b) skip the bridge and construct a Twig environment directly for a narrow rendering surface (e.g., email/PDF templates). Path (b) is lower risk if you only need Twig for one subsystem. Both require the package to be autoloadable under the target PHP version and Twig major, and require verifying whether the package ships a Laravel ServiceProvider or only a Symfony Bundle. With zero dependents, there are no reference integrations to copy, so this is discovery work, not configuration work.

Technical risk.

• Twig version drift / duplication. Twig 3 absorbed most of the old twig/extensions filters (filter, map, reduce, find, split, sort, etc.). A package of "common filters, functions and tests" may largely duplicate core, and duplicate registration is a hard failure — Twig throws on conflicting filter names at environment boot, which surfaces as a 500 on every request, not a warning.
• XSS surface. Custom filters that declare is_safe => html or wrap raw are injection points. This needs line-by-line review before anything reaches a template rendering user input.
• Vetting gap. Zero stars, zero dependents, no CVE watch, unknown CI. Apache-2.0 is fine (permissive, patent grant, compatible with proprietary Laravel apps; retain NOTICE), but the license is the only institutional signal here.
• Maintenance posture. Assume unmaintained until proven otherwise; check commit recency, open issues, and whether the last release tracks Twig 3.

Key questions.

1. Does it ship a Laravel ServiceProvider/composer.json extra.laravel, or only a Symfony Bundle?
2. What Twig constraint does it declare, and does it actually run on Twig 3.x?
3. Which filters/functions/tests does it provide that Twig 3 core does not already provide?
4. Which extensions are marked is_safe, and do any accept user-controlled input?
5. Is there CI and test coverage, and when was the last release?
6. Is it a fork of the deprecated twig/extensions, and if so, at what upstream commit?
7. Is Twig itself a strategic choice for this product, or are we importing a templating language to get three filters?

Integration Approach

Stack fit. Target is PHP 8.x / Laravel 10–11 / Twig 3.x via twigbridge. Verify the bridge's Laravel support before anything else — this is the actual gate, not this package. If the bridge does not support the target Laravel major, the package is moot. If you are not already committed to Twig, the cheaper path is to port the handful of filters you need into Blade directives or a small helpers.php; that removes both the bridge and this dependency.

Migration path. Treat this as greenfield and scope it as a vertical slice, not a platform change. Do not convert existing Blade views. Pick one rendering surface (transactional email, PDF generation, or a single admin module), prove Twig + bridge + extension there, and stop. A second templating language is a permanent cognitive tax on the team; it needs a stronger justification than "these filters are handy."

Compatibility.

• Pin twig/twig:^3.x and read the package's composer.json constraints directly; run composer why-not twig/twig <version> to see the real conflict.
• Run PHPStan against the vendor code and add a rendering smoke test that exercises every filter/function/test the package exposes — not just autoload.
• Check for name collisions with core Twig before wiring anything.

Sequencing.

1. Inventory the specific filters/functions/tests you actually need (expect 2–4, not the whole set).
2. Diff that inventory against Twig 3 core and against Symfony's maintained extensions; eliminate anything already covered.
3. Confirm twigbridge supports the target Laravel; if not, stop.
4. Spike on a branch: register the extension classes manually on the Twig environment; render one real template.
5. Security review of is_safe and any input-facing filter.
6. Decide: fork under the org (preferred if adopting) vs. reimplement 2–3 filters in-house (preferred overall) vs. depend on upstream (not recommended given zero dependents).
7. If forking: add CI, pin Twig major, add a NOTICE, and document the patch policy.

Recommendation. Do not take this as a runtime dependency. Either reimplement the specific filters internally, or fork and own them. The package is small enough that its value is in the code, not in the release stream — and there is no release stream to speak of.

Operational Impact

Maintenance. Effectively you own it from day one. Upstream has no dependents and near-zero community signal, so plan for a fork with a documented patch policy and an owner. The recurring cost is Twig major upgrades (Twig 4 will land eventually) and the associated re-validation of every custom filter's behavior and safety flags.

Support. No vendor, no SLA, no CVE feed. Internal escalation only. Bus factor is one unless the fork is documented and reviewed by a second engineer. Budget a named owner for the Twig bridge and the extension fork together — they fail as a unit.

Scaling. Rendering throughput is not the concern; custom filters are cheap. The real scaling cost is the compiled-template cache: Twig writes to its own cache directory while Laravel writes to storage/framework/views, so you now have two cache lifecycles, two warm-up paths, and a multi-node invalidation problem on deploy. Standardize the Twig cache path on shared storage or a warm-on-deploy step, or you will get stale-template incidents that look like random 500s.

Failure modes.

• Boot-time fatal: duplicate filter/function names against Twig 3 core → Twig throws during environment construction → every request 500s. Highest-probability failure.
• Silent output drift: upstream filter behavior changes across a Twig minor; output is wrong but not fatal. Caught only by golden-file rendering tests.
• XSS: an is_safe => html filter applied to user data. This is the one that becomes a security incident.
• Bridge breakage: twigbridge falls behind a Laravel upgrade and blocks the platform upgrade — a scheduling risk, not a runtime one.
• Autoload/ServiceProvider collision from Symfony-shaped bundle wiring in a Laravel container.

Ramp-up. A developer fluent in Twig needs half a day to wire the bridge and register the extension; a Blade-only team needs one to two days to become productive in Twig, plus ongoing context-switching cost across two template languages. That cognitive tax is the strongest argument against adoption and should be weighed explicitly against the handful of filters actually gained.