Addon Field Type Laravel Package

Technical Evaluation

Architecture fit. This is not a general-purpose Laravel package — it is an Anomaly Streams Platform addon that contributes a field type. It implements the platform's field type contract, registers itself through an addon service provider, and renders a dropdown whose options are the addons installed on the system. At render/persist time it resolves the selected addon identifier through the platform's addon registry/collection. Fit is therefore binary: high if the target application already runs Streams/PyroCMS, zero for any other Laravel stack (Nova, Filament, plain Blade, Livewire, etc.).

Integration feasibility. Composer-installable, MIT-licensed, and small in surface area. Two prerequisites drive feasibility: (1) a compatible platform version per its composer.json constraints, and (2) working addon discovery/registration in the target environment — some Streams setups require explicit registration rather than autodiscovery. Because the field's option list is sourced from the live addon registry, it only behaves correctly on environments where the full addon set is installed and enabled.

Technical risk. The adoption signal is effectively nil: 1 star, 0 dependents, overall score 0.275 and an opportunity score in the high twenties. That is a single-vendor, low-activity artifact. Principal risks: abandonment and no compatibility work for newer PHP/Laravel/platform majors; no visible test coverage; dependence on internal platform APIs that are not part of a stable public contract; dangling references when a previously selected addon is later disabled or uninstalled; and an option list that may be global rather than scoped, leaking addon names into contexts where they shouldn't appear.

Key questions.

• Which Streams/PyroCMS and PHP/Laravel versions are supported, and is there a tagged release compatible with our platform version?
• What exactly is persisted — addon namespace, slug, or ID — and what is the failure behavior if that addon is later removed?
• Does it support localization, required/validation rules, configurable option filtering (e.g., only certain addon types), and multiple selections?
• Who maintains it, what is the release cadence, and what does the open issue/PR backlog look like?
• Is there a first-party alternative — a native select field type with a custom options handler, or a lookup field type — that eliminates the dependency entirely?

Integration Approach

Stack fit. Adopt only if the application is already an Anomaly Streams/PyroCMS deployment. Any other stack should treat this as not applicable; pulling it in would create a dead dependency with no runtime value.

Migration path. The default recommendation is to not adopt and instead reproduce the behavior with a native select/dropdown field whose options are supplied by application code (a small options handler or a config-driven list of addon identifiers). If the addon is already in the codebase, plan a replacement — either a local field type in our own namespace or a forked copy pinned under our vendor control — before the next platform upgrade cycle.

Compatibility. Pin an exact version, verify the constraint matrix against our PHP runtime, and confirm registration mechanics in each environment (local, staging, production). Treat the addon registry as an external dependency that must be present before the field is usable.

Sequencing.

1. Spike on a throwaway branch: install, register, create a test field, verify persistence, admin rendering, and front-end rendering.
2. Test upgrade resilience: bump the platform a minor version and confirm the field type still resolves.
3. Make the build-vs-adopt decision: adopt as-is, fork and maintain internally, or replace with a native field type.
4. If adopted, lock the version, document the manual registration steps, and add a smoke test that creates and renders the field so breakage is caught in CI.

Operational Impact

Maintenance. Low code volume but non-trivial ownership cost. With essentially no community around it, we own the maintenance by default — assume periodic compatibility patching and likely a private fork if the field becomes business-critical.

Support. GitHub issues only, with uncertain response latency and no commercial backing. The realistic escalation path is reading the source and patching locally, so at least one engineer must be able to reason about the addon's internals.

Scaling. Not a concern. This is an admin-side form field; cost is bounded by an addon registry lookup, which should already be cached by the platform. It will not be a bottleneck at any realistic scale.

Failure modes.

• Addon not discovered or registered → class-not-found or the field type simply unavailable in the field picker.
• Empty option list (no addons installed/enabled) → unusable field with a confusing UX.
• Referenced addon later disabled or uninstalled → dangling stored value and broken render on edit.
• Platform upgrade changes the field type contract → fatal error on form render, potentially blocking content editing.
• Unscoped option list → unintended addon names exposed to editors.

Ramp-up. A developer needs working knowledge of Streams addon architecture — service providers, field type contracts, presenter/view layers, and the migration that assigns the field to a stream. Roughly half a day for someone already fluent in the platform, materially longer for anyone new to it. Capture the field's configuration, the addon-registry dependency, and the uninstall/upgrade caveats in the team runbook so the knowledge doesn't live with a single engineer.