Twig Instanceof Laravel Package

Product Decisions This Supports

• Build vs. buy (really "adopt vs. write"): The capability is small — registering an instanceof expression/test in Twig. This package is a decision not to maintain that glue yourself. The real PM question is whether a small, low-adoption dependency is worth the vendor risk versus copying ~30–50 lines under MIT into your own Twig extension. v1.3 slightly improves the "adopt" side of that ledger without changing the calculus: the package now supports Symfony 8 and fixes a PHP/Twig deprecation warning, and it picked up two first-time outside contributors. That is evidence of maintenance, not of a support contract.
• Whether to invest in a Twig-based rendering layer at all. Twig is not Laravel's default engine (Blade is); you only get here via rcrowe/twigbridge or a Symfony codebase. If your roadmap leans on Twig, small ergonomic gaps like this compound; if it's incidental, this package is noise.
• Feature enablement for polymorphic rendering. Concrete use cases: CMS/content blocks where each block is a distinct PHP class, mixed-type activity feeds or notification lists, form field rendering by field type, and permission- or plan-gated UI where the object type varies at runtime. It lets templates branch on type instead of forcing controllers to pre-split collections into typed buckets.
• Template-logic placement policy. Adopting this is an implicit decision to allow some type-based branching in the view layer. That is a deliberate architectural stance worth stating explicitly, because it is also the first step toward domain logic leaking into templates.
• Framework lifecycle / upgrade planning. v1.3 adds Symfony 8 support, which means the package is a viable choice for teams planning a Symfony 8 upgrade rather than something to route around. Conversely, the fact that a deprecation fix was needed means you should track its release cadence against your PHP/Twig upgrade windows.
• Risk/roadmap hygiene: Near-zero dependents and a very small maintainer base still mean you should decide now whether this is a pinned, isolated dependency or a vendored snippet — before it becomes load-bearing in a dozen templates. The recent influx of outside contributors is a positive signal but not yet a pattern.
• Not a decision this supports: anything Blade-related, and anything where the branch is really business logic (pricing, entitlement, workflow state) rather than presentation.

When to Consider This Package

Adopt when all of the following hold:

• Twig is genuinely your template engine (Symfony, or Laravel with TwigBridge already in place).
• You have real polymorphism in your view models — several classes sharing one template or one list — and the alternative is repetitive {% if item.type == 'video' %} string checks or controller-side collection partitioning.
• You want to avoid stringly-typed type discrimination in templates; instanceof is refactor-safe in a way that magic type strings are not.
• You are on, or planning to move to, Symfony 8 — v1.3 is the first release to support it, so pin ^1.3 rather than a looser constraint if that is on your roadmap. The return-type/deprecation fix also makes it usable on current PHP versions without warning noise.
• You are comfortable pinning a low-maturity MIT dependency, or willing to fork/vendor it. Check the source before adopting — it should be a thin extension registration, nothing more.
• Your team accepts the coupling cost: templates referencing PHP class names is a real refactor hazard when classes get renamed or namespaced.

Look elsewhere (or just write the test yourself) when:

• You are on stock Laravel/Blade. This package does nothing for you.
• Twig's built-ins already cover it: is defined, is null, is same as(), attribute(), or a semantic custom test like {% if block is renderable as 'video' %} — which is usually the better design because it decouples templates from class names.
• The branching is domain logic. Push it into a presenter, view model, or renderer registry and keep the template dumb. A RenderableBlock interface with a render() method beats instanceof chains almost every time.
• You need support guarantees, SLAs, or a dependency with meaningful community surface area. Small adoption numbers are a signal, not a disqualifier — but it does mean you own the risk.
• You only need this in one or two templates. The cost of a dependency exceeds the cost of a local extension class.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed Twig extension that lets templates distinguish between object types when rendering mixed content — think content blocks, activity feeds, or form fields. It removes a class of brittle string-comparison hacks from our templates and costs effectively nothing to try. The newest release (v1.3) is a maintenance release: it adds support for Symfony 8 and fixes a deprecation warning, and it drew two new outside contributors — modest but real evidence the package is being kept current, which matters for our upgrade path. The caveat stands: it is a tiny project with negligible adoption, so we should treat it as a pinned utility and be ready to vendor the (small) source if it goes stale. Low cost, low risk, modest upside.

To engineering: Single-purpose extension adding an instanceof expression to Twig, relevant only where we already run Twig (Symfony, or Laravel + TwigBridge). It buys us type-safe branching in templates instead of magic type strings. v1.3 is non-breaking: Symfony 8 support plus a return-type fix for a deprecation message, so upgrading from v1.2 is low-effort, and it removes friction if Symfony 8 is on our horizon. Two guardrails: (1) review and pin the source at ^1.3 — it is small enough to fork outright if we prefer; (2) prefer wrapping it in a semantic Twig test so templates don't hardcode PHP class names, and keep genuine business logic out of templates. If we only need it in a handful of places, writing the extension in-house is a legitimate alternative and avoids the dependency entirely.