Language Field Type Laravel Package

Technical Evaluation

Architecture fit. This is not a general-purpose Laravel package — it is a Streams Platform field type addon for PyroCMS 3.x. It plugs into Anomaly Labs' field type contract (a FieldType class plus a FieldTypePresenter and a form view), and its single responsibility is rendering a language selector populated from the anomaly/languages-module repository. It has no meaning outside a PyroCMS/Streams application: there is no service provider for stock Laravel, no config publish, no standalone usage path.

Integration feasibility. Feasible only if the target application is already a PyroCMS 3.x install with the Languages module present. In that context it is a composer require plus addon registration — genuinely low effort. In any other Laravel context (Nova, Filament, Livewire, plain Blade), the cost of adoption is effectively the cost of adopting PyroCMS, which is a platform decision, not a package decision.

Technical risk — high, and concentrated in the "unowned code" category.

• Adoption signal is absent. 0 stars, 0 dependents, score 0.15. There is no evidence of production use anywhere, which means no de facto test coverage from the field.
• Ecosystem decay. PyroCMS 3.x sits in the Laravel 5.x–6.x / PHP 7.x era. A package this small will not be independently updated for PHP 8.2+ or Laravel 10/11, and its transitive anomaly/* dependencies carry the same risk.
• Upstream fragility. The field type binds to internal Streams view namespaces and the Languages module's repository API. Both are internal contracts that can shift on a minor PyroCMS release.
• Blast radius is small, though. It is a form input that persists a language code/reference. Worst case is a broken admin form field, not data corruption or an outage.

Key questions before committing.

1. Are we already running PyroCMS 3.x? If no, this package is out of scope and the conversation is really "do we want PyroCMS."
2. Which PyroCMS/PHP/Laravel versions are pinned, and does the constraint graph resolve without --ignore-platform-reqs?
3. Is anomaly/languages-module installed and seeded, or does this field type have nothing to read from?
4. Does a native select / enum field type already satisfy the requirement? For most teams the honest answer is yes — a language picker is a static list.
5. If we adopt it, who forks it? Assume we own maintenance from day one.

Verdict: a ~200-line convenience addon with real, if bounded, technical risk. It is defensible only as a zero-cost add-on inside an existing PyroCMS estate; it is not defensible as a reason to adopt anything.

Integration Approach

Stack fit. Narrow. Supported target is PyroCMS 3.x (Streams Platform) with the Languages module. It is not a fit for standard Laravel, and it is not a fit for any headless or API-first architecture, since its value is entirely in the admin form view.

Migration path.

• Already on PyroCMS: add to composer.json, register the addon, ensure the Languages module is installed first, then assign the field type to the relevant stream/field. Hours, not days.
• Not on PyroCMS: do not migrate toward this. The equivalent capability is a select field with a static options array, a small languages lookup table, or the native select in Filament/Nova. Reimplementing the behavior is a fraction of the cost of importing the platform.
• Escaping PyroCMS later: because the field persists a language identifier, data migration to a plain column is straightforward — low lock-in at the data layer even if the platform lock-in is high.

Compatibility. Verify the three-way alignment of PyroCMS version, anomaly/languages-module version, and this package's constraints; they are released independently and are not co-versioned. Confirm autoload namespace (Anomaly\LanguageFieldType\) resolves after install — namespace mismatches on old addons are the most common install failure. Watch for illuminate/* constraint conflicts if the host app has drifted forward.

Sequencing.

1. Confirm PyroCMS 3.x and capture PHP/Laravel version pins.
2. Install and seed the Languages module — the field type is useless without it.
3. Add anomaly/language-field_type, run composer update in a branch, confirm the resolve.
4. Register/enable the addon and clear caches.
5. Assign to a test stream, render the admin form, save, and re-render via the presenter.
6. Only then promote to a real stream, with a rollback plan (revert field assignment) ready.

Operational Impact

Maintenance. Nominal steady-state effort is near zero. The realistic number is higher: treat this as vendored code we now own. Budget a fork, a composer VCS/path repository entry, and roughly 4–8 hours per PyroCMS upgrade cycle to re-verify the field renders and the presenter resolves. If the org cannot commit that, do not adopt.

Support. Community-only. No vendor, no SLA, and the repository shows no maintenance velocity — expect issues to go unanswered. Internal escalation path is "read the source," which is feasible here precisely because the package is tiny.

Scaling. Non-issue. It is a form input; runtime cost is a single repository lookup per form render, and storage is one column. It scales exactly as well as the admin UI around it, which is to say it is not on any hot path. If the language list is large, the dropdown is the only scaling consideration, and that is bounded.

Failure modes to plan for.

• Languages module absent or unseeded → silently empty selector; users save nothing and no error surfaces. Guard with a smoke test.
• Presenter returns a raw code or null when the referenced language is later deleted or disabled — display-layer rot that appears long after launch.
• Streams view-namespace changes on platform upgrade → form field fails to render, blocking content editors (highest-severity realistic failure, because it is an admin-blocking failure).
• Composer constraint conflict on upgrade → install/upgrade friction that surfaces at the worst time.
• Package disappears or repo is archived → mitigated entirely by forking on day one.

Ramp-up. For a developer already fluent in PyroCMS/Streams field types: a few hours. For a Laravel-only team: days, and the learning is in Streams concepts (streams, assignments, field types, presenters), not in this package — which is the real argument that this dependency is not worth the on-ramp unless the platform is already paid for.