Docxmustache Laravel Package

Product Decisions This Supports

• User-generated content (UGC) features: comments, forum posts, profile bios, support tickets, and any field where end users submit HTML that gets rendered back to other users. Tag cleaning is a prerequisite capability, not a nice-to-have.
• Build vs. buy: replaces hand-rolled strip_tags/regex sanitizers that tend to accumulate security debt. Adopting a maintained package shifts that burden off your team.
• Roadmap enablement: unblocks or de-risks any roadmap item involving rich text, WYSIWYG editors, markdown-with-inline-HTML, or email template previews. If those items are queued, this is an enabler worth sequencing ahead of them.
• Security posture / compliance: supports XSS defense-in-depth arguments in security reviews and vendor questionnaires, particularly where user content is displayed to privileged users (admin panels, moderation queues).
• Release-specific signal (v0.0.44): the tag cleaner was rewritten to no longer use regex. Regex-based HTML parsing is a well-known correctness and ReDoS hazard, so this is a quality improvement rather than a feature. It carries no new product capability and should be treated as a verification task, not a roadmap input: output may differ on malformed or adversarial markup (unclosed tags, nested quotes, comments, <script> inside attributes). Plan a regression pass against a corpus of real payloads before letting the version float.

When to Consider This Package

Consider adopting when:

• You need to allow a subset of HTML (a tag/attribute allowlist) rather than strip everything — strip_tags plus manual attribute filtering is where teams get burned.
• Your sanitization needs are contained: rendered user content is a small, well-understood surface (a handful of fields, one or two views).
• You're on a Laravel version this package supports and you value framework-native integration (service provider, config publishing, Blade usage) over a standalone library.
• You accept pre-1.0 semantics: 0.0.x signals an unstable public API, so pin exact versions, read the changelog on every bump, and wrap the call site behind your own thin interface so swaps are cheap.

Look elsewhere when:

• The content is security-critical and adversary-facing at scale (public social feed, anything behind a WAF you'd rather not test). Prefer a battle-tested, spec-driven sanitizer — e.g. HTML Purifier or Symfony's HtmlSanitizer — with a long support horizon and an explicit threat model.
• You need full HTML5 conformance, CSS sanitization, or URL scheme policy beyond simple tag stripping.
• You need a stable API and vendor SLAs; a 0.0.x package is a poor fit for a platform team's long-term dependency budget.
• The requirement is trivially "escape everything" — Blade's {{ }} already does that, and adding a dependency buys you nothing.

How to Pitch It (Stakeholders)

For executives (30 seconds): User-generated content is one of the most common sources of security incidents, and the usual fix — engineers writing their own HTML cleaners — is where bugs hide. This is a small, Laravel-native library that handles that job so we don't have to. Cost is low, integration is a day or two, and it removes a recurring class of risk from anything where customers type into our product. The latest release (v0.0.44) is an internal hardening change — the cleaner no longer relies on regex — which is exactly the kind of maintenance we'd otherwise be paying our own engineers to do. Caveat: the package is pre-1.0, so we should pin the version and keep our integration behind a thin wrapper.

For engineering: Adopt behind an interface, not scattered call sites. Pin 0.0.44 explicitly and do not float ^0.0. Before upgrading anything that renders stored user content, run a differential test of old vs. new output over a payload corpus — malformed tags, unclosed attributes, encoded entities, <script> in attributes, oversized input (check for pathological runtime, the historical reason to drop regex here). Treat the rewrite as behavior-affecting until proven otherwise, even though the changelog frames it as internal. No config or API changes are implied, but confirm against the diff before assuming.