Email Field Type Laravel Package

Product Decisions This Supports

• Build vs. buy for admin form plumbing. This package answers a narrow question: should we hand-roll an email input on a Streams entry, or take a ready-made field type? It's a small "buy" (MIT) with near-zero cost and near-zero strategic weight.
• Data quality at the point of entry. Adopting it commits us to validating email addresses at write time (on stream save) rather than downstream in reporting or CRM sync — a decision that shifts cleanup work left but can block bulk imports of messy contact data.
• Standardization across admin surfaces. Using one canonical field type prevents each team from reimplementing email inputs and validation differently in contact records, subscriber lists, and profile fields.
• Vendor and dependency policy. With zero stars and zero dependents, this is a live test case for our threshold on adopting unmaintained code — it either becomes a vendored internal module or a precedent we don't want to set.
• Roadmap scoping for the CMS layer. If we plan to move off the Streams Platform/PyroCMS, this adoption is throwaway work; that dependency is the actual decision here.

When to Consider This Package

Consider it when all of the following hold:

• The product is already running on the Anomaly Streams Platform (PyroCMS 3.x) and field types are the established extension point.
• We need a validated email field in the stream builder and want consistent render/validate/store behavior without bespoke code.
• We accept that we will own the source: fork or vendor it, pin the version, and add our own tests.

Look elsewhere when:

• You're not on Streams. The package has no meaning outside that platform — it's not a general Laravel email utility.
• Your application is plain Laravel. A string column, Laravel's email validation rule, and a Blade input cover this in roughly fifteen lines. The abstraction costs more than it saves.
• You need more than a single validated address: multi-value email arrays, double opt-in/verification flows, IDN or case normalization, deliverability checks, or mailto rendering with display names.
• You require active maintenance or security response. No stars, no dependents, no community signal, and a low overall score mean no one is watching this code but us.

How to Pitch It (Stakeholders)

To executives: This is glue code, not a product bet. It's MIT-licensed, costs nothing to adopt, and saves a few hours of boilerplate on a single field type inside one CMS. The risk is also small but real — the package is effectively unmaintained, so we should treat any code we take as our own. Approve it only as a time-saver, never as a strategic dependency.

To engineering: It's a thin field-type adapter for the Streams Platform: it registers an email field, renders the input, and applies email validation on save. Expect to vendor and own it. Don't take a runtime dependency on an unmaintained package with no dependents — copy it in, pin it, and write the tests it doesn't have. If we're staying on Streams, this is a reasonable few hours saved; if we're leaving, skip it and hand-roll the field.

Recommendation: Adopt only as vendored code inside an active Streams deployment; otherwise decline and use Laravel's built-in validation.