- How do I install torchlight/laravel in a Laravel application?
- Install it with Composer, publish its configuration, add TORCHLIGHT_TOKEN to your environment, and register the service provider or CommonMark extension in your rendering setup. There are no migrations, queues, or database tables to manage. A proof of concept is typically measured in hours.
- Does torchlight/laravel support Laravel 10, 11, and 12?
- torchlight/laravel is intended for supported Laravel and PHP versions, including Laravel 10, 11, and 12 applications using league/commonmark. Because it is a thin wrapper maintained by a single maintainer, confirm the package's release notes match your exact Laravel major before upgrading. Test in a feature-flagged environment rather than assuming forward compatibility.
- How does torchlight/laravel work with Markdown and CommonMark?
- It supplies a league/commonmark extension so Markdown converted through CommonMarkConverter can render highlighted code blocks. You register the Torchlight extension deliberately in your CommonMark configuration. This makes it a rendering-layer substitution for blogs, docs, changelogs, and similar Markdown content.
- Do I need an API token and outbound internet access for Torchlight?
- Yes. You need a valid Torchlight API token in TORCHLIGHT_TOKEN and outbound HTTPS egress to the Torchlight API endpoint. Highlighting happens as a synchronous outbound HTTP call at render time, so network access and vendor availability matter. Plan for data-egress review because source code is sent to a third-party service.
- Does torchlight/laravel cache highlighted code blocks?
- The package is built around rendering cached code blocks, and caching should be treated as a production requirement. Put Redis or the Laravel cache in place before sending real traffic, and define a TTL and cache-key strategy that matches your content update cadence. The client has no database schema or persistent state of its own.
- What happens if the Torchlight API is down or times out during page render?
- Torchlight highlighting is a synchronous outbound HTTP dependency in the page-render path, so a timeout, 429, or 5xx can affect the page unless you design for failure. Wrap it behind a highlighter abstraction and feature flag so you can degrade to an existing highlighter or a fallback. Confirm the client's error behavior during your proof of concept and add monitoring for latency and failures.
- Can I use torchlight/laravel with a Blade component instead of Markdown?
- Yes. The package provides a Blade component in addition to the CommonMark extension, so you can render highlighted code blocks directly in views. Use the Blade component where code blocks are authored in templates and the CommonMark extension where content is converted from Markdown. Both paths still depend on the Torchlight API and your token.
- Is torchlight/laravel a replacement for highlight.js or Prism.js?
- It can replace client-side highlight.js or Prism.js when your code blocks are rendered server-side through Laravel and CommonMark. Highlighting moves to render time, which removes the flash of unstyled code and the client-side JavaScript payload. It is not a fit for SPAs, static-site generators outside Laravel, or request paths that do not render Markdown.
- What are the main risks of using torchlight/laravel in production?
- The main risk is architectural: page rendering gains latency variance, availability coupling, per-request cost, and an external data-egress path. Secondary risks include the package's maturity, with roughly 120 stars, zero known dependents, and a single maintainer, so the wrapper could lag Laravel major releases. Vendor lock-in is moderate because output is static HTML with inline styles, but configuration, themes, and the token workflow are Torchlight-specific.
- How do I test or migrate to torchlight/laravel safely?
- Start with a low-traffic surface, inventory all Markdown rendering entry points, and put a feature-flagged highlighter abstraction around Torchlight and your incumbent. Validate output parity on representative content, including themes, line highlighting, diff annotations, and language coverage, before enabling production traffic. Introduce caching before launch and retire the old highlighter only after parity is confirmed.