Commonmark Bundle Laravel Package

Product Decisions This Supports

• Per-surface content rendering policy. The bundle's one distinguishing feature — registering several named CommonMark converters, each with its own configuration — maps directly onto a product decision most content-bearing apps eventually face: not all Markdown is equal. Comments, support tickets, and user bios need a hardened converter (no raw HTML, no dangerous links, minimal extensions). Internal docs, changelogs, and CMS pages can safely run an extended converter (tables, footnotes, attributes, autolinks). Marketing/email previews may want a stripped, plain-text-friendly variant. This package lets you express that as configuration instead of branching logic scattered across services.
• Build vs. buy for Markdown plumbing. The actual parsing work is league/commonmark v2 — a mature, widely used library. This bundle is a thin Symfony DI layer on top of it. That reframes the buy decision: you are not buying a Markdown engine, you are buying roughly a service-definition file and a compiler pass. The real question is "do we want to spend a sprint designing a converter-registry abstraction, or copy ~200 lines of YAML/PHP?"
• Feature viability for a docs/help-center/commenting roadmap. If the roadmap includes any of: knowledge base, in-app release notes, forum or comment threads, ticket bodies, or user-authored profiles, you need a sanctioned rendering path before you ship, not after. Adopting this now is cheap optionality; retrofitting a second converter config into live templates later is where XSS and inconsistent-rendering bugs come from.
• Trust-boundary tiering. Being explicit that "converter A is untrusted input, converter B is trusted staff input" is a security product decision as much as an engineering one. A named-converter registry makes that boundary legible to reviewers and auditable in one config file.
• Use cases where it clearly pays off: multi-tenant SaaS where each tenant may want different Markdown dialects; migration off a legacy renderer one surface at a time (run both converters in parallel behind a feature flag); A/B testing rendered output formatting.

When to Consider This Package

Adopt (or, more realistically, vendor/fork) when all of the following hold:

• You are on Symfony 5.x (the bundle targets Symfony 5) and have no near-term framework upgrade, or you are willing to own a fork for 6.4/7.
• You genuinely need two or more converter configurations active in the same application. If one config suffices, this bundle buys you nothing over league/commonmark plus a single service definition — or over Twig's markdown filter via twig/markdown-extra.
• You want the configuration to live in Symfony config/YAML so non-authors can change extensions without touching PHP.
• You accept that the integration layer is small enough to read, patch, and replace.

Look elsewhere, or plan to substitute, when:

• Maintenance risk is disqualifying. 2 GitHub stars, 0 dependents, last release August 2021, and a composite opportunity score near zero. There is no community to catch regressions, and no evidence of a Symfony 6/7 release. Treat it as sample code, not a dependency.
• You are on Symfony 6.4/7. Use symfony/ux-markdown (first-party, actively maintained) or wire league/commonmark yourself — the latter is a legitimate afternoon of work.
• You only need one converter — the abstraction is pure overhead.
• You need more than configuration: custom AST visitors, custom parsers, streaming rendering, or per-request converter mutation. At that point you want direct control of the Environment object.
• You need guaranteed security patch cadence. The underlying league/commonmark gets those; this wrapper is a fixed snapshot of its config surface.

Net PM recommendation: do not add this as a live dependency. Instead, read it as a design reference — the "multiple named converters" pattern is worth adopting, and the bundle demonstrates the shape of it — then implement the pattern in-house against league/commonmark v2 directly, or fork the bundle under your own namespace if you want the config-driven ergonomics.

How to Pitch It (Stakeholders)

To executives (30 seconds): We need different Markdown safety settings for different parts of the product — locked-down for anything a customer types, feature-rich for content our own team writes. The open-source package that solves this is MIT-licensed and free, but it's effectively abandoned (last release 2021, two stars, no users). Recommendation: don't depend on it. The idea is worth ~1 engineering day to implement ourselves on top of the well-maintained league/commonmark library, which we'd be using either way. This de-risks a future security/compliance conversation at trivial cost and avoids onboarding a dependency nobody maintains.

To engineering: yivoff/commonmark-bundle is a Symfony 5 DI wrapper that lets you register N named league/commonmark converters with distinct configs. The parsing is all upstream — the bundle is a compiler pass and some service definitions. Value is the named-converter registry pattern, not the code volume. Concrete ask: spend a day building markdown.converter.<name> services with a tagged locator, one hardening profile (no HTML, html_input: strip) and one extended profile. Constraints to note: the bundle is Symfony 5-only and unmaintained, so pulling it in directly creates an upgrade blocker at the exact moment we move to Symfony 6.4/7. If we want it verbatim, vendor it under our namespace so we control the release.

To security/compliance: this is the mechanism that makes "untrusted Markdown is rendered with raw HTML disabled and unsafe links stripped" a declarative, reviewable configuration rather than an assumption spread across templates. That's the audit artifact worth having.