Twig Markdown Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for markdown rendering. This package answers a narrow question: "do we hand-roll markdown-to-HTML conversion in our Twig layer, or take a dependency?" It is a thin wrapper over aptoma/twig-markdown, so the real decision is about the underlying library, not this bundle.
• Content format strategy. Whether to let authors write in Markdown (docs, blog posts, help center, transactional email bodies, release notes) instead of HTML or a WYSIWYG. Markdown-in-template support is the enabling capability; this package is one implementation of it.
• CMS / admin tooling scope. If non-engineers will author content, markdown support determines whether you need a rich-text editor (bigger build), a plain textarea (cheap), or a hybrid preview. This package gives you the preview/render half.
• Roadmap prioritization for templating work. If the team is already on Twig, adding markdown is a small increment; if not, this is not the package for you (see below).
• Important scope caveat for the PM: despite being filed alongside Laravel/PHP packages, this is a Symfony bundle (hashnz/TwigMarkdownBundle). It will not drop into a Laravel app without adaptation. If your stack is Laravel, the equivalent decision is league/commonmark (often via a small Blade directive or a Laravel markdown package), not this repo.

When to Consider This Package

Consider it only when all of the following hold:

• You are on Symfony with Twig as the template engine.
• You need markdown rendering inside templates (filter/function style), not just in a service layer.
• Your markdown needs are basic-to-moderate (headings, lists, links, emphasis, code blocks) and satisfied by the upstream aptoma/twig-markdown behavior.
• You are comfortable pinning/patching a low-traffic dependency, or you are treating this repo as a reference implementation to copy the wiring from.

Look elsewhere when:

• You're on Laravel or plain PHP. Use league/commonmark directly; it's the de facto standard, actively maintained, and has a large ecosystem.
• Adoption signals matter. Zero stars, zero dependents, and a zero score mean no community vetting, no security review trail, and no guarantee of maintenance. For anything customer-facing or long-lived, depend on the upstream library directly rather than a wrapper with no users.
• Security is in scope. Rendering user- or author-supplied markdown into HTML requires sanitization (raw HTML passthrough, XSS). A zero-adoption wrapper gives you no assurance here — you'll need htmlpurifier or CommonMark's safe mode regardless.
• You need GFM tables, footnotes, syntax highlighting, or custom extensions. You'll be configuring the underlying parser anyway; skip the middleman.
• Performance at scale matters. Per-template parsing without caching can be costly on high-traffic pages; you'll want a render cache, which this bundle doesn't provide.

How to Pitch It (Stakeholders)

To executives: "There's a small open-source component that lets our content team write in Markdown instead of raw HTML — cheaper and faster than building an editor, and it keeps formatting consistent across pages and emails. However, this specific wrapper has essentially no adoption (no stars, no known users) and targets Symfony, not our Laravel stack. Recommendation: adopt the well-maintained underlying parser (league/commonmark) directly and wire it up ourselves — roughly a day of engineering — rather than take a dependency on an unvetted wrapper."

To engineering: "Thin Symfony/Twig wrapper around aptoma/twig-markdown. It's ~a service definition and a Twig extension. Useful as a pattern reference for how to expose a markdown filter, but not as a dependency: zero stars, zero dependents, no maintenance signal, and it's Symfony-only. Use league/commonmark (or aptoma/twig-markdown on Symfony) directly, enable safe mode or add HTML sanitization, and cache rendered output."

Bottom line for the roadmap: the capability (markdown authoring) is worth a slot; this package is not the way to get it. Decision: build the thin integration in-house on a maintained parser.