Markdown Bundle Laravel Package

Product Decisions This Supports

• Framework standardization vs. capability standardization: The single most useful product decision this package informs is whether markdown authoring should be solved per framework or as a shared capability. ornj/markdown-bundle is a Symfony bundle — not a Laravel package — so it exposes the cost of framework-scoped tooling: anything built this way must be rebuilt when the stack changes. That argues for a product-level decision to standardize on a server-side parser (league/commonmark) plus a JS editor that both your Laravel and (any) Symfony surfaces share.
• Build vs. buy for authoring UX: Markdown-with-preview is a commodity. This bundle is a useful "prior art" artifact for sizing the work — it demonstrates the shape of the integration (a form field wrapping a textarea + preview target + parser), which makes in-house effort realistic to estimate in days, not sprints. That directly informs whether to build natively rather than adopt an unmaintained dependency.
• Sanitization and rendering ownership (security-relevant product call): Authoring preview is not the trust boundary. This package only addresses the input/preview half and provides no rendering hardening story. The decision it forces — where markdown is parsed, where HTML is allow-listed, and whether preview and published output share a single render path — is a product-visible correctness and security choice you must make regardless of whether you adopt the package.
• Roadmap enablement for content surfaces: If the roadmap includes a knowledge base, docs portal, changelog/release notes, in-app help center, support macros, or comment/annotation features, markdown authoring becomes a cross-cutting platform requirement. This package is evidence of a recurring need rather than a strategic bet — treat it as a signal, not a solution.
• Use cases it clarifies: internal admin tools where authors are trusted or semi-trusted; low-volume, high-structure content (runbooks, API docs, policy pages); and anywhere a plain-text, diffable, version-controllable source format is preferable to stored HTML.
• Upgrade-path planning: Because the package targets an end-of-life Symfony generation and is not a Laravel dependency, its primary product value is as a negative signal — a concrete reason to route authoring investment into maintained, stack-agnostic components that don't accrue migration debt.

When to Consider This Package

Consider it only under a narrow, mostly reference-oriented set of conditions:

• You are running a legacy Symfony 2.x application and need a drop-in markdown form field with preview, and the realistic alternative is custom form-type plus JS work.
• You want low-cost prior art: reading the bundle's templates and JavaScript to understand its preview interaction model (split-pane vs. toggle, debounce, toolbar) before committing to a maintained editor is a legitimate, cheap use.
• Scope is small, internal, and authenticated: authors are trusted or semi-trusted, and all rendered output passes through your own sanitizer — the bundle is not a trust boundary.
• You can vendor or fork it and accept indefinite ownership of patching, as a deliberate short-term bridge on a frozen application.

Look elsewhere when any of the following hold — and for a Laravel target, they almost all do:

• You are on Laravel (as this brief implies): this is a Symfony bundle with no adapter, no bundle registry, and no Form component equivalent. Porting effort exceeds writing the field natively with a Blade/Livewire/Inertia component plus a PHP parser. Assume zero code reuse.
• You are on a supported Symfony (5/6/7) or planning an upgrade: adoption couples admin tooling to an EOL framework generation and adds migration debt you will pay twice.
• The package shows zero stars, zero dependents, zero score, and no maintenance signal: no security response, no PHP-compatibility guarantees, no upstream fixes for parser or XSS issues. Abandonment is the dominant risk factor.
• You need production-grade authoring: tables, footnotes, task lists, syntax highlighting, image paste/upload, autosave, collaborative editing. A maintained JS editor (EasyMDE, Toast UI, CodeMirror-based) plus a CommonMark/GFM parser covers this and is stack-agnostic.
• You require audited supply-chain posture: security review, license clarity, dependency freshness, or SBOM inclusion — an unmaintained bundle with no community will not clear the gate.
• Public-facing rendering is in scope: you still need your own parser, sanitizer, caching, and HTML allow-list; the bundle solves only the smallest part.

How to Pitch It (Stakeholders)

For executives (one paragraph): The capability being evaluated — letting people write in markdown and see a formatted preview — is a commodity authoring convenience, not a differentiator. This specific package is a small, unmaintained Symfony2-era form component with no community adoption (no stars, no dependents) that targets a framework generation past end of life, and it is not a Laravel package despite how it was surfaced. The recommendation is do not adopt it as a dependency. We can deliver the same value in a fraction of a sprint by pairing a maintained client-side markdown editor with a maintained server-side parser, which works across both our Symfony and Laravel surfaces, is actively patched, and keeps upgrade paths open. Treat the repository as a design reference only.

For engineering (summary):

• What it is: a Symfony2 bundle contributing a form type, Twig templates, some client-side preview JavaScript, and a wrapped markdown renderer. No sanitization guarantees, no parser ownership, no Laravel surface.
• Health: zero stars, zero dependents, no maintenance signal, no compatibility story beyond Symfony2's EOL line. Adopting it means we inherit maintenance and security response for a widget that is a few hundred lines to rebuild.
• Recommendation: reference-only. Build natively — a Blade/Livewire component (or Vue/React depending on front end) wrapping a maintained editor (EasyMDE / Toast UI / CodeMirror) and league/commonmark + a sanitizer (mews/purifier or equivalent) server-side. Estimated effort: 2–5 engineering days for the internal authoring field, excluding sanitization hardening and integration tests.
• Non-negotiables in our build: server-side parsing with an explicit HTML allow-list (preview is not a trust boundary); stored markdown as the canonical, diffable source of truth; and one shared rendering path so preview and published output cannot diverge. If server-side preview is required, debounce aggressively and rate-limit the endpoint.
• Suggested spike: timebox one day to build the component with EasyMDE + league/commonmark and compare UX against the bundle's readme/screenshots; only revisit the bundle's source if the spike reveals an interaction we cannot reproduce cheaply.
• Decisions needed from product: (1) confirm the authoring surface is internal/authenticated for v1; (2) confirm whether GFM extensions (tables, task lists, footnotes) are in scope — that answer drives editor choice more than framework preference; (3) confirm whether preview must match exactly what the server stores.