Addons Module Laravel Package

Product Decisions This Supports

Feature scoping: addon/extension management

• Informs the "manage installed extensions" surface of your product: listing addons, surfacing metadata (name, version, author, description), and toggling enable/disable state.
• Provides a reference model for how addon metadata is declared, discovered, and exposed to an admin UI — useful for writing acceptance criteria and data contracts before any code exists.

Build vs. buy

• Represents the "buy/extend" option for teams already inside the Anomaly Streams Platform ecosystem: adopting an existing, MIT-licensed module instead of writing addon discovery, registration, and lifecycle handling in-house.
• Because it is scoped narrowly to "addon information and management," it lets you defer building a bespoke plugin registry while you validate demand for a marketplace or extension model.

Roadmap and platform strategy

• Signals what a mature extension ecosystem needs: metadata schema, version awareness, enable/disable lifecycle, and admin-facing discovery. Useful as a checklist when planning a marketplace, third-party integration program, or self-serve extension directory.
• Helps you time investment: if you are not yet on Streams, this package is not a roadmap dependency; if you are, it can accelerate an early milestone.

Use cases worth validating

• Internal admin tooling that enumerates and manages first-party modules.
• A migration aid when consolidating multiple Streams-based sites into one platform.
• A learning/reference artifact for engineering spikes on plugin architectures — cheaper to read than to design from scratch.

Decision inputs it clarifies

• What "addon management" actually costs in scope (metadata, state, versioning) versus what stakeholders imagine it costs.
• Whether an extension ecosystem is a differentiator worth funding, or a maintenance liability to avoid.

When to Consider This Package

Consider it when:

• You are already running the Anomaly Streams Platform (or PyroCMS derivatives) and need addon listing/management behavior that matches the platform's conventions.
• You need a reference implementation for addon metadata and lifecycle handling to inform a spike or an internal design doc — reading it is cheap, and MIT licensing makes reuse low-friction.
• Your requirement is genuinely narrow: display and manage addon information, not a full dependency resolver, marketplace, or remote registry.
• You have engineering capacity to vendor or fork the code and own it, treating it as a starting point rather than a maintained dependency.

Look elsewhere when:

• You are not on the Streams Platform — the value is ecosystem-specific and does not transfer to a generic Laravel application. A general-purpose package manager or a small custom registry will be a better fit.
• You require active maintenance, security patching, or vendor support. The last release is April 2020, the project has 2 stars and 0 dependents — no community validation, no downstream signal, and a single-maintainer bus-factor risk.
• Addon management is core to your product's value proposition. In that case, own the implementation: the metadata schema and lifecycle rules are the product, and inheriting stale conventions will constrain you later.
• Your security posture requires audited, version-pinned dependencies in the admin surface — an addon manager is a privileged code path (it enumerates and can toggle executable modules) and warrants scrutiny.
• You need modern PHP/Laravel compatibility guarantees; an unmaintained 2020-era module is a likely upgrade tax at every framework bump.

Adoption checklist before committing: confirm framework/PHP version compatibility, read the source end-to-end (small codebase), check whether it pulls additional Anomaly packages you would also inherit, and budget explicitly for fork ownership.

How to Pitch It (Stakeholders)

For executives — the short version This is a small, MIT-licensed module that handles addon information and management for the Anomaly Streams Platform. It is a cheap accelerator, not a strategic dependency. It is only relevant if we are already committed to Streams; otherwise it does not apply to our stack. Treat it as a potential head start on extension-management tooling — one we would fork and own rather than rely on. The maintenance signals are weak (last release 2020, two stars, no downstream dependents), so the recommendation is evaluate as a reference, do not adopt as a dependency unless we are already on the platform and the scope is strictly narrow. Cost of evaluation is low (a day of engineering reading); cost of unmanaged adoption is an orphaned dependency inside an admin-privileged code path.

For engineering — the working summary

• Scope: addon metadata discovery and management (list, inspect, enable/disable) within the Streams Platform module conventions.
• License: MIT — forking and vendoring are permitted and probably the correct move.
• Health: last release 2020-04-15; negligible community traction. Assume no upstream fixes.
• Risks: framework version drift, implicit coupling to other Anomaly packages, privileged admin surface requiring review, single-maintainer abandonment.
• Recommended action: timebox a spike, read the source, extract the metadata schema and lifecycle model, then implement against our own requirements. If we are mid-migration on Streams and the need is purely informational listing, a vendored copy is acceptable — with an owner assigned and a documented exit plan.

Positioning line for stakeholders: "A small, free accelerator for extension management on one specific platform — useful as a blueprint, not as a foundation."