Text Field Type Laravel Package

Product Decisions This Supports

• Feature-level build-vs-buy on a legacy CMS. This is a single-purpose addon that registers a plain text input as a Streams Platform field type. If you are running PyroCMS 3.x / Anomaly Streams, it answers a narrow but concrete question: do we write our own field type, or do we adopt one? For "plain text," adopt — re-implementing it is pure waste.
• Scaffolding a bespoke field type. The more valuable product use is as a reference implementation. The package lays out the full addon contract in miniature: service provider, FieldType subclass, config/lang/views, Twig input view. That makes it a template for a differentiated field type (license key, SKU, slug-with-preview, external ID) where the actual product value lives. Estimate: hours, not days, to fork the pattern.
• Roadmap/capacity estimation. Because the marginal cost of a new field type in this stack is low, "add a field to the admin form" should be treated as a cheap, reversible increment on the roadmap — not an initiative. That has a real effect on prioritization: field-level requests shouldn't displace higher-leverage work.
• Platform direction signal (negative). 0 stars, 0 dependents, and a low composite score are not a verdict on this file's quality — it's trivial code — but they are a read on the ecosystem's health. This supports the strategic decision to stop deepening investment in the Streams addon layer and to evaluate a migration path rather than commission new addons.
• Use cases it explicitly does not support: rich text, structured input, validation-heavy forms, or anything customer-facing. Those need sibling field types, and using a plain text field as a stand-in is a common and costly shortcut.

When to Consider This Package

Consider it when all of the following hold:

• You are already on Anomaly Streams Platform / PyroCMS 3.x and the addon layer is a load-bearing part of your admin.
• You need a plain single-line text field, or you need a minimal, MIT-licensed example to onboard an engineer onto the field-type contract.
• You are comfortable treating it as vendored reference code — read it, fork it, or copy the pattern — rather than as a maintained dependency.

Look elsewhere when:

• You are not on Streams. Laravel Nova, Filament, Backpack, Statamic, and Craft all ship first-party text fields; adopting anything here would be a net-new platform commitment for a commodity input.
• You need real input semantics. Use the appropriate sibling field type (textarea, WYSIWYG, choice) rather than stretching a text field.
• You require a support contract or security response. Zero dependents and zero stars means no community backstop and no upgrade path. There is no one to escalate to, and no evidence anyone has run this against a recent Streams release.
• Your org has a dependency-review gate. A package with no downstream consumers and no release cadence will typically fail provenance/vetting — correctly. Route it as a code sample, not as a composer require.
• The maintenance burden of the host platform is already in question. Adding addons to a dormant CMS compounds sunk cost. That is a migration conversation, not an addon conversation.

How to Pitch It (Stakeholders)

To executives — one paragraph:

This is a small, MIT-licensed component that adds a text box to the admin panel of our CMS. It is not a strategic asset and we should not treat it as one. Its value to us is informational: it shows that adding a field to our current admin costs hours, and it shows that the surrounding open-source ecosystem is effectively dormant — no downstream users, no visible maintenance. The recommendation is no new investment in this addon layer; if we need new admin capabilities, we should price them against a modern Laravel admin stack (Nova or Filament), where the equivalent is a first-party feature rather than a community addon. Low cost, low risk either way, but the strategic read is to stop building here.

To engineering — the short version:

anomaly/text-field_type is the canonical minimal Streams field type: a service provider plus a FieldType subclass and a Twig input view. Treat it as a template, not a dependency. Two concrete uses: (1) copy the structure when we need a differentiated field type — that's a same-day task; (2) use it as the onboarding artifact for anyone new to the addon architecture. If we do pull it in, pin the version and vendor it, because there is no maintainer to page and no dependents to surface regressions. Do not extend it for rich input — use the dedicated field types. And flag it in the dependency review as reference-only so it doesn't accrete into our production surface by default.