Twig Spreadsheet Bundle Laravel Package

Technical Evaluation

Architecture fit This is a Twig templating bridge for Laravel — it replaces (or coexists with) Blade by wiring Twig into Laravel's view factory, and it leans on Symfony components (Translation, HttpFoundation, Finder) plus Twig itself. That means its dependency graph is governed by two upstream release cadences (Laravel and Symfony), not one. Release 2.5 tightens the Symfony and Twig ends of that graph, so the package's supported envelope is now narrower than Laravel's own. For a TPM, the headline is: this package's compatibility matrix is now approximately "Laravel 11+ on PHP 8.2+, Symfony 7.4+/8.x, Twig 3.21+". Anything outside that needs an explicit exception.

Integration feasibility Constraint changes are all in composer.json and will surface at composer update time, which is good — failures are loud and pre-deploy. The realistic friction points:

• PHP 8.1 floor removal is the single most impactful line. Any service still on PHP 8.1 (typically Laravel 9/10 estates) cannot take 2.5 at all and is pinned to 2.4.x indefinitely.
• Symfony 6.4 is an LTS with support into late 2027; dropping it is a policy decision by the maintainer, not an upstream EOL forcing function. Teams that deliberately standardised on Symfony 6.4 LTS components for stability are now on an unsupported path.
• Twig 3.21 minimum can collide with transitive pins in packages that cap Twig below 3.21, producing unresolvable dependency graphs rather than clean errors.

Technical risk

• Medium-high for legacy estates: silent exposure if teams assume ^2.4 allows 2.5 — verify the constraint actually is ^2.4 and not ^2.5, because a caret on 2.x will pull 2.5 in and break PHP 8.1 CI.
• No deprecation runway: Symfony 6.4/7.0–7.3 and PHP 8.1 all disappear in one release. There is no 2.4.x → 2.5 transition period with warnings. That is the main governance concern.
• Low functional risk: the changelog contains no behavioural changes to rendering, extensions, or the view bridge — "improved internal code style" is cosmetic. Rendering output should be identical.
• Twig version risk is security-relevant: Twig has had sandbox-escape advisories; a higher floor is generally good, but confirm whether 3.21 is required for a security fix or merely for API convenience.

Key questions

1. Is 2.4.x receiving security backports, and for how long? Get this in writing before pinning.
2. Does 2.5 actually pass CI against the Laravel versions we run, or only against latest?
3. Which PHP 8.2+ features are now used — is this a floor bump or a rewrite that assumes 8.2 semantics?
4. Is the Twig 3.21 floor driven by a CVE?
5. Are there downstream packages (admin panels, CMS kits) that transitively depend on this and cap Twig/Symfony?

Integration Approach

Stack fit Confirm where this package sits in the render path — if it is the primary view engine for any customer-facing surface, treat it as tier-1; if it is used for a handful of mail templates or an admin module, tier-3. The upgrade effort is identical either way, but the blast radius and change-control requirements are not.

Migration path

1. Inventory: composer why twig/twig, composer why symfony/*, and composer depends <vendor>/<package> across every app and shared library.
2. Build a matrix of app → PHP version → Laravel version → Symfony component version → Twig version. Flag any cell that fails the new floor.
3. For apps on PHP 8.1: no upgrade path to 2.5 without a PHP runtime bump. Treat as a separate, larger project; pin to 2.4.* explicitly with a dated review.
4. For apps on PHP 8.2+ but Symfony 6.4: the Symfony component bump is usually a composer update of symfony/* plus a regression pass on translation and HTTP kernel behaviour, not a code change.
5. Run the full render-diff suite (or snapshot tests over rendered templates) — the changelog says no output change, so any diff is a red flag.

Compatibility Note the coupling explicitly: PHP 8.1 drop ≈ Laravel 10 and below; Symfony 6.4 drop ≈ Laravel 10 and below (Laravel 11 moved to Symfony 7). These two lines are largely the same cut, so the effective statement is "Laravel 11+ only". That is a defensible and probably intentional position — but it should be documented as such rather than inferred.

Sequencing Runtime (PHP) first, then Laravel, then Symfony components, then this package, then Twig. Do not bump this package and PHP in the same PR; you will not be able to attribute failures. Pin 2.4.* in every repo that is not yet through the PHP upgrade so a routine composer update on an unrelated branch cannot drag 2.5 in.

Operational Impact

Maintenance Small ongoing cost, but note the cadence: this package will now track Symfony major releases closely, which means an upgrade roughly every 12–24 months. Budget for it as recurring work, not a one-off. The absence of deprecation shims in 2.5 means future drops will likely also be hard cuts — plan on that assumption.

Support The critical unknown is the 2.4.x support window. If 2.4.x stops receiving fixes when 2.5 ships, any team stuck on PHP 8.1 is on an unpatched templating layer, which is a security-relevant position given Twig's history of sandbox advisories. Escalate this as a decision, not a backlog item.

Scaling No scaling implications — this is a compile-time/rendering-path dependency with no runtime services, queues, or state. Twig's compiled-template cache behaves the same across these versions.

Failure modes

• Silent constraint drift: ^2.4 resolving to 2.5 on a PHP 8.1 runner — fails at install, but only when someone runs composer update.
• Dependency deadlock: a transitive package capping Twig < 3.21 makes the graph unsolvable; symptom is a confusing Composer conflict, not a clear "upgrade Twig" message.
• Translation/HTTP regressions: Symfony component jumps are usually inert but occasionally change locale fallback or request handling subtly — the template-diff suite will not catch this; add a smoke test on localisation.
• No runtime failure mode: nothing here changes behaviour at request time, so partial rollout (per-service) is safe.

Ramp-up Low. An engineer familiar with Composer and Laravel's view layer can execute this in a day per application, assuming PHP 8.2 is already in place. The real cost sits in the PHP runtime upgrade for any lagging service, which is infrastructure work and should be estimated separately — do not let it hide inside a "minor dependency bump" ticket.