Draftjs Bundle Laravel Package

Product Decisions This Supports

• Content model for rich text. Whether to persist editor output as Draft.js raw ContentState JSON, HTML, or Markdown. If you store raw JSON, every consumer that isn't the editor — server-rendered article pages, transactional email, RSS/AMP, mobile clients, search indexing, LLM pipelines — needs a converter. That's the exact gap this bundle filled.
• Build vs. buy vs. borrow. This package is a reference spec, not a dependency. Its block-type and entity handling (unordered/ordered lists, atomic blocks, links, decorators) is a useful checklist for scoping an in-house converter — realistically a 1–2 week spike for one engineer, not a quarter.
• Editor roadmap. Draft.js itself is no longer actively maintained by Meta. Any decision to stay on Draft.js should be paired with a decision about who owns server-side rendering forever. This package's archival is a concrete data point for "the ecosystem around this editor decays."
• Rendering surface priorities. Decide whether HTML is generated at write time (store both JSON + HTML, cheap reads, migration pain) or read time (single source of truth, needs a reliable renderer in every runtime). This package only supports the read-time path, and no longer reliably.
• Security posture for user-generated content. Draft.js raw JSON → HTML is an XSS-adjacent transformation. Whatever you adopt must own sanitization explicitly; an archived, unmaintained converter cannot be your trust boundary.
• Legacy migration. If any stored content is in Draft.js raw format, this is a signal to inventory it now and define an exit path before the last person who understands the schema leaves.

When to Consider This Package

Effectively never for new or existing production work. It is explicitly marked deprecated, archived, last released February 2017, has 7 stars and zero dependents — no maintenance, no PHP 8 compatibility story, no security response, no community to inherit it.

Narrow cases where it is still worth ten minutes:

• As documentation. Reading the source to understand the Draft.js raw block/entity shape and typical conversion edge cases before writing your own renderer.
• Archeology. Auditing an inherited Symfony codebase that may already depend on it, so you know what has to be replaced.

Look elsewhere — or build — when any of the following apply:

• You're on Laravel. Despite the framing, this is a Symfony bundle (a bundle, a DI extension, Symfony-era PHP). It has no Laravel service provider, no facade, no config publishing. Integration cost exceeds rewrite cost.
• You need maintained dependencies. PHP 8.1+, modern static analysis, security patching, or an SBOM that survives an audit.
• You need sanitization guarantees. Pair any converter with an explicit HTML sanitizer (e.g., a maintained HTML purifier) rather than trusting the transformer.
• You're choosing an editor today. Prefer editors with first-class, maintained server-side rendering or an HTML-native storage format — TipTap/ProseMirror, Lexical, or plain Markdown — over reconstructing a dead bridge.

The high "opportunity" score is the interesting signal here: server-side rendering of rich-text editor output is genuinely underserved in PHP. That argues for a small, owned, well-tested internal package, not for resurrecting this one.

How to Pitch It (Stakeholders)

Executive summary. We evaluated m6web/draftjs-bundle, a PHP library that converts Draft.js rich-text content into HTML on the server. Recommendation: do not adopt. It is formally deprecated and archived, last shipped in 2017, and has no users or maintainers. It is also a Symfony bundle, so it does not fit our Laravel stack.

Why it still matters. It surfaces a real, unowned product problem: any content our users write in a rich-text editor has to be rendered somewhere other than the browser — article pages for SEO, emails, feeds, and APIs. Today that problem has no clear owner, and the most popular PHP solution in this space is dead. The market gap is real; the specific artifact is not viable.

What we recommend. (1) Decide and document our rich-text storage format this quarter — ideally one where HTML is a first-class output, not a re-derivation. (2) Budget a short engineering spike to build a small, tested, sanitized converter we own, or to migrate the editor to one with maintained server-side rendering. (3) Inventory any legacy Draft.js content and define a migration path.

Risk of the status quo. Adopting an archived converter would put an unmaintained, unpatchable component on the trust boundary for user-generated content — an XSS and compliance exposure — with no upgrade path. The cost of building our own is measured in days; the cost of an incident is not.