Markdown Laravel Package

Product Decisions This Supports

• Dependency modernization / technical-debt triage. This is a live decision only if dflydev/markdown already sits somewhere in our composer graph (legacy Laravel app, older package, inherited codebase). The PM decision is replace vs. freeze vs. remove, with a dated migration ticket — not "should we adopt."
• Build vs. buy for content rendering. If a roadmap item needs Markdown → HTML (user-generated content, docs portals, comment bodies, CMS fields, changelogs, AI-generated text rendering), this package answers "buy," but it's the wrong SKU in 2024+. Its existence justifies not hand-rolling a parser; it does not justify picking this parser.
• Roadmap sequencing for a rendering/Content pipeline epic. Deprecation status makes this an input to when we touch the content layer, not whether — e.g., bundle the swap into an already-planned editor or CMS migration rather than spending a standalone sprint.
• Security & compliance posture decisions. NOASSERTION on the license plus a deprecated upstream means legal/procurement review will flag it. That is a decision artifact for the license inventory and SBOM workstream, not a feature decision.
• Feature scoping guardrails. Markdown "Extra" support (tables, footnotes, definition lists, abbreviations, fenced code) is a product surface. If we standardize on CommonMark via a maintained library, we get a spec with conformance tests — which lets us say yes/no to table and footnote support with a defensible answer instead of "whatever this library does."
• SLA/support expectations for a platform team. Publishing a package internally that depends on a deprecated parser transfers an unowned risk onto every consuming team. That's a platform-governance call.
• Use cases it legitimately covers if already installed: rendering trusted, developer-authored Markdown (READMEs, internal docs, seeded content) in a low-risk internal tool. It is a poor fit for anything user-facing that processes untrusted input.

When to Consider This Package

Consider only as an exit, not an entry.

• ✅ You already depend on it and need to scope a migration. Treat it as a known liability with a small, bounded blast radius — 0 public dependents on Packagist suggests a narrow adoption footprint, so the swap is likely contained to a handful of call sites behind MarkdownParserInterface.
• ✅ You need a stopgap while a larger CMS/editor migration lands, and the content is trusted and static.
• ✅ You're doing due diligence on an inherited Laravel codebase and need a one-line verdict for the dependency audit: deprecated, replace.

Look elsewhere — do not adopt:

• ❌ Any greenfield feature. A package whose own description says DEPRECATED should never enter a new composer.json. The PM cost is that you inherit a migration you could have avoided for free.
• ❌ Untrusted user input. Markdown parsers are an XSS and denial-of-service surface (pathological nesting, huge inputs). An unmaintained parser will not receive fixes.
• ❌ License-sensitive distribution. NOASSERTION means automated license scanners can't classify it; that blocks OSS distribution review and adds manual legal work on every audit.
• ❌ Modern PHP / Laravel targets. This is PSR-0-era code (last meaningful releases ~2013–2014). Compatibility shims on PHP 8.x are a recurring tax, and it typically won't ship a Laravel service provider or config surface you'd expect.
• ❌ A spec-conformance requirement. If you need CommonMark compliance, GFM parity, or a documented extension set, use a maintained implementation with a conformance suite.

Preferred alternatives to evaluate instead (frame as a bake-off, one spike, half a day):

• league/commonmark — actively maintained, CommonMark-compliant, GFM extension, extensible AST, the de facto Laravel-ecosystem choice.
• cebe/markdown — lighter, fast, GFM-ish, good for read-only rendering.
• erusev/parsedown (+ parsedown-extra) — smallest surface area, easiest swap for existing "Markdown Extra" behavior.
• michelf/php-markdown — the upstream lineage this package ported; same feature set, actual maintainer, better license clarity.

How to Pitch It (Stakeholders)

To executives (one paragraph): We found dflydev/markdown in our dependency review. It is a Markdown-to-HTML rendering library marked deprecated by its own maintainer, last meaningfully maintained roughly a decade ago, with an unclassifiable license (NOASSERTION) and no active dependents. It is not a security incident and not a cost line — it's a small piece of unowned technical risk in the content layer. Recommendation: do not adopt it anywhere new; schedule a low-effort replacement with a maintained library as part of work we're already doing in the content/CMS area. Cost is measured in engineering days, not dollars, and it removes a recurring question from every future license and security audit.

To engineering leadership (the ask):

• Decision: Standardize on one maintained Markdown renderer (league/commonmark is the default recommendation) and formally retire dflydev/markdown.
• Why now, but not urgently: Deprecated + NOASSERTION license + PSR-0-era code means every PHP upgrade and every audit re-opens the same question. Bounded blast radius (0 public dependents; likely a handful of internal call sites behind an interface) makes this a cheap fix if we do it inside an already-scoped epic.
• Why not a standalone project: The user-visible behavior is identical for well-formed Markdown; there's no customer-facing win to sell. Bundling avoids a sprint spent on zero-visible-value work.
• Risk if we do nothing: Low-to-moderate and slow-burning — no upstream fixes for parser bugs or DoS edge cases, plus manual legal review each cycle. Acceptable short-term; not acceptable indefinitely.
• Proposed next step: One half-day spike to inventory call sites, confirm output parity against our existing golden-file content samples, and size the swap. Ship behind the existing interface so callers don't change.
• Success criteria: Dependency removed from composer.json; parser confined to a single adapter class; content rendering output diff-tested clean; license inventory shows no NOASSERTION entries in the content layer.

One-line framing for the roadmap review: This isn't "should we use this package" — it's "how cheaply can we stop using it," and the answer is: quite cheaply, if we attach it to work already on the board.