Torch Filament Laravel Package

Product Decisions This Supports

• Build vs. buy on a narrow, undifferentiated UI task. This is a single Filament infolist component that renders syntax-highlighted code via the Torchlight engine. The decision it informs is small but concrete: instead of having engineering hand-roll a code-rendering entry (wiring Torchlight, theming, escaping, asset build, Filament integration), we adopt a plugin. Adopt only where the requirement is a thin, one-off surface — not where code display is a core product feature.
• Roadmap enablement for "code in the admin panel." Any roadmap item that needs to show code, config blocks, API examples, payloads, or error frames inside a Filament back-office is unblocked by this — e.g. developer-tooling dashboards, an internal docs/knowledge-base admin, a support/ops console surfacing snippets to agents, or an onboarding/educational admin surface.
• Scope containment on dev-tooling products. Where highlighted code is genuinely part of the admin experience, adopting this keeps a low-differentiation, well-understood job off the critical path and lets engineering spend cycles on what customers actually judge us on.
• Dependency-tiering policy (risk register). With 7 stars and 0 dependents, this is a single-maintainer, low-adoption ecosystem plugin. It is a useful concrete test case for a standing rule: third-party Filament plugins are acceptable for peripheral UI, not for critical paths. The takeaway is tiering, not blanket adoption.
• Upgrade-sequencing decision. Release 3.0.0's entire stated change is "support Filament 5," so the package major tracks Filament's major. Adopting it is coupled to our Filament version — sequence it inside a platform move, not as a routine dependency bump. Critically: do not let a syntax-highlighting widget be the reason we take a Filament major upgrade.
• Use cases served: code display inside Filament infolists/entries — admin docs, snippet libraries, support/ops consoles, developer portals, config or payload viewers, and any back-office surface where formatted code aids comprehension.
• Metadata caveat that gates the decision. The repo description ("Infolist component to highlight code") and the attached description.md (an AI toolkit — providers, models, prompts, chat, conversations) describe two different products; the latter matches lara-zeus/torch, not torch-filament. Before this enters a roadmap, confirm which package we are actually evaluating from its composer.json and source tree. The discrepancy itself is a supportability and diligence signal.

When to Consider This Package

Consider it when:

• The back-office layer is already Filament-based (Filament 5) and the specific need is an infolist entry that renders highlighted code — not a general-purpose highlighting library.
• The requirement is peripheral to the product — an internal panel where a small third-party dependency stalling will not jeopardize the business.
• You prefer a Filament-native wrapper over integrating Torchlight yourself: less glue code, consistent theming, one plugin registration per panel.
• You are comfortable with the Lara Zeus ecosystem and its conventions.
• Torchlight's hosting model is acceptable — hosted API (network egress, key management, source snippets leaving our infrastructure) or a viable self-hosted option. For most internal tooling this is fine; for regulated or air-gapped environments it is disqualifying unless self-hosting checks out.

Look elsewhere or defer when:

• You are not on Filament. Outside Laravel/Filament admin panels this has no value; use Torchlight (or Shiki/Prism) directly.
• Highlighted code is a core or customer-facing surface — a public code viewer, a docs site, a heavy or high-traffic render path. A 7-star, 0-dependent, single-purpose plugin is a liability in the critical path; build on Torchlight directly with our own tests and theming.
• You need richer code UX — copy buttons, line numbers, diff views, multi-language tabs, large-file streaming. This is a component, not a full-featured code viewer.
• You are still on Filament 3/4. 3.0.0 is a semver-major tied to Filament 5; adopting may force a panel-wide upgrade. Defer until the platform upgrade is independently justified.
• There is no tolerance for low-adoption dependencies in your dependency policy — this fails that bar by design.

Before adopting, verify: the actual package identity (see caveat above); composer.json constraints for PHP, Laravel, Filament, and Livewire; Torchlight configuration/bundling (hosted vs. self-hosted, keys, languages/theme, asset publishing); per-panel vs. global registration; graceful degradation to a plain <pre> on highlighting failure; presence of any test coverage against Filament 5; and a real upgrade path from 2.x (the changelog is one line — ask the maintainer).

How to Pitch It (Stakeholders)

For executives (one paragraph): We identified a small, single-purpose plugin that lets our Filament admin panel display formatted, syntax-highlighted code without us building it. The value is modest and bounded: it saves a little engineering on a non-differentiating UI task and unblocks any back-office screen that needs to show code or config, and it does not touch customer-facing surfaces or business logic. The caveats are maturity and metadata quality — it is a young project with a single maintainer, minimal adoption, and a repository description that does not fully match its attached documentation, so it belongs firmly in the "peripheral tooling" category, not the critical path. Recommendation: approve it for internal, non-critical panels where it plainly saves work, keep it behind a toggle so we can fall back to a plain code block, and treat its 3.0 release as a platform-coupled upgrade (it tracks Filament 5) rather than routine maintenance.

For engineering (summary): This is a Filament infolist entry that renders code using the Torchlight engine. Confirm the package's actual function first — the repo description and the attached docs describe two different products, and we should verify from composer.json and the source tree before committing. Then confirm two things before building: (1) 3.0.0 is a semver-major whose only note is "Filament 5 support," so expect the package major to track Filament's — do not let it drive a Filament upgrade, register it per-panel, stage the rollout, and add a regression pass over the affected infolists, theme, and filament:assets build; and (2) the Torchlight hosting model — hosted API vs. self-hosted, key/secret management, data-egress implications with security, and whether highlighted output is cached or recomputed on every render. Validate the full constraint chain (PHP/Laravel/Filament/Livewire) with composer why-not on a scratch branch, confirm whether 2.x stays patched during any 4→5 window, and verify the entry degrades to plain text rather than throwing when highlighting fails. Because the fallback (a Blade <pre> entry, or client-side Prism/Shiki) is cheap and covers most of the need, the adoption bar should stay low — keep usage behind panel-scoped registration and a config flag so it is a one-hour revert, add a smoke test that the infolist entry renders, and report a rough effort estimate for both the integration and the Filament-major coupling before this lands in a release.