- Is tempest/markdown a Laravel package?
- No. It is a framework-agnostic, near-zero-dependency PHP library with no service provider, facade, config file, publishable assets, or Blade directive. You consume it directly with new Markdown() and parse(), which returns a result object exposing html and frontmatter. That neutrality means it can run inside a domain service, an Artisan command, a queue worker, or a CI static-site step without framework coupling. The trade-off is that every Laravel-shaped convenience, such as a singleton binding, Blade directive, config file, or HTML caching, is roughly 30 to 50 lines you write and own.
- How do I install and use tempest/markdown in a Laravel app?
- Run composer require tempest/markdown, then instantiate the parser and call parse() with your Markdown string. The returned object exposes $parsed->html for the rendered output and $parsed->frontmatter['title'] for YAML frontmatter values. There is no auto-discovery or config step, so you can drop it into a controller, job, or Artisan command immediately. Integration risk is low because the dependency surface is one Composer package with no external services or build step.
- How does tempest/markdown compare to league/commonmark and Parsedown Extra?
- The project's benchmark table reports roughly 10.9ms and 6.6MB for the Tempest docs corpus versus 57ms and 21MB for league/commonmark, with Parsedown Extra at 15.2ms. The design rationale is that it uses a simple lexer to tokenize Markdown instead of relying on regex, which is directionally credible but was measured by the vendor on a vendor corpus. Re-measure on your own content, PHP version, and runtime (FPM, queue worker, or serverless) before treating those numbers as a planning input. commonmark remains the safer pick if you need strict spec compliance above all else.
- What Markdown features does tempest/markdown support out of the box?
- Built-in extensions include code highlighting, table support, div blocks, responsive images, and frontmatter parsing. That covers most documentation and blog rendering needs without extra plugins. Features that are not documented, such as footnotes, autolinks, definition lists, custom containers, or configurable syntax-highlight themes, should be verified against the source before you commit. If you need one of those, budget for either an upstream contribution or a custom extension.
- Does tempest/markdown follow the CommonMark spec?
- Not strictly. The custom lexer intentionally diverges from CommonMark, and the 1.3.0 changelog shows edge-case stabilization work on setext headings, short headings, bullet markers, lazy list continuations, thematic breaks, and unmatched tildes. Treat spec-exact HTML as unproven until you diff its output against league/commonmark on your real content. If a downstream consumer, such as an API, a mobile client, or exported HTML, assumes CommonMark behavior, validate before committing to the package.
- Is tempest/markdown safe to use with untrusted user input?
- Version 1.2.1 shipped XSS fixes for HTML attributes and code blocks, plus a parser cache-leak fix and a configurable maxNestingDepth setting. The existence of those knobs is good, but it also implies this class of bug has occurred in the past. Markdown-to-HTML with untrusted input is an XSS surface regardless of which parser you use, so plan an HTML sanitizer and your own adversarial test corpus as part of the integration rather than as later hardening. If your input is trusted, such as your own repo docs and changelogs, the risk profile is much lower.
- Which PHP and Laravel versions does tempest/markdown support?
- Check the PHP constraint in composer.json rather than the README, since the 1.0.0 changelog includes a Fix PHP version entry. Because the package is framework-agnostic, Laravel version compatibility is mostly a function of your PHP runtime rather than the framework itself, so Laravel 10, 11, and 12 on modern PHP should all work. It does not hook into Blade, Eloquent, queues, or caching, so there is nothing to conflict with there. Dependency-conflict risk with an existing composer.lock is low given how little it pulls in.
- Is tempest/markdown stable enough for production?
- It carries an explicit work-in-progress banner, roughly 44 GitHub stars, no known dependents, and a small maintainer pool with no vendor or SLA behind it. The API has moved from pre-1.0 into 1.x, so the parse() result shape and frontmatter semantics could still shift. Pin the version in composer.json and treat upgrades as reviewed changes with a changelog read. In practice you are the support contract, so name an owner for the wrapper and the upgrade cadence.
- How do I add a Blade directive or singleton binding for tempest/markdown in Laravel?
- Register a singleton in a service provider that returns a configured Markdown instance, then add a Blade::directive or a custom Blade component that calls parse() and echoes the html property. That adapter is small, typically 30 to 50 lines, and easy to swap if you later move to another parser. Keep the adapter in one place so the underlying library stays replaceable, and avoid scattering new Markdown() calls across views and controllers. This wrapper-and-swap approach also gives you a single point for sanitization and caching.
- How should I test and cache Markdown rendering in Laravel?
- Start with snapshot tests on a representative sample of your real documents and a parity diff against league/commonmark so you can quantify output differences before rollout. Add adversarial fixtures for raw HTML, attributes, deeply nested structures, and malformed lists to cover the XSS and maxNestingDepth surface. HTML caching is not provided by the package, so if you need it, implement it in your adapter keyed by content hash and parser version. Define a measurable success bar up front, such as a parity diff threshold, p95 render latency, and a memory ceiling on your runtime.