Tinymce Bundle Laravel Package

Product Decisions This Supports

• Rich-text editing as a build-or-buy capability decision. This package is a thin wrapper around TinyMCE, so its real product value is as a conversation starter: does the roadmap need WYSIWYG at all, and if so, is TinyMCE the right editor versus Tiptap, Lexical, Editor.js, Quill, or a Markdown-first approach? The wrapper is commodity; the editor and its licensing are the decision.
• Scoping the integration as trivial, not a project. Everything the bundle does — asset inclusion, a config-driven theme map, a form helper — is a few dozen lines of first-party glue. This supports treating rich-text integration as a one-day engineering task in the roadmap rather than a dependency evaluation or a vendor selection exercise.
• Framework-alignment as a product constraint. The package is a Symfony2 bundle, and Symfony2 reached end-of-life in 2018. For a Laravel product this is a hard stop and a useful data point: it informs a policy that product dependencies stay framework-native (service providers, config publish tags, Vite/npm assets) rather than importing another ecosystem's conventions.
• Dependency-risk policy inputs. Zero stars, zero dependents, a score of 0, and a dead framework target make this a clean reference case for a "do we accept unknown-maintainer dependencies" policy — specifically, a clear reject. It informs the risk rubric more than any individual feature decision.
• Legacy migration scoping. If any portfolio surface still runs Symfony2, this flags an unmaintained integration island to be replaced as part of a modernization plan — not as new feature work.
• Editor UX and content-model requirements gathering for the PM. The bundle's theme/variant idea (a default plus named simple/full/minimal presets) is a useful prompt for defining which authoring surfaces the product actually needs, and for capturing requirements around sanitization, accessibility, paste behavior, and output format before any editor is chosen.

When to Consider This Package

Consider it only under a narrow, unlikely conjunction:

• You are maintaining an existing Symfony 2.x application (not Laravel, not Symfony 4+), and
• You need TinyMCE wired into server-rendered forms with minimal effort, and
• You have already accepted the bundle is unmaintained and are prepared to fork and own it internally.

For anything else, look elsewhere:

• Laravel in any form: this is not a Laravel package. No service provider, no facade, no publishable config in the Laravel sense. Adopting it means fighting the framework; a Blade component plus npm install tinymce reproduces the same behavior in under a day and keeps the editor version locked in package.json.
• Greenfield or product-facing surfaces: prefer an editor with an active release cadence and a documented React/Vue path (Tiptap, Lexical, Editor.js) so front-end work is not constrained by a PHP-era wrapper.
• Any surface where TinyMCE licensing matters: TinyMCE v6+ is GPL or commercial. For a closed-source commercial product this is a procurement and legal decision on its own, and the bundle will pin or assume an older version.
• Any requirement where sanitization/XSS handling is assumed: the bundle does not handle it; treat it as a first-party requirement regardless of editor.
• Zero-adoption dependencies in general: no stars, no dependents, and a dead framework target is a package-health signal, not a coincidence.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. This is a Symfony2 bundle — not a Laravel package — targeting a framework that has been end-of-life since 2018. It has no visible adoption (zero stars, zero dependents, score 0) and no maintenance posture. Even in its native environment, it saves hours of config sugar in exchange for a permanent, unmaintained dependency in a user-facing surface.

For executives: there is no cost saving and no capability we cannot build in-house in under a sprint. Adopting it trades a few hours of setup for a small, permanent maintenance liability, plus a supply-chain consideration: an unmaintained, near-anonymous dependency sitting in our form layer. The decision to make is the editor choice (TinyMCE licensing and hosting model vs. alternatives), not the wrapper.

For engineering: treat this as a rejected candidate and a scoping error in the brief. Use it as a reference implementation only — the Twig init helper, the config-merge/theme map, and the data-theme opt-in pattern are worth copying into a first-party Blade component and a config/tinymce.php. Prefer Vite/npm over CDN URL strings so the editor version is pinned and auditable. Budget roughly a day for the integration; add a separate task for sanitization/XSS review of editor output.

For the roadmap: if rich text editing is genuinely planned, sequence it as (1) an editor-selection spike benchmarking license, output format, sanitization, accessibility, and bundle size, followed by (2) a thin in-house integration with sanitization built in. If it is not planned, note this package as evaluated and declined and take no further action.