Streams Distribution Laravel Package

Technical Evaluation

Architecture fit. This is a distribution/metapackage, not a library. Its job is to pin and co-install the Streams Platform core plus a canonical set of first-party addons so that composer require anomaly/streams-distribution yields a coherent, version-aligned Streams runtime. That means it contributes almost no business logic of its own — the architectural decision it forces is not "should we add this package" but "should we adopt the Streams data-modeling paradigm" (streams, fields, assignments, addons) instead of hand-rolled Eloquent models and migrations. For a standard Laravel service, that is a poor fit. For a CMS-like or low-code admin surface where non-developers define content types, it is a strong fit and saves weeks of building a field engine.

Integration feasibility. Composer-installable and presumably auto-discovered via Laravel package discovery. The real gate is not installation but surface area: Streams brings its own control panel, its own routing/views layer, and its own database tables. This is a platform adoption, not a dependency addition. Budget for a spike in a throwaway Laravel skeleton before any commitment.

Technical risk. High, driven almost entirely by project health rather than code quality. Three stars and zero dependents is effectively no community signal; the entire support surface is one small vendor. Distribution packages are the most brittle class of Composer package — any upstream constraint conflict in streams-platform or a bundled addon blocks the whole upgrade, and you cannot selectively advance one component. Assume the distribution lags core releases.

Key questions.

• Is this strictly a metapackage, or does it ship installers, service providers, or migrations we inherit?
• Which anomaly/streams-platform version range and which Laravel/PHP versions are pinned? Does it support Laravel 10/11 and PHP 8.2+?
• Does installation force the Streams control panel into our app, and can it be disabled or IP-restricted?
• What is the vendor's release cadence and stated support window? Is there a paid support tier?
• If the vendor stops maintaining this, can we drop to streams-platform directly, or does the distribution own migrations/state?
• How cleanly can data modeled in Streams be exported back to plain Eloquent tables?

Integration Approach

Stack fit. Fits only where we are already on Laravel and need dynamic content modeling, admin-generated CRUD, or a lightweight CMS layer. It is a bad fit for API-only services, queue workers, or anything where the schema is stable and developer-owned — in those cases it adds a platform we must maintain for zero benefit.

Migration path. Treat as greenfield-only. Retrofitting into an existing Eloquent application creates two competing data layers and two sources of truth for content, which is a persistent tax. If we proceed, install into a fresh Laravel skeleton and build application code on top of it, not alongside it.

Compatibility. First action is a composer require --dry-run against our actual root composer.json to see whether constraints resolve at all. Then verify PHP version, database driver support (MySQL/Postgres parity is often uneven in this class of package), and whether our existing packages conflict on shared Laravel contracts. Pin the distribution to an exact version in composer.json; do not float it.

Sequencing.

1. Constraint-resolution spike (half day) — does it even install against our stack?
2. Throwaway-app evaluation (1–2 weeks) — build one realistic content type end-to-end, including admin UI, API exposure, and a data export.
3. Field-type coverage audit — confirm every field type we need exists or is cheap to add.
4. Decision gate — go/no-go against building a minimal in-house field engine.
5. If go, wrap all Streams access behind our own repository/service interfaces so business logic never calls Streams APIs directly.

Operational Impact

Maintenance. Low day-to-day code churn, high strategic risk. We inherit the vendor's release cadence and their judgment about what gets bundled. Because the distribution is all-or-nothing, a single stale bundled addon can freeze us on an old Laravel minor for months. There is no realistic path to forking and self-maintaining a distribution of this size.

Support. Effectively vendor-only. With three stars and zero dependents there is no Stack Overflow corpus, no third-party tutorials, and no pool of contractors who have seen this code. Escalation means the vendor's own channels. Price paid support into the business case before committing — if none exists, that is close to disqualifying for anything customer-facing.

Scaling. Streams models content as fields and assignments, which behaves like EAV under the hood. That is fine at moderate volume with disciplined indexing and caching, and painful at high read volume or with complex cross-stream queries. Any high-traffic or reporting-heavy requirement should be prototyped and load-tested early rather than discovered in production.

Failure modes.

• Composer deadlock on upgrade — blocked by an unrelated transitive constraint, with no partial-upgrade escape hatch.
• Upstream abandonment — vendor pivots or stops releasing; we are stranded on a pinned Laravel version.
• Schema lock-in — content model lives in Streams tables; extraction back to first-class Eloquent models is manual and expensive.
• Security surface — shipping an admin control panel into production increases attack surface and needs explicit hardening and access control.
• Silent behavior change on a distribution bump — bundled addons move together, so a minor upgrade can shift multiple subsystems at once.

Ramp-up. Significant. The Streams mental model (streams, fields, assignments, addons, namespaces) is non-obvious and the documentation is thin. Estimate two to four weeks before a mid-level Laravel developer is independently productive, and assume the first developer becomes a single point of knowledge. Budget for internal written documentation as a deliverable, not an afterthought.