Tinymce Bundle Laravel Package

Technical Evaluation

Verdict up front: this is still not a Laravel package — but the reason has changed. prolix/tinymce-bundle is now a Symfony 6/7 bundle, not a Symfony2 bundle: v3.0.5 bumps the symfony/framework-bundle constraint to 7.*. That removes the "anachronistic, frozen artefact" objection and removes the Composer-deadlock objection. It does not create an integration path. Laravel's service container, package discovery, Blade, and config/*.php publish pipeline still share no contracts with Symfony's Bundle / Extension / CompilerPass model. Treat it as a reference implementation to mine, not a dependency to install — the conclusion is unchanged, the reasoning is updated.

Architecture fit

• Unchanged and decisive: nothing in the bundle binds to Laravel. The constraint bump targets a framework whose kernel we never boot, so the code would install and then never execute.
• What is reusable: the editor asset tree, default toolbar/plugin configuration, and any integration patterns for image/file upload callbacks. v3.0.5 does not change any of this — the release touches one Composer constraint and nothing else, which also confirms the vendored TinyMCE build is untouched.
• What is not reusable: configuration loading, Twig rendering helper, container-tag-based auto-registration.
• Net: still roughly 20–30% of the package's surface mapping to a Laravel target, and that 20% remains the least differentiated part (a static JS bundle plus an array of options).

Integration feasibility

