Smartwig Laravel Package

Product Decisions This Supports

• Template-layer component strategy. Smartwig represents one architectural bet: UI primitives (forms, grids, panels, buttons, icons) expressed as declarative tags inside the template rather than as view classes, partials, or client-side components. That bet is a real fork in the road for any PHP product, and this package is a compact reference implementation of the "tag DSL in the template" side of it.
• Build vs. buy for an internal component layer. If we are considering an in-house form/grid rendering package, Smartwig shows the minimum viable shape: a Twig extension plus tag/node parsers delegating to a PHP-side markup builder. That informs effort estimates for building a ~200–400 line internal equivalent we control, versus adopting something off the shelf.
• Legacy modernization roadmap. Relevant only if we inherit or acquire a Twig-based PHP application (Symfony, Slim, or Laravel 4-era with a Twig bridge). In that case the decision it supports is "replace at the next UI cycle, do not extend" — not "adopt."
• No roadmap impact for a Blade-based Laravel product. Laravel ships Blade; Twig arrives only via a bridge package. For our primary stack this package is effectively out of scope, and treating it as a candidate would be a category error.
• Dependency-bar calibration. With 6 stars, 0 dependents, no vendor backing, and an MIT license (forkable, but nobody obligated to fix anything), it is a clean worked example of what fails our third-party UI dependency threshold. Useful when socializing that threshold internally.
• Plausible use cases if we ever did use it: internal admin/CRUD scaffolding in an old Twig app, rapid prototyping of form markup, or as a pattern reference when designing our own tag-based component layer.

When to Consider This Package

Consider it only when all of the following hold:

• The stack is genuinely Twig-based (Symfony, Slim + Twig, or Laravel with a Twig bridge) and Blade components, Symfony UX Twig Components, or plain Twig macros/includes are not viable for the specific screen.
• The PHP runtime matches the package's era — verify composer.json constraints first; a package of this vintage is likely to fail or warn on PHP 8.x, which alone can be disqualifying.
• The work is internal, low blast radius (admin tooling, back-office CRUD), and we are prepared to fork it, vendor it, and own it permanently under MIT.
• A spike is acceptable: we want to see the tag-based component pattern working end-to-end before committing to a design.

Look elsewhere when:

• We are on Laravel with Blade — use anonymous/class components, Livewire, or Inertia. This package contributes nothing to that stack.
• We are on modern Twig — use Symfony UX Twig Components or plain macros, both maintained and PHP 8-ready.
• The surface is customer-facing, authenticated-sensitive, or handles payments/PII. Six stars and zero dependents means no issue triage, no security response path, and no upgrade guarantee.
• We need PHP 8.1+, PSR-4/PSR-12 conformance, static analysis, or credible test coverage as adoption gates.
• The team cannot commit to owning a fork indefinitely. Unmaintained dependencies do not get cheaper over time; they get more expensive.
• The requirement is only "render forms faster." That is usually solved by the framework's existing component system at lower total cost.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated yepsua/smartwig, a Twig extension that renders UI components — forms, grids, panels, buttons — through template tags. It is free and MIT-licensed, so cost is not the issue; ownership is. With six GitHub stars, zero dependent projects, and no active maintenance, adopting it means we inherit the maintenance and security-patching obligation ourselves, on a codebase written for an older PHP generation. Recommendation: pass — reference only. We take the design pattern (tag-based components compiled from the template), not the code. No budget impact, no procurement action, and no change to the roadmap.

For engineering (the substance): The interesting artifact here is the architecture, not the library — a Twig extension registering custom tags whose node visitors compile to component markup, backed by a PHP-side builder. If that pattern is attractive to us, we can implement a scoped version internally in a few hundred lines and keep control of PHP version support, tests, and escaping behavior. If we are on Twig and want this capability with a maintenance story, Symfony UX Twig Components is the maintained equivalent. If we are on Blade, this is moot. Action: do not add it to composer.json; if we encounter it in an inherited codebase, log it as technical debt with a fork-or-replace decision attached to the next UI cycle rather than patching it in place.