Ckeditor Lineutils Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the premise needs correcting. This is not a Laravel package. stinger/ckeditor-lineutils-bundle is a Symfony2 bundle: composer type symfony-bundle, with a DependencyInjection/*Extension.php, a *Bundle.php kernel class, and the actual payload sitting as static JS under Resources/public/. Laravel has no bundle registration mechanism, so roughly 80% of the package (the bundle plumbing) is dead weight the framework will never invoke. The only reusable artifact is the vendored CKEditor 4 lineutils plugin source.

What the dependency actually does. LineUtils is a support plugin, not a feature. It provides CKEDITOR.plugins.lineutils — the positioning/drag-line helpers consumed by Widget, drag-and-drop, and placeholder plugins. Users never toggle it on. That means adopting this package buys you no user-visible capability; it buys you a copy of a file that ships inside every full CKEditor 4 build anyway.

Integration feasibility. composer require will succeed and autoload nothing useful. The realistic integration is: install, then copy Resources/public/plugins/lineutils into public/vendor/ckeditor/plugins/, and configure extraPlugins=lineutils,widget in the editor init. That is a manual, undocumented-in-Laravel workflow — acceptable as a one-time vendor drop, unacceptable as a maintained dependency.

Technical risk — high.

• Abandonment. Symfony2 reached end of life in 2018; PHP 5.x-era constraint sets will conflict with PHP 8.2/8.3 and Composer 2.7 dependency resolution. Expect --ignore-platform-reqs hacks, which cascade into CI noise.
• Zero validation. 1 star, 0 dependents. No test suite, no CI badge, no issue history to mine for known breakages. Effectively a single-author mirror repo.
• Version coupling. LineUtils is tightly bound to CKEditor 4 core internals and breaks silently across minor CKEditor bumps. There is no compatibility matrix published.
• Licensing. MPL-2.0 is file-level copyleft: fine for consumption, but any patch you apply to those files must be published. That is a governance obligation most teams don't track; it also means the correct mitigation is "don't patch, fork and publish" or "don't fork."
• Platform lifecycle. CKEditor 4 is in extended/LTS support territory and CKEditor 5 uses a completely different plugin architecture with no LineUtils equivalent. Any bet here has a hard expiry date.

Key questions for the team.

1. Do we actually need LineUtils as a separate plugin, or does our CKEditor 4 build already bundle it (it does in standard-all/full presets)?
2. Is our editor on CKEditor 4 or 5? If 5, this package is irrelevant and the ticket closes.
3. Who owns MPL-2.0 compliance if we ever modify the vendored file?
4. Why is a Symfony bundle under consideration in a Laravel codebase — is there a hidden Symfony service in the stack, or is this a legacy-copy-paste artifact?
5. What is our supported PHP matrix, and does anything in our monorepo still run Symfony 2?

Integration Approach

Stack fit: reject as a Composer dependency; adopt as a vendored asset at most. Two acceptable paths, in preference order:

1. Preferred — use the first-party distribution. CKEditor 4 ships LineUtils in its standard-all/full builds, and ckeditor/ckeditor4 is installable via npm. Add it to the Vite/package.json pipeline, reference the built asset from a Blade partial, and configure extraPlugins. No PHP dependency, no MPL surface, no abandoned-repo risk, and the plugin version is guaranteed to match core.
2. Fallback — deliberate vendor drop. If a network-isolated build or an existing pinned CKEditor copy forces it, copy the plugin directory once into public/vendor/…, commit it with the MPL header intact and a PROVENANCE.md recording upstream commit, date, and reason. Do not list it in composer.json; do not register a service provider.

Migration path (if already installed). Remove from composer.json → confirm vendor/stinger is gone → verify public/ assets still resolve (they will, if they were copied rather than symlinked) → replace any Symfony-style asset reference ({{ asset('bundles/stingerckeditorlineutils/...') }} equivalents) with asset('vendor/...') → delete the residual config.

Compatibility. If the install stays, pin PHP via config.platform in composer.json rather than contorting the repo; otherwise Composer will attempt to satisfy a PHP 5.x constraint against a PHP 8 runtime and either fail or downgrade something you care about. Keep CKEditor core and the plugin on identical version numbers — mismatched LineUtils is the single most likely source of subtle drag-handle breakage.

Sequencing.

1. Confirm editor major version and whether LineUtils is already present in the build (30 min spike, resolves 60% of the risk).
2. Decide build-vs-vendor; default to npm ckeditor4.
3. If vendoring: land the asset move in one PR with no behavioral change, so editor regressions are attributable.
4. Add a smoke test asserting the editor initializes and CKEDITOR.plugins.get('lineutils') is truthy.
5. Document the CKEditor 4 → 5 migration trigger in the tech-debt register with an owner and a review date.

Operational Impact

Maintenance. Effectively zero upstream maintenance; all maintenance cost is yours. Budget it as frozen vendor code, not as a dependency. The composer entry, if kept, will generate recurring Dependabot/Snyk noise and platform-requirement failures that someone must triage every quarter.

Support. There is no support channel — no active issues, no maintainer responsiveness, no CVE feed. Security posture is "unaudited JavaScript executing in an authenticated admin context," which is a real consideration for any CMS-facing editor surface (paste-handling and upload paths in CKEditor 4 have historically been the interesting attack surface, not LineUtils itself).

Scaling. Non-issue technically — it is a client-side static file with no runtime, no DB, no queue, no cache interaction. It scales exactly as well as your CDN does. The scaling concern is organizational: N copies of a vendored plugin across N apps is N upgrade problems.

Failure modes.

• Silent: CKEditor core upgrade changes plugin-loading order; LineUtils fails to register; widget drag handles vanish. No error, no alert — discovered by an editor user.
• Noisy: composer install fails on PHP constraint after a base-image upgrade; CI goes red; engineer reaches for --ignore-platform-reqs and disables the guardrail repo-wide.
• Licensing: an engineer patches the vendored JS for a browser quirk and never republishes — MPL-2.0 non-compliance, discovered in diligence.
• Asset pipeline: public/bundles/ symlink assumptions break when the project moves to Vite or a containerized build with a read-only vendor/.

Ramp-up. Near-zero to consume (copy folder, add extraPlugins), moderate to own correctly (understanding CKEditor 4 plugin lifecycle, the widget dependency graph, and MPL obligations). Realistically half a day for a mid-level engineer to integrate; the harder skill is recognizing that this package should not have entered the dependency graph, which is a review-process finding rather than an engineering one.

TPM recommendation. Do not adopt as a tracked dependency. Route to the CKEditor npm package or a documented one-time vendor drop, close the MPL question by not modifying upstream files, and flag the underlying pattern — Symfony2-era bundles being evaluated for a Laravel stack — as a recurring intake-quality issue worth a checklist item at the architecture-review gate.