Variables Module Laravel Package

Product Decisions This Supports

• Build vs. buy for editable content. The core decision this package informs is whether to build an internal "settings + content snippets" admin system or take one off the shelf. Variables (key/value content entries backed by the Streams field-type system) let non-engineers change footer copy, contact details, social links, analytics IDs, hero text, and image assets without a deploy.
• Platform commitment. Adopting this is not adopting a package; it is adopting the Anomaly/Streams Platform. That's the real roadmap decision — is the Streams ecosystem a foundation worth standardizing on, or a dependency we want to avoid?
• Roadmap pressure on releases. Content-only changes currently bundled into a release cycle can be moved to runtime edits. That reduces release frequency for copy tweaks and unblocks marketing without engineering tickets.
• Feature triage. It gives a concrete estimate of what a "typed variables" feature costs you: field-type validation, admin UI, translations. If the team is scoping a settings screen, this is a reasonable reference implementation to compare against building it.
• Use cases it fits: site-wide configuration surfaced in templates, client-editable marketing blocks, per-locale content strings, structured-but-simple values (booleans, selects, images) rather than raw string blobs.

When to Consider This Package

Consider it when:

• You are already running the Streams Platform / PyroCMS and need admin-editable variables that participate in the existing field-type system (text, wysiwyg, image, select, etc.) rather than a flat settings table of strings.
• You need variables to be translatable and validated per field type, with the platform's storage and admin conventions for free.
• You are prototyping on that stack and want the feature without writing schema, migrations, and admin screens.

Look elsewhere when:

• You are not on the Streams Platform. Pulling in a CMS framework to get a settings table is a large, permanent coupling for a small feature. Use spatie/laravel-settings, a small key/value model with a Filament/Nova page, or config + a settings model.
• You need maintenance guarantees. Zero stars, zero dependents, single-vendor, no visible community or third-party security review. Treat the 0.33 score and 0 dependents as a signal that no one else is exercising this code path. Verify last commit date, PHP/Laravel version constraints, and test coverage before spending an afternoon on it — the constraints are very likely pinned to older Laravel majors.
• You need an SLA or long-term support. If it's genuinely the right fit, pin the version, fork it internally, or vendor the handful of classes you actually use.
• You only need static strings. Language files or a flat CMS handle this without a module.

How to Pitch It (Stakeholders)

For executives: This is a small plugin in a niche CMS ecosystem that lets non-technical staff edit site text, settings, and image assets without engineering involvement. It's MIT-licensed and free, but it has effectively zero independent adoption and one vendor behind it — so using it is really a decision to standardize on that CMS platform, not a decision to install a utility. Recommendation: do not adopt it standalone. If we're already on that stack, it's a low-cost win; if we're not, a one-day internal settings table or a maintained package covers the same need with far less lock-in.

For engineering: It's an AnomalyLabs Streams Platform addon — variables are stored as typed stream entries with an admin UI, sitting on top of streams-platform core and its migrations. The functionality is thin; the coupling is the whole cost. No community signal, no dependents, no obvious test suite — audit its Composer constraints against our Laravel/PHP versions before investing time. If the actual requirement is "typed, admin-editable settings," spatie/laravel-settings plus a Filament page is the lower-risk path. If the requirement is "we're on Streams anyway," take it and pin the version.