Markdownify Bundle Laravel Package

Product Decisions This Supports

• Content portability / export features: this package's entire reason to exist is turning HTML into Markdown inside a Symfony application — useful for "export to Markdown" buttons, CMS content portability, static site generation, changelog/docs pipelines, and archiving rich-text content as diffable plain text.
• LLM and RAG context preparation: HTML→Markdown is a common normalization step before feeding content to a model or embedding pipeline. This is the most commercially relevant use case in 2024+, and it is not what this bundle was built for — evaluate the underlying library, not the bundle.
• Build vs. buy: strongly favors build. The bundle's contribution over the underlying Markdownify class is a service definition and a config block — roughly an afternoon of work to replicate in a modern Symfony app (services.yaml + one wrapper class). There is no proprietary logic, no vendor leverage, no licensing cost.
• Roadmap input: this package is a data point, not a dependency. Its existence confirms HTML→Markdown conversion is a recurring need in Symfony shops; that argues for owning a thin internal converter service rather than sourcing one.
• Not a differentiator: nothing here creates user-visible advantage. Treat as commodity plumbing at best.

When to Consider This Package

Consider only if all of the following are true:

• You are maintaining a legacy Symfony 2.x application that already has this bundle installed and working, and the alternative is a disruptive migration.
• The conversion workload is small, non-critical, and internal (no user-facing SLA, no untrusted HTML on the critical path).
• You have accepted a permanent fork-and-patch posture: the bundle is archived, last released 2019-05-15, and will receive no security or compatibility fixes.

Look elsewhere — decisively — if any of these apply:

• Any greenfield or Symfony 4/5/6/7 project. The Symfony2 bundle structure is incompatible with modern Symfony; Flex, autowiring, and attribute-based config are all absent. This is a hard blocker, not a preference.
• You need maintained dependencies. A 2019 archive with 0 dependents and 3 stars means essentially no community scrutiny, no CVE triage, and no bus factor beyond the original author. Supply-chain review should fail this on maintenance-liveness criteria alone.
• You need performance or streaming for large documents — an unmaintained 2019 converter has no modern benchmarks or tuning.
• You want the function without the bundle. Install a maintained HTML→Markdown library directly (the league/html-to-markdown family is the usual default; the original Markdownify class is also usable standalone) and register it as a service yourself. This is the recommended path in nearly every case.

Adoption criteria summary: do not adopt; do not migrate off in a panic if already present and working — instead, add a backlog item to replace the bundle with a direct library integration during the next maintenance window for that app.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated pk/markdownify-bundle, an MIT-licensed Symfony 2 add-on for converting HTML content to Markdown. It is technically sound in intent but operationally dead: archived, last released in 2019, three GitHub stars, zero dependent projects, and bound to a Symfony version that has been end-of-life for years. The business capability — exporting our content as clean, portable Markdown for docs, archives, and AI/LLM ingestion — is genuinely useful and worth having. This package is not the way to get it, and it carries no cost to skip. Recommendation: do not adopt; if we need the capability, spend roughly one engineer-day wiring a maintained converter library into our own service layer, which we then own and can patch.

For engineering leads (the short version): The bundle is a thin DI wrapper — a service definition plus config — around the Markdownify class. There is no hidden value to preserve. Symfony 2 bundle conventions make it unusable on Symfony 4+ without a rewrite, and the 2019 archive date means no security patches and no PHP 8.x guarantees. If we already have it in a legacy app, leave it alone until that app's next scheduled maintenance, then replace it with a direct dependency on a maintained HTML→Markdown library and a first-party wrapper class. Effort: low. Risk of the current state: low but nonzero — unpatched third-party code on our dependency manifest. If we greenfield the capability, do not add this to the shortlist; the build-vs-buy math is a clear build, and it doubles as the migration target for the legacy instances.