Markdown Laravel Package

Product Decisions This Supports

• Build vs. buy on content rendering. If the roadmap contains docs, blogs, changelogs, knowledge-base articles, release notes, or user-authored Markdown, this is a "buy" (adopt) decision that replaces an internal parser and its hardening backlog. The realistic alternatives are league/commonmark (ecosystem default) or a hosted rendering service; this is the low-dependency, high-performance option.
• Whether rendering can happen on-request instead of at build time. The benchmark table is the PM artifact that matters: ~10.9ms and 6.7MB versus ~57ms and 21MB for league/commonmark on a real docs corpus. That gap is the difference between "we must pre-render and cache everything" and "we can render per request," and between "this runs in a web worker" and "this runs in a memory-capped queue worker or serverless PHP runtime."
• Dependency consolidation. Frontmatter parsing, code highlighting, tables, divs, responsive images, and manual header IDs ship in the box. That removes a highlighter and a frontmatter library from the stack, which shrinks the supply-chain surface and the security-review scope — a decision worth recording, not just an implementation detail.
• File-based content architecture. Frontmatter means a .md file carries title, date, tags, draft and can drive routing, navigation, and SEO metadata without a database or separate YAML step. This directly enables "docs and blog as Git-tracked content, not CMS rows," which changes who owns publishing and how the content pipeline is built.
• Keeping rendering server-side. Pure PHP, no Node toolchain, no JS build step for rendering. That supports a simpler deploy pipeline and lets rendering live in Laravel controllers, Blade, Artisan commands, and queued jobs.
• Extensibility as a roadmap hedge. The lexer-plus-rules design means custom syntax (mentions, embeds, callouts, internal links) is an in-house addition rather than a fork or a vendor ask. That supports a "we can grow into it" decision instead of a "rip and replace later" one.
• Risk gating and ownership. This assessment should terminate in an explicit adopt / pilot / avoid call with a named owner, given the early-stage signals below.

When to Consider This Package

Consider (pilot) when:

• You're on PHP/Laravel and want Markdown rendering with one Composer dependency, no external service, no Node toolchain.
• Rendering volume or latency is on the critical path — high-traffic docs, per-request rendering of user content, batch conversion in CI, or memory-constrained workers and serverless runtimes.
• You want frontmatter and extensions out of the box rather than commonmark plus several extension packages plus a highlighter.
• You can absorb early-adopter work: pin the version, write your own output-diff and XSS tests, and upstream fixes. The project is actively maintained (security and parser fixes, multiple outside contributors) and MIT-licensed, so exit cost is low.
• You need a configurable safety ceiling for untrusted input — maxNestingDepth exists, and the 1.2.1 release fixed XSS via HTML attributes and code blocks. Both signal security is being taken seriously, and both signal it's still being discovered.

Look elsewhere when:

• Strict CommonMark compliance is contractual or an interoperability requirement. A custom lexer that intentionally diverges and adds extensions will differ at the edges — the 1.3.0 changelog (setext headings, lazy list continuations, thematic breaks, unmatched tildes) is the clearest evidence that spec edges are still being closed. Validate output before assuming spec-exact HTML reaches downstream consumers.
• Ecosystem depth and production exposure beat raw speed. league/commonmark has years of production use, a broad extension ecosystem, and a long security history you can point a reviewer at.
• You need an SLA, LTS guarantee, or a vendor to escalate to. 44 stars, zero known dependents, and an explicit "work in progress" banner mean you are the support contract.
• Procurement or architecture review requires a de facto standard. "No known dependents" will cost more in review cycles than the performance win returns.
• Rendering happens client-side (live preview, browser Markdown) — this is a PHP parser; it's the wrong tool.
• You need to sanitize arbitrary untrusted HTML. Markdown-to-HTML plus user input is an XSS surface; budget an HTML sanitizer and your own adversarial test suite regardless of the fixes shipped.

Adoption gate (recommended): a one-sprint spike — render your actual content corpus, diff output against the current renderer, run malicious-input tests, and measure latency and memory in your real runtime. Put the parser behind an internal interface so it stays swappable. Promote to production only if the diff is acceptable and single-maintainer risk is explicitly accepted.

How to Pitch It (Stakeholders)

For executives (30 seconds): Markdown is how our docs, blog, and user content becomes web pages. Today that's either slow, memory-hungry, or requires extra infrastructure. This is a small, MIT-licensed, pure-PHP component that renders the same content roughly 5x faster using a third of the memory of the most common alternative — on a real documentation set, 11ms instead of 57ms, 6.7MB instead of 21MB. It also replaces three or four dependencies with one by bundling frontmatter, code highlighting, and table/image support. There are no license fees, no new services, no new hosting, and it's trivial to remove. Recommendation: fund a one-sprint evaluation, not a commitment.

For engineering leads: composer require tempest/markdown, then parse() returns ->html and ->frontmatter. There's no regex engine — a lexer tokenizes the document, which is where the speed and memory gains come from. It ships frontmatter, code highlighting, tables, divs, responsive images, manual header IDs, and a configurable maxNestingDepth, and it's extensible via custom rules. Note it is framework-agnostic, not a Laravel package — no service provider, facade, config, or Blade directive. Budget ~30–50 lines of wrapper for singleton binding, a Blade directive, and config; treat that as a known cost, not a surprise. Recent releases fixed XSS in HTML attributes and code blocks, a parser cache leak, and several spec-edge cases: active maintenance, and a reminder that this is pre-stabilization software.

The honest caveat to say out loud: this is early-stage — 44 GitHub stars, no known dependents, an explicit "work in progress" notice, and a maintainer team still closing CommonMark compliance gaps. Frame it as a high-upside, low-switching-cost pilot, not a strategic platform bet. We contain the risk by pinning the version, keeping rendering behind an internal interface, owning an output-diff and XSS test suite, and committing to upstream the fixes we need. If the spike doesn't clear the bar we fall back to the incumbent having lost a week; if it does, we cut render cost and remove dependencies from the critical path.