Streams Composer Plugin Laravel Package

Product Decisions This Supports

• Build vs. buy for addon distribution: This package represents a "buy" (adopt) answer to the question "how do we let Composer manage Streams platform addons?" It is the kind of glue a PM evaluates when deciding whether to build internal tooling around a CMS/platform's extension model or lean on the vendor's own tooling. Here, the answer is heavily weighted toward "don't depend on it."
• Platform selection, not feature selection: The package only has meaning inside the Streams platform ecosystem (Anomaly Labs, the lineage behind PyroCMS/Streams). Its real product value is as a data point in the broader decision of whether Streams is a viable platform for a roadmap — not as a standalone capability.
• Roadmap signal for legacy maintenance: Last release July 2015, one star, zero dependents. For a PM owning an existing Streams-based product, this is a maintenance-burden marker: expect to own this code if you use it, and plan migration/modernization work accordingly.
• Use case fit: Composer-driven installation of Streams addons/modules — useful in a workflow where extension packages are versioned and pulled like normal PHP dependencies rather than manually copied into an addons directory. That is a legitimate DevOps/developer-experience use case; it just isn't one this package can be trusted to deliver in 2024+.
• Ecosystem health input: Zero dependents and a decade-old release are strong negative evidence for any "should we standardize on this?" decision. If an engineer proposes it, the PM's job is to redirect the conversation to the current, maintained mechanism (or a small internal script) rather than resurrect this plugin.

When to Consider This Package

Consider it only under narrow, mostly historical conditions:

• You have inherited a live Streams platform application pinned to a PHP/Laravel era consistent with 2015 tooling, and Composer-based addon installation is already part of the build. Even then, treat it as a read-only reference for how the integration was intended, not as a new dependency.
• You need to understand the Streams addon install contract (how addons get registered/discovered) before writing a modern replacement or a CI script. Reading the source is cheap; depending on it is not.
• You are evaluating the Streams ecosystem as a whole and need to characterize its maintenance posture. This package is evidence, not a solution.

Look elsewhere — decisively — when:

• The project is new or actively developed. A one-star, zero-dependent package with a 2015 release has no support path, no security response, and no compatibility guarantees with current Composer or PHP versions.
• You need Composer 2 compatibility, PHP 8 support, or PSR-4 autoloading. Assume none of it without verification; the release date makes breakage likely.
• You need a vendor SLA or community support. There is effectively no community here.
• You can solve the same problem in a few lines of build script or a private Composer repository. That is almost certainly the better buy.
• The underlying platform itself is under evaluation. If Streams is not a strategic commitment, this plugin is irrelevant regardless of its quality.

How to Pitch It (Stakeholders)

To executives: This is a small, decade-old integration plugin for a niche PHP CMS platform. It is not a strategic dependency and should not enter our architecture. Its value to us is informational: it tells us how that platform's extension model was meant to work and confirms that the surrounding ecosystem is not actively maintained. Recommendation: do not adopt; if we are on this platform today, treat this as a signal to scope a modernization or migration path rather than to invest in the plugin.

To engineering: No one should add this to composer.json. Zero dependents, last release 2015, no maintainer activity — the cost of adopting it (Composer/PHP compatibility, security review, permanent ownership) exceeds the cost of replacing it. Two acceptable uses: (1) read the source to understand the Streams addon registration contract, (2) if we must support Composer-based addon installs in a legacy Streams app, write and own a minimal internal script or private package instead. If a team believes it is still required, ask them to demonstrate it works on our current PHP/Composer versions in a spike before we discuss it further.