- What is torchlight/engine and how is it different from the hosted Torchlight API?
- torchlight/engine is the PHP-side rendering core behind Torchlight for Laravel. Instead of sending code snippets to the hosted Torchlight API, it performs syntax highlighting and Torchlight annotation rendering in-process inside your PHP application. That removes a third-party network hop, keeps your source code on your own servers, and decouples rendering cost from API quotas.
- How do I install torchlight/engine in a Laravel application?
- It is a Composer package, so installation is a standard composer require torchlight/engine followed by whatever provider registration or config publishing the README documents. It ships as an MIT-licensed, auto-discovered Laravel service provider with config-published defaults, so most teams should find integration low-friction. Always read the current README for the exact provider and config steps, since the package is recently released.
- Do I need Node.js or a JavaScript runtime to use torchlight/engine?
- No. The engine is pure PHP and is built on top of Phiki, the PHP port of the TextMate grammar highlighting approach used by Shiki. That means there is no Node process, no WASM runtime, and no subprocess to manage in your deploy pipeline. This is a materially simpler operational story than Shiki-based alternatives that require a JavaScript toolchain.
- Does torchlight/engine replace league/commonmark or spatie/laravel-markdown?
- No. torchlight/engine is not a general-purpose Markdown parser or a drop-in replacement for league/commonmark or spatie/laravel-markdown. It is purpose-built for the Torchlight annotation syntax, covering line highlighting, diffs, focus ranges, and labels. You typically keep your existing Markdown pipeline and let the engine handle the code-block rendering layer.
- Which PHP and Laravel versions does torchlight/engine support?
- The package is recently released and actively maintained, so the supported matrix is best confirmed from its composer.json and README before you commit. Check the constraint graph against your lockfile first, because a transitive PHP or illuminate/* conflict is the most likely and cheapest-to-find blocker. If you already depend on torchlight/torchlight-laravel, verify that both constraints can be satisfied together.
- How do I migrate from the hosted Torchlight API to local rendering with torchlight/engine?
- Pin your current torchlight/torchlight-laravel version and capture baseline rendered HTML for a representative corpus such as docs pages, blog posts, and changelog diffs. Install the engine on a feature branch, render the same corpus, and diff the output, classifying divergences as cosmetic whitespace, token or grammar differences, or annotation feature gaps. Benchmark p50 and p95 render time plus peak memory, gate cutover on parity and performance thresholds, and keep the API path behind a config flag for one release cycle.
- Does torchlight/engine send my source code to a third-party service?
- Rendering happens locally in your PHP process, so code snippets are not shipped to the hosted Torchlight API. That is the central architectural benefit for teams with proprietary code or strict data-residency requirements. You should still review the package for any optional network calls, and confirm whether grammars and themes are bundled or fetched at install time.
- Can I pre-render or cache highlighted code blocks instead of rendering on every request?
- Because the engine runs in-process, highlighting can happen at request time or be pre-rendered during a build or deploy step. For content-heavy sites, pre-rendering or caching the resulting HTML is usually the better fit and keeps request latency flat. Measure per-code-block render cost and peak memory for large blocks before deciding which approach to use.
- Does torchlight/engine support custom themes, line highlighting, and annotations?
- Yes. The engine is built around the Torchlight annotation syntax, so line highlighting, diff-style ranges, focus ranges, and labels are first-class features. It also supports custom themes and a flexible plugin architecture for extending rendering behavior. Parity with the hosted renderer should still be validated against your own corpus before cutover.
- Is torchlight/engine production-ready, and how does it relate to torchlight/torchlight-laravel?
- The engine is effectively the local rendering core consumed by the Torchlight Laravel client, so it is most likely a component beneath that umbrella package rather than a separate API you wire up yourself. Treat adoption as early-adopter territory: it has few dependents and moderate star counts, which usually means the umbrella package has not yet bumped onto it. The main risks are pre-1.0 API churn, unproven rendering parity with the SaaS renderer, and single-vendor concentration.