• Materially changed, in a way that is worth stating precisely because it removes a false safety net. Previously the plan could lean on "composer require will fail, so nobody will try." A Symfony 7 constraint may now resolve against a Laravel 11/12 application (both sit on modern symfony/* components), or it may still conflict on individual component versions. Either outcome is irrelevant: a successful install buys 100% dead code and a permanent "why is this here?" in the dependency graph.
• Feasible path is unchanged: extract assets + config into a first-party Blade component (<x-rich-text>), publishable config, and a thin upload controller. 1–3 engineer-days, largely independent of this repo.
• Effort remains dominated by editor concerns (upload endpoint, sanitization, CSP, content migration), not by the bundle.

Technical risk

• Adoption risk (high, unchanged): 0 stars, 0 dependents, no downstream validation. Still single-maintainer, still unproven in any production fleet we can observe.
• Maintenance risk (down from high to medium-high): the December 2025 "dead repo" read is now falsified — there is a contributor and a merged PR. But read the release carefully: a one-line dependency-constraint bump is installability housekeeping, not development. There is still no evidence of CI, test suite, changelog discipline, or a security policy. The package is being kept resolvable, not maintained.
• Release hygiene risk (new, medium): a Symfony major-version constraint change shipped as a patch (v3.0.5) is a compatibility break dressed as a bugfix. Any existing consumer on Symfony 5 gets silently cut off by a routine composer update. That is a semver-discipline signal, and it is the single most informative thing about this release.
• Security risk (medium-high, unchanged): WYSIWYG packages ship third-party JS with an independent CVE history. We inherit whatever TinyMCE build is vendored, with no assured upgrade path — and v3.0.5 provides no evidence of one.
• Licensing risk (low-medium, unchanged): confirm the bundled TinyMCE build's license and whether any premium/cloud plugins are referenced.
• Quality risk (reduced): the Symfony 7 constraint implies a PHP 8.2+ floor, so the earlier PHP-compatibility unknown is effectively resolved in our favour. This does not offset anything else.

Key questions to resolve before commitment

1. Which TinyMCE major/minor is vendored, and is it self-hosted or CDN-loaded? v3.0.5 does not touch the asset tree, so whatever was there is still there.
2. Does it include premium/commercial plugins or a cloud API key requirement?
3. Is the new contributor a one-off patch or a durable second maintainer — and did the constraint bump ship with any test run at all?
4. Does the bundle implement server-side upload handling, and if so, does it perform content-type/extension validation?
5. Who on our side would own a fork if we extract assets — and is a fork acceptable under our OSS policy?

Integration Approach

Stack fit

• Poor as a dependency, moderate as source material. The correct framing for planning remains "asset and pattern extraction," budgeted as a small internal build, not an integration project. v3.0.5 does not shift this.
• Preferred primary option: a Laravel-native editor integration (a maintained Blade/Vue/Livewire TinyMCE wrapper, or the editor's own npm package plus a first-party Blade component). Gives us npm/Composer version pinning, a real upgrade path, no framework-tax.
• Fallback option has narrowed: this bundle is now viable only for a Symfony 6/7 estate, and only for teams already on it. If we have such an estate, the TPM owner is that platform team, not the Laravel team. Note the patch-level constraint break means anyone adopting it must pin exactly.

Migration path If we proceed with extraction:

1. Audit — inventory Resources/public, config defaults, and any Twig helper logic; record the exact TinyMCE version. Still the gating step; v3.0.5 changes nothing here.
2. Extract — copy assets into resources/js/vendor/tinymce or a small private npm package; port defaults into config/editor.php.
3. Wrap — Blade component + a RichTextServiceProvider that publishes config and registers upload routes.
4. Secure — Laravel filesystem disks, MIME/extension allowlists, CSRF on the upload route, server-side HTML sanitization on render.
5. Harden — CSP with explicit script-src/img-src; smoke test asserting the editor boots and posts HTML.
6. Document — a one-page runbook: where the version is pinned, how to bump it, who reviews.

Compatibility

• Target PHP 8.2+ and the current Laravel LTS line. Do not attempt to consume the bundle. If any transitive Symfony package is needed, pin modern symfony/* components only, and do not let the bundle's constraint drive our graph — it is now a moving target at patch level, which is worse than a frozen one.
• Front-end: confirm the vendored editor build works with Vite; TinyMCE's runtime URL resolution for skins/plugins usually needs an explicit base_url.

Sequencing

• Sprint 1: decision spike (half-day audit) → confirm editor version, license, and that nothing non-portable is required. Go/no-go on extraction. The new release does not shorten this.
• Sprint 1–2: prototype the Blade component against extracted assets; validate upload + sanitization end-to-end.
• Sprint 2: CSP, tests, docs; pilot on one low-traffic authoring form.
• Sprint 3+: roll out to remaining forms; only then retire any legacy editor.
• Gate unchanged: if the vendored editor is more than one major version behind, skip extraction entirely and use the upstream npm package.

Operational Impact

Maintenance

• Ownership still transfers to us on day one. The new contributor and merged PR slightly improve the odds of an upstream fix landing, but there is still no release cadence, no security process, and no test suite to trust. Plan for fork-by-default; treat upstream presence as a bonus, not a dependency.
• Budget ~2–4 hours per quarter for editor version review in steady state, more in any quarter where TinyMCE ships a sanitizer or XSS advisory.
• The patch-level Symfony major bump is a caution for anyone tracking this repo: automated dependency updates or a composer update in a downstream project can change its platform contract without a minor version. If we ever do depend on it, pin exactly.

Support

• Still no vendor, no community, no issue-tracker signal beyond a single PR. Internal L1/L2 support only; every authoring-form bug routes to the owning squad with no escalation path.
• Named owner and a documented "how to bump the editor" procedure remain release gates.

Scaling

• Runtime cost negligible: client-side editor, single templated config block. Serve assets from a CDN or long-cache with content hashes.
• The real scaling risk is content, not throughput: rich-text fields accumulate HTML that later needs sanitizing, indexing, excerpting, and possibly migration to a structured model. Decide early whether stored HTML is canonical — far more consequential than editor choice.
• Uploads add object-storage growth and a moderation surface; size and rate limits are mandatory.

Failure modes

• Zombie dependency (replaces the old "dependency deadlock") — the constraint bump makes it plausible that someone successfully installs this into a Laravel app, sees no error, and assumes it works. Prevent by policy: extract, never require.
• Silent asset 404 — editor renders as a bare textarea; caught only by users. Mitigate with a boot smoke test in CI/staging.
• CSP violation — editor dies on strict script-src; needs explicit allowlisting and an eval-free build check.
• Stored XSS — untrusted pasted HTML surviving to render; requires server-side sanitization, not editor-side trust.
• Upload abuse — unrestricted MIME/extension or unauthenticated upload route; enforce allowlist, CSRF, auth, size caps.
• Stale editor — a multi-year-old TinyMCE build accrues known XSS advisories; v3.0.5 gives no indication of an upgrade path. Mitigate with the quarterly review.

Ramp-up

• Low for any mid-level Laravel engineer: the component is ~100 lines plus config; the JS surface is standard TinyMCE initialization.
• Symfony 6/7 knowledge in this repo is not transferable to our target and should not inform hiring or staffing.
• ~Half a day of onboarding for a developer comfortable with Blade and Vite; the real learning curve is sanitization and upload-hardening policy, which is organization-specific.

Recommendation to the decision owner Do not adopt as a dependency. v3.0.5 is a housekeeping release: it retires the "frozen Symfony2 artefact" objection and resolves the PHP-version unknown, but introduces a versioning-discipline concern and leaves every material risk standing — unknown editor version, no tests, no security process, no Laravel architecture fit. Approve the same half-day audit; if the vendored editor is current, extract assets + config into a first-party Blade component (1–3 days) and proceed; if it is stale, go straight to the upstream npm distribution. The composite score moves marginally upward on maintenance and unchanged everywhere else; readiness for a Laravel target remains low.