Ux Editor Laravel Package

Product Decisions This Supports

• Build vs. buy for rich-text / block editing UI. A Laravel-native wrapper around a UX editor means the team avoids hand-rolling editor state, toolbar, and serialization logic — a multi-week build for a commodity capability. This package lets you buy that time back, at the cost of depending on a pre-1.0 third-party.
• Scoping WYSIWYG / content-authoring features (admin notes, CMS bodies, comment fields, internal knowledge-base pages). Useful for deciding whether an editor is a feature or infrastructure — if it's infrastructure, this package is too immature to carry that weight.
• Roadmap sequencing. Because v0.1.2 is a breaking change (removal of auto-generated IDs) in a 0.x line, any roadmap item depending on this package should be scoped as a timeboxed spike, not a committed deliverable.
• Standardization decision. Whether to adopt one editor integration across admin surfaces vs. per-team ad hoc choices (plain <textarea>, TinyMCE, Tiptap directly). This package only makes sense as a standard, which requires stability it does not yet have.
• Vendor/bus-factor risk register entry. Single-maintainer (@pentiminax), three releases in, no prior assessment on file. That belongs in the dependency risk log alongside the build-vs-buy call.

When to Consider This Package

Consider it when:

• You need a basic rich-text/editor surface inside a Laravel admin or internal tool, and the content model is yours (you control where the HTML/JSON lands).
• You are explicitly prototyping and can absorb a rewrite; pinning to an exact version is acceptable.
• Someone on the team can read the source — it is small enough to fork, and at 0.x you should assume you may have to.
• Editor UX is a differentiator you don't want to spend engineering weeks on, and the failure mode of a broken editor is annoying, not data-losing or customer-facing at scale.

Look elsewhere when:

• You need a supported, versioned contract (1.0+, semantic versioning guarantees, deprecation policy). Not present here.
• Content integrity matters — any change to ID generation means stored references to auto-generated IDs may break. If existing saved content is keyed on those IDs, migration work is on you.
• You need a security posture (sanitization guarantees, XSS policy, CSP compatibility) documented and reviewed. A one-line changelog is not evidence of that review.
• You need SLAs, long-term maintenance commitments, or a commercial support path.
• The editor is core product (e.g., your product is the authoring tool) — then build on the underlying editor library directly rather than through a thin Laravel wrapper you don't control.

Specific caution on v0.1.2: removing ID generation is small in lines and potentially large in blast radius. It changes the DOM/output contract. Any consumer that relied on stable generated IDs for anchors, aria-labelledby, deep links, or persisted references must now supply and manage IDs themselves — an application-level concern that landed on consumers without a major-version signal. Treat every 0.x bump here as breaking until proven otherwise.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, early-stage open-source Laravel package that gives us a ready-made rich-text editing component, saving an estimated few weeks of front-end work on non-core screens like admin panels and internal tools. It is not a platform bet: it is pre-1.0, maintained by a single developer, and its latest release changed its output format in a way that could break saved content. Recommendation is to approve a short, contained evaluation (1–2 weeks, one engineer) on a low-stakes surface only — not to commit roadmap dates or place it in any customer-facing or data-critical path until it reaches a stable release with a documented deprecation policy. Cost of trying is low; cost of over-committing is a migration we didn't plan for.

For engineering:

• Pin the exact version. Do not float on ^0.1.
• Verify what "remove id generation" changed in emitted markup/JSON; audit any persisted content and any CSS/JS/test that assumed generated IDs. Add IDs explicitly at the application layer.
• Wrap the component behind our own thin adapter so the dependency is swappable (direct Tiptap/Symfony UX integration, or a paid editor) without touching feature code.
• Confirm sanitization and output-escaping behavior before any user-generated content is rendered to other users.
• Budget for the possibility of forking: the surface is small, and single-maintainer abandonment is a plausible event.