Tinymce Laravel Package

Product Decisions This Supports

• Rich-text editor selection for content surfaces. This package exists to answer one narrow question inside the Contao ecosystem: which version of TinyMCE do we ship, and how do we pin and deliver its assets. For a PM, it is a datapoint in the broader "what editor do we standardize on" decision — TinyMCE vs. CKEditor 5 vs. Tiptap/ProseMirror vs. a lighter Markdown-first experience.
• Build vs. buy for editor tooling. TinyMCE is the classic buy/assemble path: mature, feature-complete, but with a licensing and hosting decision attached (self-hosted vs. TinyMCE Cloud, and GPL vs. commercial terms). This package represents the "vendor assets pinned via Composer" flavor of that decision.
• Asset delivery strategy. It illustrates a legitimate architectural pattern — distributing third-party JS through the package manager alongside server dependencies — that is worth comparing against the more common Laravel approach of npm + Vite bundling. That comparison is a real roadmap/architecture decision even if this specific package loses it.
• Portfolio/integration scoping. If your roadmap includes multi-CMS connectors or content migration from Contao, knowing that Contao's editor assets are Composer-managed (and that this repo is the maintained mirror) informs effort estimates for migration and export tooling.
• Not a Laravel decision. Be explicit internally: this is a Contao component, not a Laravel package. It ships no service provider, no config, no model binding, no upload handling. The decision it supports for a Laravel team is a negative one — it justifies looking at Laravel-native editor integrations instead.

When to Consider This Package

Consider it only when:

• You are running Contao (not Laravel) and want TinyMCE assets version-pinned through Composer rather than committed to the repo or pulled from a CDN.
• You already depend on the contao-components/* family and want consistency in how vendor assets are resolved.
• You need a self-hosted editor in a locked-down/air-gapped deployment where CDN and npm-at-build-time are both unattractive.

Look elsewhere when:

• You are on Laravel, Livewire, Inertia, or Filament. Use the tinymce npm package behind your Vite build, or a Laravel-native wrapper that gives you config publishing, file/image upload endpoints, and model binding. This package provides none of that.
• You need community validation. The signals here are thin: zero stars, zero dependents, a package score of 0, and an opportunity score of 51.3. Zero dependents on a widely-used editor integration is a strong hint that consumption happens through Contao's own dependency graph rather than direct adoption. Treat it as a maintained mirror, not an independently validated library.
• Licensing hasn't been cleared. Verify which TinyMCE major is bundled before committing. The license changed materially between v6 (MIT) and v7 (GPL-2.0-or-later with a commercial option), and TinyMCE Cloud carries separate commercial terms. This is a legal review item, not an engineering detail.
• You need an editing experience, not an editing asset. If your requirements include collaborative editing, structured content blocks, or a component-based authoring model, TinyMCE's classic iframe model may be the wrong primitive regardless of packaging.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose asset package from the Contao CMS ecosystem — it delivers TinyMCE, a mature rich-text editor, and nothing else. It carries no community traction (zero dependents, negligible stars), so it is not a strategic dependency and does not belong in our Laravel stack. The recommendation is to not adopt it, and instead make a deliberate editor decision: TinyMCE self-hosted, a commercial cloud tier, or a modern block-based alternative. The only real cost exposure is licensing — TinyMCE's terms tightened at v7 — which is a one-time legal check, not an ongoing spend.

To engineering: Treat this as a reference implementation of Composer-based vendor asset distribution, not as a dependency. There is no Laravel integration layer: no service provider, no publishable config, no upload handling, no model binding. If TinyMCE is the chosen editor, the right shape for us is the tinymce npm package wired through Vite with an upload endpoint we control, plus an explicit decision on self-hosted vs. cloud and a license review against the bundled major version. Revisit this package only if Contao enters our integration scope — for example, a content migration or a multi-CMS connector — in which case it tells us where Contao's editor assets come from and how they are versioned.

Bottom line: Low-risk, low-relevance for a Laravel product. Use it as an input to the editor-standardization and licensing decisions; do not use it as a dependency.