Nova Tinymce Field Laravel Package

Product Decisions This Supports

• Build vs. buy for rich-text authoring in Laravel Nova. This package answers a narrow, recurring question: do we hand-roll a WYSIWYG field (TinyMCE init, asset publishing, toolbar config, Nova field lifecycle for index/detail/forms) or drop in a dependency? If the admin panel is internal and the editor is a table-stakes capability, this is a ~1-day build compressed into one composer require — a defensible "buy" (adopt) call.
• Unblocking a content-authoring milestone. If the roadmap item is "editors can author blog/help-doc/policy content in the admin panel without a developer," this is the shortest path to shipping. It converts a form textarea into a real authoring surface without touching the front end, because content is stored as plain HTML.
• Scoping the CMS surface area. Choosing a free-text HTML field is a product decision, not just a technical one: it means authors control markup and layout inside the body copy. That's fine for internal/marketing-lite content; it's a deliberate no to structured blocks, editorial workflow, and design-system-enforced rendering. Make that trade-off explicitly.
• Deferring investment in a content platform. Adopting a thin field wrapper keeps you off a headless CMS contract for now — a useful lever when comparing "extend Nova" against "license Contentful/Storyblok/Sanity" for a small team.
• Prioritising roadmap bets elsewhere. Because the integration is cheap, it frees engineering capacity for differentiators. The PM decision is "spend a day here, not a sprint."
• Constrained by signals, not features. Feature-wise this does what it says. Procurement-wise the signals are weak: 0 stars, composite score 0.3, single-maintainer-style release history, last release April 2024. That makes this a contained bet — acceptable for an internal tool, hard to justify as a platform dependency.

When to Consider This Package

Consider adoption when all of these hold:

• You are already on Laravel Nova, and the Nova version is compatible with the package's supported range (verify against the field's composer.json before committing — Nova major versions do break custom fields).
• The content is internal, low-blast-radius, or marketing-lite: help articles, internal docs, announcements, policy pages, small marketing pages. Authors are trusted staff.
• HTML-as-storage is acceptable — you render it on the front end and are prepared to own sanitisation (HTMLPurifier or equivalent) at render or save time. Unescaped HTML from an editor is a stored-XSS surface; that's your risk to manage, not the package's.
• You are willing to pin and vendor: pin an exact version, commit composer.lock, and accept that a 0-star package may be abandoned. Budget for the fork day.
• Requirements are "a decent toolbar, plugins we can toggle, config we control" — not "a content platform."

Look elsewhere — or build the field in-house (it is genuinely small: a Nova Field subclass, a Vue component wrapping TinyMCE, and ->withMeta() passthrough) — when:

• You need structured/block content, portable content models, or a future migration to a headless CMS or mobile app. HTML blobs are a one-way door; migrating thousands of authored pages off raw HTML is real cost.
• You need editorial workflow: drafts, scheduled publish, approvals, revisions/diffs, multi-locale content, per-role editor restrictions. A field wrapper gives you none of this.
• You have licensing or compliance constraints. Confirm TinyMCE's current licence terms and whether you are self-hosting or using TinyMCE Cloud (which has API-key and commercial terms). Also check accessibility obligations (WCAG) and content-security-policy compatibility with a CDN-hosted editor.
• The admin panel is customer-facing or high-traffic and you need a maintained dependency with security response. 0 stars and a year-old release is not that.
• Engineering already standardises on a Markdown editor or an existing Nova field, or you need media library / asset manager integration in the editor.

Additionally, treat the documentation as a diligence flag: the release notes supplied here describe a fix to an "incorrect post path" and contain routing/service-provider/path-resolution guidance that does not match a Nova WYSIWYG field at all. Either the release notes are mismatched or the docs are copied from another package. Verify against the actual repository README and source before adoption — if the docs are untrustworthy, assume the maintenance is too.

How to Pitch It (Stakeholders)

To executives (one paragraph): For roughly a day of integration effort we can give editors a professional rich-text authoring experience inside the admin panel we already own, instead of paying for a separate CMS or paying engineers to build an editor. It is a small, reversible, contained bet: it stores standard HTML, so our content is not locked in, and we can swap it out or take over the code if we ever need to. The honest caveats are that the package has essentially no community adoption and hasn't been updated in about a year, so I recommend we adopt it as an internal-tooling dependency only, pin the version, and not build customer-facing or high-compliance content on top of it. Net: it unblocks the authoring milestone this quarter at near-zero cost, with the main residual risk being maintenance, which we can absorb.

To engineering (the asks):

• Vet Nova-version compatibility and pin an exact release + lockfile. Assume we may fork; keep the integration behind a thin internal wrapper class so a swap is a one-file change.
• Own the security boundary: sanitise stored/rendered HTML, and get a CSP decision on how TinyMCE assets are loaded (self-host vs CDN) settled up front.
• Treat authoring constraints as config, not code: toolbar/plugins/make() options should live in one place so product can tune the editor without a deploy.
• Set expectations that this is not a content platform — no workflow, revisions, or structured fields. If product later asks for those, that's a new build-vs-buy conversation, and we should not assume this package grows into it.