Editor Field Type Laravel Package

Technical Evaluation

Architecture fit anomaly/editor-field_type is not a standalone Laravel library in the conventional sense—it is a field type addon for the Streams Platform (the data-modeling layer behind PyroCMS/Anomaly CMS). Its job is narrow and well-defined: register a WYSIWYG "editor" field type with the Streams field-type registry so that entries defined in the control panel render a rich-text input and serialize HTML (or editor JSON) into a column. It almost certainly depends transitively on anomaly/streams-platform and on the companion anomaly/editor addon for JS/CSS asset registration and publishing.

That means the fit test is binary, not graded. If the target application is a Streams/PyroCMS installation, this is a legitimate, idiomatic addon that slots into the existing addon loader, service provider bootstrapping, and field-type contract. If the target application is any other Laravel codebase—including a modern Laravel 10/11/12 app—there is effectively no architecture fit at all. This package does not offer a generic "give me a rich text field for my Blade form" API; you cannot meaningfully consume it outside the Streams addon lifecycle.

Integration feasibility Feasibility is dominated by dependency resolution, not by code complexity. The package is a thin wrapper: a service provider, a field type class implementing Streams' FieldType contract, a form view (likely a Blade partial loading editor JS), and language/publishable assets. The integration work is therefore mostly Composer surgery and asset publishing rather than application code. Expect PHP version constraints that predate PHP 8.1/8.2 hardening and Laravel constraints that will not satisfy current framework releases; an install attempt against a fresh Lumen/Laravel skeleton should be treated as the first, gating experiment, not an afterthought.

Technical risk The material risks are lifecycle and supply chain, not runtime:

• Abandonment. Zero stars and zero dependents on a package whose parent ecosystem (Anomaly Labs/PyroCMS 3) has been effectively dormant for years. There is no realistic upstream patch path for PHP deprecations, Laravel upgrades, or security fixes.
• Transitive coupling. The real dependency surface includes the Streams Platform and the anomaly/editor asset addon. Any one of those being unmaintained or unpinned undermines the whole install, and you inherit the aggregate risk of the deepest node.
• Rich-text trust boundary. A WYSIWYG field type stores and re-renders user-authored HTML. The package's own sanitization posture is unknown and is unlikely to reflect current best practice. XSS defense must be assumed absent until proven otherwise and enforced at output time.
• Editor JS provenance. The bundled or referenced editor library (Redactor, CKEditor, TinyMCE, etc.) is an unpinned, likely end-of-life front-end dependency with its own CVE history.

Key questions

1. Is the target system already running Streams/PyroCMS, or is this being evaluated for a greenfield Laravel app? (If the latter, stop.)
2. Which editor JS engine does it wrap, at what version, and is that engine still maintained?
3. Does the field type sanitize stored HTML server-side, or is sanitization delegated entirely to the client?
4. What are the exact composer.json constraints on php, laravel/framework, anomaly/streams-platform, and anomaly/editor, and do they resolve against our PHP runtime?
5. Is there an internal commitment to own a fork, and who signs for that maintenance burden?

Integration Approach

Stack fit Fit is conditional and ecosystem-specific. In a Streams-based CMS the addon is a first-class citizen: it registers through the platform's field-type service provider, appears automatically in the field-type picker, and requires no application-level wiring beyond asset publishing. In a conventional Laravel application (Eloquent models, resource controllers, Blade/Livewire/Filament forms) the package is inert. For those stacks the correct equivalent is a maintained in-application editor component—Filament's RichEditor, a Livewire-bound Trix/CKEditor/TipTap component, or a dedicated sanitization-plus-editor pair—not a CMS field-type addon.

Migration path There is no migration path into this package from a non-Streams application, and that is the central finding. The realistic paths are:

• Already on Streams: vendor the repository, pin to an exact commit or a private tag, and treat it as internal code. Do not rely on Packagist resolution.
• Evaluating Streams for a new build: reject on ecosystem-vitality grounds and select a maintained CMS/Laravel admin stack instead. The opportunity score of 33.82 reinforces that adopting this pulls you toward an unsupported platform, not away from one.
• Legacy Streams install needing an editor field: adopt, fork, and schedule replacement as part of the broader platform exit.

Compatibility Assume incompatibility with current PHP and Laravel releases until a sandbox install proves otherwise. Check composer.json constraints directly; a php: ^5.6|^7.0 style constraint will hard-fail on PHP 8.2+. Also verify the anomaly/editor asset addon resolves and that its published JS assets are still retrievable—if assets were fetched from a third-party CDN at build time, the field type can render a dead input while remaining "installed."

Sequencing

1. Dependency probe: attempt install into a disposable container matching the target runtime; record resolution failures verbatim.
2. Contract audit: read the field type class and form view; identify the editor engine, asset source, and any server-side sanitization.
3. Fork and pin: create an internal mirror, add explicit version constraints, and freeze the transitive tree.
4. Security gate: add server-side HTML sanitization (e.g., an allow-list sanitizer) at the persistence or render boundary, independent of the package.
5. Asset publication smoke test in staging, including a cold deploy with an empty public/ directory.
6. Only then wire into content models and author training.

Operational Impact

Maintenance This is a permanent fork obligation, not a dependency you consume. Budget for: annual PHP/Laravel compatibility shims, editor JS upgrades or freezes, and Composer constraint upkeep as the surrounding tree moves. Because the upstream is dormant, "maintenance" here means "ownership"—the package is effectively internal source code with a public origin story. Estimate the ongoing cost as low in hours but non-zero forever, which is often worse organizationally than a large one-time cost.

Support No vendor support, no active issue triage, no security advisory channel. Internal runbooks must cover: where the fork lives, who may bump it, how the editor assets are built and served, and what the sanitization policy is. On-call engineers will not be able to reason about this package from public documentation alone; write the runbook at adoption time or the knowledge will not exist later.

Scaling Runtime scaling is a non-issue: a field type is a form-rendering concern executed on control-panel requests, not on the hot path of a public API. The scaling concerns are data-shaped rather than compute-shaped. Rich-text fields accumulate large HTML payloads per row, inflating table size, backup windows, and replication lag; and they are hostile to full-text search unless the rendered text is separately extracted and indexed. If the field stores editor JSON rather than HTML, plan for a rendering step and a schema-version field, since editor upgrades silently change the document format.

Failure modes

• Asset pipeline failure. Editor JS/CSS not published or not served → the field renders as a blank or unusable textarea. Most likely first incident on a new deploy target.
• Composer resolution break. A routine composer update in an unrelated package pulls a constraint that makes the addon uninstallable; the build fails at the worst time.
• PHP/Laravel upgrade wall. Framework upgrade is blocked; the addon becomes the reason a platform refresh is deferred.
• Stored XSS. Unsanitized HTML persisted through the editor and rendered to lower-privileged users or the public site.
• Silent content corruption. Editor version change alters the stored document schema; content still "saves" but renders incorrectly.
• Abandoned transitive dependency. anomaly/editor or the Streams Platform itself becomes the unpatchable node.

Ramp-up For an engineer already fluent in Streams addon conventions—service provider registration, the FieldType contract, asset publishing, control-panel views—ramp-up is a few hours; the code surface is small and the patterns are familiar. For anyone else, the cost is not this package but the platform: understanding Streams' entry/field/assignment model, the addon loader, and the control-panel view layer is a multi-week investment before this addon's behavior is legible. That asymmetry is the practical argument against adoption: you are paying platform-sized onboarding costs to obtain a rich-text input, which is the single most commoditized component in the Laravel ecosystem.