Installer Laravel Package

Product Decisions This Supports

• Plugin ecosystem strategy. The package is the plumbing that lets third-party developers ship extensions as ordinary Composer packages and have them land in the right places (plugins/{$name}/, public/spora/, public/plugins/{$slug}/). If the roadmap includes a plugin marketplace or an extensibility story, this is a foundational decision enabler rather than a feature in itself.
• Build vs. buy on distribution. Rather than building a bespoke upload/install UI for plugins, adopting Composer + this installer moves distribution onto a mature, familiar toolchain. The trade-off decision for PM is: custom marketplace UX vs. developer-grade Composer workflow — this package presupposes the latter.
• Directory-convention standardization. By encoding where plugin code and frontend assets go, it fixes conventions that ripple into documentation, onboarding guides, CI templates, asset-publishing, and support runbooks. Approving it is effectively approving those conventions.
• Modularity vs. monolith roadmap calls. Supports a decision to let teams or partners deliver features as separately versioned packages (backend-only, frontend-only, or combined plugin-with-frontend) instead of bundling everything into core.
• Use cases it unlocks: plugin authors publishing to Packagist/a private registry; internal teams modularizing a large app; frontend asset delivery for plugins that ship their own UI; separation of spora-plugin (backend logic) from spora-plugin-frontend (assets) so they can version and publish independently.

When to Consider This Package

Consider adopting when:

• You are already building on spora-ai/spora-core — this is explicitly a companion, not a standalone tool.
• You want plugins installed via Composer with zero custom post-install scripting, and you're willing to adopt its directory conventions as your official layout.
• You need distinct routing for backend plugins, shared frontend assets, and per-plugin frontends — i.e., your plugin model has a clear backend/frontend split.
• Your audience is developer-comfortable (Composer, CLI) rather than non-technical admins expecting a web-based installer.

Look elsewhere or defer when:

• You are not on spora-core; the value is entirely tied to that ecosystem.
• You need a hosted marketplace with licensing, billing, or a GUI installer — this only handles file placement.
• You require a battle-tested, widely adopted installer with a large support community. With 0 stars and 0 dependents, this is effectively pre-adoption tooling: expect limited documentation, unproven edge cases (Windows paths, nested vendor dirs, version conflicts), and single-maintainer/key-person risk.
• You need guarantees around backward compatibility; early-stage installers often change path conventions between versions, which would be a breaking change for your plugin layout.

PM guidance: treat it as an internal-facing dependency with a thin surface area. It's cheap (MIT) and low-blast-radius if isolated, but because the ecosystem is nascent, pin versions, document the conventions you rely on, and keep an exit path (a small custom Composer installer) so a stalled maintainer doesn't block your plugin story.

How to Pitch It (Stakeholders)

For executives: "This is a small, low-cost piece that lets third-party developers extend our product the way they already ship code — through Composer. It reduces what we'd otherwise have to build (a custom plugin installer and asset pipeline) and sets up a scalable plugin ecosystem. It's MIT-licensed and easy to trial, but it's very early-stage with no adoption yet, so I'd position it as a strategic enabler we validate, not a foundation we depend on blindly."

For engineering: "It's a Composer installer plugin that routes package types to standard paths — backend plugins to plugins/{name}, shared frontend assets to public/spora, plugin frontends to public/plugins/{slug} — so we don't hand-roll post-install scripts. It's tightly coupled to spora-core and enforces a directory convention we'd need to adopt wholesale. Pros: conventional, no custom bootstrap, clean separation of backend and frontend packaging. Cons: zero dependents, minimal docs, single-maintainer risk — so pin it, wrap it in our own config, and don't let it become an unremovable dependency until it's proven."