Twig Classes Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for view-layer class logic. zicht/twig-classes is a thin adapter that exposes zicht/classes (a PHP helper for composing CSS class lists, BEM-style modifiers, and conditional classes) inside Twig templates. The decision it informs is whether class-name composition belongs in PHP helpers invoked from templates, or in Twig macros/filters you own.
• Where presentation logic lives. Adopting it means conditionals like "add is-active when state is X, append a modifier when size is Y" stay in templates and out of controllers/view models, instead of accumulating as string concatenation in Twig or duplicated per-component.
• Component library consistency. If you ship a design system or a set of Twig components (buttons, cards, form fields), a shared class-composition helper is the difference between consistent BEM output and per-team ad-hoc class strings. This is a design-system governance decision as much as a technical one.
• Roadmap scoping for templating modernization. Relevant if you are evaluating a move toward Twig components/TwigComponent, or if you are deciding whether to invest in a small internal utility layer versus adopting a broader frontend framework.
• Use cases it plausibly fits: server-rendered marketing sites, admin back-offices, agency-built client sites with bespoke Twig component sets — anything Symfony/Twig with hand-authored CSS.
• Portfolio/technical-debt triage. With 0 stars, 0 dependents, and no maintenance signal, the honest PM decision is usually "pattern yes, package no": adopt the idea of a class-builder, and either vendor the ~50 lines or write your own filter. The 8.32 opportunity score reflects niche whitespace (nobody has solved this well), not package quality — do not read it as adoption validation.

When to Consider This Package

Consider it when all of the following hold:

• Your stack is PHP + Twig (Symfony, Craft, Slim+Twig, or similar) and templates are the primary authoring surface.
• You already use, or are willing to adopt, zicht/classes as the underlying class-name builder — this package is worthless without it.
• You have a real, recurring need for conditional/modifier class composition across many templates, not one or two components.
• Your team accepts an unpinned, low-ceremony dependency from a single agency (Zicht) with effectively no community footprint.

Look elsewhere — or build in-house — when:

• Support and longevity matter. Zero dependents and no stars is a strong signal this is agency-internal tooling. No ecosystem means no third-party bug reports, no security review, and no guarantee of a release compatible with your Twig major version. Fork it or reimplement it.
• You are not on Twig. React/Vue/Svelte equivalents (clsx, classnames, cn) are mature and better supported; this package adds nothing there.
• You want a maintained, opinionated solution. Twig's own {% apply %}/macro patterns, twig/html-extra, or TwigComponent-adjacent tooling may cover the need with better bus-factor characteristics.
• Your CSS is utility-first (Tailwind). Conditional class composition is largely absorbed by utility classes and component extraction; the abstraction pays less rent.
• You have strict dependency-review or SBOM requirements that a single-maintainer, zero-adoption package will not clear.

Recommended framing for engineering: treat it as a reference implementation. Read the source, confirm it is a trivial wrapper, and decide between composer require and a 30-line internal Twig extension you own.

How to Pitch It (Stakeholders)

One line: A small Twig extension that lets templates compose CSS class names cleanly and conditionally, replacing scattered string concatenation with a single, testable helper — but it is a low-adoption, single-vendor package, so we should adopt the pattern rather than lean on the dependency.

For executives: This is not a platform decision, it is a hygiene decision. Class-name logic scattered across templates is a known source of UI inconsistency and slow, error-prone styling changes — especially across a multi-client or multi-brand portfolio. A shared class helper makes design-system changes cheaper and makes UI regressions less likely. Cost is negligible; the real recommendation is to standardize the pattern internally rather than depend on an unsupported third-party package for it.

For engineering: zicht/twig-classes exposes zicht/classes as a Twig filter/function. It solves a real annoyance — conditional and BEM modifier composition in templates — with minimal surface area. Risks: single maintainer, no adoption signal, no compatibility guarantees across Twig majors, and an implicit hard dependency on zicht/classes. Proposal: 1–2 hours to evaluate the source, then either pin and vendor it or reimplement equivalent behavior as an internal Twig extension under our own ownership. Either way we get consistent class output, and we avoid a silent dependency we cannot maintain.

Ask: Approval for a timeboxed spike (≤1 day) and a decision gate — adopt, vendor, or reimplement — before any team standardizes on it.