Twital Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. skip: Still not a purchase decision (MIT, free), but an adoption bet: do we add a TAL-style attribute layer on top of Twig, or keep templates in plain Twig? This package remains the cheapest way to evaluate that question on Symfony — but only on legacy Symfony.
• Design-to-engineering handoff roadmap: The core value is unchanged — templates remain valid HTML, so tal:repeat / tal:condition attributes render harmlessly in a browser and in visual editors. Designers can open, preview, and edit templates without a running app. That supports any roadmap item about reducing design/dev round-trips, agency/client-editable markup, or WYSIWYG handoff.
• Use-case fit: Strong for marketing/CMS front-ends with heavy design iteration, XHTML/XML output (email, feeds), and legacy TAL/Zope/PHPTAL migrations. Weak for API-first or SPA products.
• Platform standardization: Unchanged and still decisive — this is a Symfony bundle, not a Laravel package. Twital compiles to Twig; Blade is not Twig.
• Framework-version ceiling (updated by 1.6.0): 1.6.0 is a compatibility-only release adding Symfony 3, 4, and 5. It ships no features, no API changes, and no deprecations, so existing adopters can take it as a safe minor bump with zero migration cost. But it also caps support at Symfony 5, which is already end-of-life; Symfony 6.4/7.x are the current LTS lines. Practically: the package cannot be adopted on a modern Symfony application without a fork or a library-level integration. The release widens legacy support rather than reaching current supported framework versions.
• Maintenance signal: A release did land (good — not abandoned), but it is a narrow compatibility patch from a single contributor, confirming a bus factor of roughly one and a reactive, legacy-oriented maintenance posture. Treat this as "alive, not forward-looking."
• Vendor/abandonment risk register: Still ~20 stars, negligible dependents, single maintainer. Any dependency needs a documented exit path — goetas/twital is separable, and output is compiled Twig, so extraction remains feasible.

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony 3, 4, or 5 (1.6.0 defines exactly this range; do not assume it on 6/7), templating through Twig.
• A real workflow depends on designers or clients editing template files directly in HTML tools, or on templates that must render standalone in a browser.
• You are migrating from a TAL-family engine and want to preserve template semantics during transition rather than rewriting everything at once.
• You can absorb the ecosystem cost: no meaningful Q&A corpus, no third-party tutorials, error surfaces routed through a compile step, and IDE support far behind Twig's.

Look elsewhere when:

• You are on Laravel/Blade — a non-starter without building Twig-in-Laravel glue, a multi-week project with no product payoff.
• You are on Symfony 6 or 7 — 1.6.0 does not cover it. The realistic fallback is integrating goetas/twital directly, which is a real engineering line item, not a drop-in.
• Your UI is component-driven (Livewire, Inertia, Twig Components, Vue/React) — Twital solves a document-template problem, not component composition.
• Templating is not a bottleneck. If design handoff already works, this adds a dependency and a compile concept for zero marginal value.
• You need support guarantees — no commercial backing, no SLA, bus factor of one.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed Symfony add-on that lets designers work in real HTML tools while engineers keep Twig, potentially cutting design-to-dev rework on content-heavy pages. License cost is zero; adoption cost is not. The new 1.6.0 release is a compatibility patch only — it extends support to Symfony 3/4/5 and adds nothing else. That is the important read: the newest framework it supports is already end-of-life, it has a tiny community and a single maintainer, and it is Symfony-only. Recommendation: do not adopt. Our stack is Laravel/Blade, so it would require custom glue with no product upside. Log it as a known option only if a legacy Symfony or TAL-migration project lands on the roadmap.

To engineering: 1.6.0 is low-risk for anyone already using it — a version-range bump, no API or behavior changes. For everyone else it clarifies the ceiling: Symfony 3/4/5, nothing newer. Twital compiles TAL attributes to Twig at compile time, so runtime performance is effectively Twig's; the cost is a compile step and indirect stack traces. The bundle is thin Symfony wiring around goetas/twital, so if we ever need this capability we would integrate the library directly and manage framework compatibility ourselves. Given Blade incompatibility and the Symfony 5 ceiling, the pragmatic move is a timeboxed spike only if a Symfony 3/4/5 project with a design-heavy template workflow appears — otherwise decline and revisit at the next framework decision.