Checkboxes Field Type Laravel Package

Product Decisions This Supports

• Field-level data modeling for content and records. Whether a multi-select attribute (tags, categories, product features, interest areas, risk flags) is a first-class field type in your CMS/back-office, rather than free text or a single-select enum. This package is a concrete answer someone already shipped.
• Build vs. buy on admin form primitives. A checkbox group is deceptively expensive: serialization shape, pivot vs. JSON storage, validation ("at least one", "max N"), ordering, default handling, search/filter integration, and API output shape. This is a worked reference implementation of how those decisions were resolved inside one ecosystem.
• Roadmap scoping for an internal attribute/form builder. It clarifies what a mature field-type abstraction actually consists of — a registration contract, a storage convention, a UI view, and a validation profile — which is directly reusable as a design sketch even off-stack.
• Multi-facet filtering and "any of" query semantics. Checkbox selections produce OR-style filters. Relevant when deciding whether browse/search supports faceted filtering and how selections map to query clauses.
• Concrete use cases it serves: content taxonomy and tagging, product attribute matrices (sizes, materials, colors), survey/form multiple-choice, per-record preference and notification toggles, and permission/role-set assignment.
• Deprecation and migration planning. Because a field type is a discrete addon, it makes the blast radius of retiring a taxonomy legible: the storage column or pivot, the admin view, and the validation rules. Useful input to a data-model exit strategy.

When to Consider This Package

Consider it only if:

• Your application is already on Laravel with the Anomaly Streams Platform / PyroCMS 3.x, where field types are the sanctioned extension point and this drops in as one.
• You need an admin-editable multi-value boolean set on a stream entry and would otherwise hand-roll the input, hydration, and validation.
• You want a small MIT-licensed reference for how a Streams field type is structured (service provider, field type class, view, configuration) before writing your own.

Look elsewhere if:

• You are not on the Streams Platform. This is not a general Laravel package; it is a host-specific plugin with no value outside it. Zero stars, zero dependents means no community support, no issue triage, and no upgrade path.
• You need a maintained dependency. Treat this as vendored sample code you own, not a third-party library with a support contract.
• You need real relations, ordering, or cross-entity querying. If selections must join, sort, or aggregate across entities, a dedicated taxonomy/relation package or first-party Laravel modeling will serve far better.
• You need rich interaction. Search, "select all", chips, async-loaded options, and keyboard accessibility will require rebuilding the view regardless, which erases most of the savings.

How to Pitch It (Stakeholders)

Executives. This is a small, free (MIT) building block for one specific CMS stack we may or may not adopt. Evaluation costs nothing and walking away costs nothing. Its value is the pattern rather than the code: it demonstrates how to add a reusable multi-select attribute to an admin system, a decision we will face in any content or back-office tooling we build. It is unmaintained with essentially zero adoption, so it should not appear in a dependency inventory as a supported library.

Engineering. If we land on the Anomaly Streams Platform, this gives us the checkboxes field type for free — admin rendering and value handling included — and it doubles as a template for the three or four bespoke field types we will inevitably need. If we are not on Streams, do not lift the code: read it, take the structure (field type contract, storage convention, validation profile, view boundary), and implement it against our own abstraction. Either way, budget for owning it — no maintainer, no dependents, no upgrade path.