Torch Filament Laravel Package

Getting Started

First, resolve the identity of the package. The repo description ("Infolist component to highlight code using Torchlight Engine") and the packaged description.md ("generates complete Filament resources…", which is really lara-zeus/torch) disagree. Before you spend a sprint, run:

composer show lara-zeus/torch-filament --all

and read src/ directly. What you are almost certainly installing is a narrow presentational component: a Filament infolist entry that renders a string as syntax-highlighted code via Torchlight. Plan on that; verify nothing else is bundled.

Prerequisites.

• Laravel app already running a Filament panel.
• Filament 5 — 3.0.0 is a semver-major whose only changelog entry is "support filament 5". If you are on Filament 4, do not let a code-highlighting widget drive a platform upgrade; defer.
• PHP/Laravel/Livewire constraints that satisfy Filament 5. Run composer why-not lara-zeus/torch-filament 3.* on a scratch branch before booking work.
• Torchlight's own setup: the underlying torchlight/torchlight-laravel engine plus its JS/CSS assets. Confirm whether this package pulls that in or expects you to have it. If highlighting is delegated to the hosted Torchlight API, you have a network egress, API key, rate limit, and data-residency decision to make before wiring anything — check with whoever owns infosec if your admin panel ever renders sensitive config, payloads, or tokens.

Install and register.

composer require lara-zeus/torch-filament
php artisan filament:assets

Register the plugin per-panel (not globally) in your panel provider so it's easy to disable:

->plugin(\LaraZeus\TorchFilament\TorchFilamentPlugin::make())

Confirm the real plugin/entry class name from the source tree — the README is thin and the marketing copy is wrong, so trust the code, not the prose.

Your first use case. The canonical one is an infolist ViewRecord page that shows a stored string as highlighted code. A viewer relation or a snippet model with a content and language column, displayed as:

// Confirm the exact class + method names from src/ before copying
TorchlightEntry::make('content')
    ->language('php')

Then in the panel: Config viewer (show a config/app.php blob), an API sample page, a payload inspector for a webhook log record, or an onboarding docs page. These are the realistic day-to-day wins — internal back-of-house surfaces where code readability aids comprehension, not customer-facing code viewers.

Where to look first, in order: src/ (the component + plugin), composer.json (constraint chain and Torchlight dependency), and any tests against Filament 5. If there are no tests, that is your baseline risk signal.

Implementation Patterns

Thin wrapper over Torchlight. The package's value is that it saves you the glue between Torchlight output and a Filament infolist entry — theming, escaping, and panel integration. Treat it as exactly that: don't expect copy buttons, line numbers, diff views, tabs, or large-file streaming. Those belong in your own Blade view if the requirement is real.

Admin docs / knowledge-base page. A Snippet model (title, language, content, category) rendered as a ViewRecord page with the entry in the infolist. This is the pattern with the best reuse and the cleanest fit: the data is authored in the panel, and the display is a read-only infolist. This is the one worth building.

Config / payload / log inspector. Store or stream a JSON body or config block and render it in a ViewRecord. Pair with ->language('json') / ->language('yaml'). Beware size — see Gotchas. If the payload is potentially large, truncate server-side before handing it to the component.

Feature-flag fallback. Do the whole integration behind a panel-scoped plugin registration and a config toggle:

if (config('panels.torchlight.enabled')) {
    $panel->plugin(TorchlightPlugin::make());
}

Ship a plain <pre> Blade view that renders the same field when the flag is off. That gives you a one-line revert if Torchlight has an outage, the key rotates, or the maintainer stalls — which, given 7 stars and 0 dependents, is the operational risk you are actually buying.

Caching. Confirm from the source whether highlighted output is cached or recomputed on every render. If recomputed, cache the rendered HTML keyed on (language, hash(content)) and render the cached string. For internal admin concurrency (tens of users) this is cheap insurance; for anything larger it is mandatory.

Panel-scoping. Register per-panel, not app-wide, so you can stage rollout to a single low-traffic panel first, measure render latency and asset weight, and expand only if it holds. This also keeps removal a config change, not a deploy rollback.

Migration from 2.x. The 2.x → 3.0.0 jump is a Filament 4 → 5 move; there is nothing to migrate in the package itself — the migration is your Filament upgrade. Do the Filament upgrade first, confirm the panel is stable, then add this on top. Do not let the two coincide in one release.

Gotchas and Tips

The metadata is wrong. The attached description.md describes a completely different product (lara-zeus/torch — a scaffolding generator). Whatever your procurement or ticket system ingested from that description is about the wrong thing. Read src/ and composer.json before anything else; treat the prose as unreliable.

Torchlight hosting is the real decision, not the component. Torchlight runs either as a hosted API (network egress, API key, rate limits, code leaves your infrastructure) or self-hosted. In a regulated or air-gapped environment, the hosted path is disqualifying regardless of how neat the component is. Confirm which model torchlight/torchlight-laravel is configured for in your app before adopting this wrapper.

Hard coupling to Filament's major version. 3.0.0 exists solely to track Filament 5. That means every Filament major will reopen this dependency. Add it to the Filament upgrade checklist alongside other panel plugins, and pin exactly ("lara-zeus/torch-filament": "3.0.x") so drift surfaces as a Composer resolution error, not a runtime blank entry.

Failure mode to verify explicitly. Does the component degrade to plain <pre> when Torchlight fails (missing key, rate limit, outage), or does it throw and blow up the whole infolist page? For a read-only internal page the difference is "ugly" vs. "page is down." Test it by unsetting the API key in a local environment and loading a record.

Asset build. This package will need Torchlight's CSS/JS present. Run php artisan filament:assets after install and after any upgrade, and include a smoke test that a code block renders with highlighting in CI (a browser test or at minimum a Dusk/Playwright screenshot check). This is the most common "it worked on my machine" failure here.

Vendor-readiness. MIT, 7 stars, 0 dependents, one maintainer, single-line changelogs. Budget half a day to git clone the repo into a packages/ path and composer path it if the maintainer goes quiet. This is cheap and turns abandonment into a routine maintenance task. Keep the plain <pre> fallback specced for the same reason.

Don't use it as a code viewer. No copy buttons, no line numbers, no diff, no tabs, no streaming. If your requirement has any of those, use Torchlight (or Shiki/Prism) directly in a custom Blade view. The 80% fallback — a <pre> with a small client-side highlighter — covers most of the actual need at zero vendor risk, which is exactly why the adoption bar here should be low, not high.

The changelog is one line. Ask the maintainer (or read the diff) whether 3.0.0 is a genuine compatibility shim or a rewrite. "Support filament 5" tells you nothing about whether your theming and asset config survive. Also check whether 2.x still receives patches during any Filament 4→5 window you have open.