Tomato Plugins Laravel Package

Product Decisions This Supports

• Build vs. buy on platform plumbing. If the roadmap includes optional features that must be toggled per customer, deployment, or tenant, this package replaces a bespoke module loader — provider registration, migration/asset discovery, admin toggles — with an MIT-licensed implementation. That is roughly 2–4 engineer-weeks of undifferentiated platform work we would otherwise own and maintain indefinitely.
• Whether to make a plugin/extension ecosystem a product bet. Runtime install/enable/disable with Filament management screens is the prerequisite for any partner, third-party, or internal "marketplace" story. Adopting it is a cheap way to validate demand for an ecosystem before committing roadmap to a formal SDK and marketplace UX.
• White-label and per-client variation strategy. Multi-deployment products typically fork the codebase per client. A plugin system keeps one shared core while client-specific features ship as discrete, togglable modules — directly reducing branch sprawl, merge cost, and release risk. This is the strongest economic argument for the package.
• Packaging and pricing architecture. Plugin boundaries map naturally onto tiers and add-ons. If sales needs "turn on the reporting module for this customer," plugin granularity gives product a concrete unit to price, bundle, and gate — and gives ops a lever that doesn't require a deployment window.
• Runtime feature gating without redeploy. Enable/disable is an operational capability, not just code organization. It answers "can we turn on an add-on for a customer the same day?" — a recurring blocker in on-prem and regulated environments where release cadence is slow.
• Roadmap sequencing and staffing. Adopting now versus building later changes the critical path: it pushes core platform plumbing out of the next two quarters and frees the team for customer-visible work. It also implies a standing commitment to keeping the plugin API stable (versioning, deprecation policy, upgrade guides) — worth an explicit decision rather than an implicit one.
• Typical use cases to evaluate against: a Laravel/Filament admin product with add-on modules; an internal platform where multiple teams contribute self-contained features; a consultancy delivering tiered bundles from one codebase; a vertical SaaS where each segment needs a different feature subset.

When to Consider This Package

Consider adoption when:

• You are already on Tomato PHP + Laravel + Filament — the value is concentrated in that stack, and the admin-side plugin management comes largely for free.
• You have a concrete, near-term need for self-contained modules that register their own resources, pages, migrations, routes, and settings without touching core.
• Your delivery model involves multiple deployments or tiers needing different feature subsets, and you want to retire long-lived per-client branches.
• You want runtime enable/disable exposed to operators through the admin panel rather than through config files plus redeploys.
• You can accept a single-maintainer, pre-2.0 dependency and are willing to pin a version, wrap it behind a thin internal interface, and treat the ability to fork as part of the plan.

Look elsewhere or defer when:

• Your stack is not Filament-based (or not Laravel) — the integration story and most of the payoff evaporate, leaving a thin provider loader.
• You only need Composer-level package organization, not runtime toggling. nwidart/laravel-modules or plain service-provider packages deliver modularity with a far larger user base and mature documentation.
• Adoption risk is disqualifying. One star, zero dependents, and a pre-2.0 version line mean near-zero field validation. If you cannot absorb the cost of forking or replacing this within six to twelve months, prototype but do not standardize.
• You need vendor support, SLAs, security review artifacts, or a published deprecation policy. None of that is implied here; the MIT license is the entire guarantee.
• You need plugin isolation or sandboxing for untrusted third-party code. This is a trusted, first-party module system, not a security boundary — do not position it as marketplace safety.
• You need strict guarantees across Laravel/Filament majors. A 1.2.x line with active patch releases implies churn; budget upgrade work at each Filament major.
• Migration and asset auto-discovery conflicts with conventions already baked into a mature monolith. Retrofitting a plugin loader is usually a bigger change than it appears — scope it as a spike before promising timelines.
• Documentation and source appear mismatched. The provided release note describes form/relation-select behavior rather than plugin installation, which suggests shared release artifacts across a package family. Resolve that against the tagged source before any scoping decision; ambiguity in a package that controls provider registration is a red flag.

Due-diligence checklist before a go decision: review issue/PR responsiveness and release cadence over the last two quarters; confirm whether the maintainer's other packages sit on your critical path in a way that concentrates risk; verify discovery behavior against your deployment topology (multi-node, queues, read-only filesystems, config:cache / route:cache / optimize); confirm what "disable" means for already-run migrations and persisted data; and confirm license compatibility with your distribution model.

How to Pitch It (Stakeholders)

To executives: This is a small MIT-licensed package that adds a module system to our Laravel/Filament admin stack, letting us package optional features so they can be installed, enabled, or disabled per customer without redeploying or forking the codebase. The strategic value is delivery economics: one shared core instead of a branch per client, which is where much of our customization and merge cost currently sits — and a clean unit for pricing tiers and add-ons. The risk is maturity, not cost: the project is early-stage with essentially no public adoption. The recommendation is a scoped, time-boxed pilot behind an internal abstraction, not a company-wide standard. If it holds, it's the cheapest credible path to a tiered add-on offering; if it doesn't, we've spent days rather than a quarter.

To engineering: The package provides plugin auto-discovery for providers, migrations, and assets; runtime enable/disable; Filament screens for managing installed plugins from the admin panel; and publishable config for custom plugin paths and namespaces — plugins own their resources, pages, migrations, and settings without core edits. Three conditions before we depend on it: pin an exact version and wrap the discovery and enable/disable surface behind our own PluginContract so a swap to nwidart/laravel-modules or a hand-rolled loader is a contained change; keep registration inside the trust boundary (first-party modules only, never untrusted code); and verify behavior under optimize/config:cache, on multi-node and read-only-filesystem deployments, and define explicitly what disable does to migrations and data. Please also reconcile the release notes against the tagged source before we estimate.

To product/PM: Treat this as platform capability that de-risks how we ship variation, not a user-facing feature. It changes the cost curve for tiers, add-ons, and per-client customization — the places where roadmap timelines usually slip. The decision to make now is procedural, not architectural: run a one-to-two-week spike on a single real add-on module, measure how much core branching it removes and whether the operator toggling actually works, then reconvene on standardizing. Do not put a plugin marketplace, public SDK, or third-party ecosystem on the roadmap until that spike and the maintainer-health check both come back green.