Torchlight Commonmark Laravel Package

Product Decisions This Supports

• Rendering strategy for developer-facing content: server-side syntax highlighting (pre-rendered, cacheable HTML) vs. client-side JS highlighting (bundle weight, layout shift, SEO/accessibility of code blocks). This package is the server-side option wired into league/commonmark, the parser the Laravel ecosystem already standardizes on.
• Build vs. buy for highlighting: Torchlight is a hosted highlighting API with recurring cost and a network dependency; this package is the thin integration layer. The real decision is "pay for a highlighting service" vs. "self-host Shiki/highlight.php" vs. "ship highlight.js to the browser." This package only matters if the answer is Torchlight.
• Upgrade unblocker: the fork exists specifically for Laravel 11 support. If the team is planning a Laravel 11 migration and already renders Markdown with CommonMark + Torchlight, this is a dependency-conflict fix, not a new feature — evaluate it as part of the framework upgrade scope.
• Feature surface it enables: fenced code blocks in docs, blogs, changelogs, API references, marketing pages with code samples, and static site generation (HydePHP's own use case).
• Vendor/dependency policy: 0 stars and 0 dependents means adopting a single-maintainer fork. That is a governance decision (pin, wrap, monitor) as much as a technical one.

When to Consider This Package

Consider it when:

• You are on Laravel 11+, want Torchlight, and the upstream torchlight/torchlight-commonmark-php constraints block the upgrade.
• You already use (or have budgeted for) Torchlight and want server-rendered, cacheable, JS-free highlighted markup.
• You need the CommonMark extension integration path specifically — not the direct Torchlight API client or a Blade component.

Look elsewhere when:

• You want zero recurring cost or offline/air-gapped highlighting — evaluate Shiki or a PHP-native highlighter instead.
• You are not on Laravel 11 — use the upstream package, which has the adoption and maintenance history.
• Your dependency policy requires meaningful community traction; 0 stars/0 dependents is a red flag for a long-lived production dependency.
• Client-side highlighting (highlight.js/Prism) is acceptable and you'd rather avoid an external API in the render path.
• Your stack is Node-based, or you need highlighting at build time outside PHP.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed adapter that lets us render highlighted code server-side on Laravel 11 with minimal engineering effort. The package is free; the cost is Torchlight's API subscription and a dependency on a low-adoption fork. It unblocks the Laravel 11 upgrade for content-heavy surfaces without a rewrite.

To engineering: Drop-in CommonMark extension; we should wrap it behind our own rendering interface so we can swap to upstream, Shiki, or a self-hosted highlighter later. Pin the version, confirm the Laravel 11 constraint issue actually affects our composer.json before adopting, and set a review checkpoint on fork maintenance. Do not adopt it as a permanent, unexamined dependency — treat it as a bridge with a documented exit path.