Integrations Livewire Laravel Package

Product Decisions This Supports

• Feature scoping for an "Integrations" settings surface. This package is the presentation layer (Livewire components) for a companion Integrations domain module. If the roadmap includes "let customers connect their own third-party accounts," this adapter is the cheapest path to a working connect/disconnect/configure UI — the decision it informs is whether that surface is a scoped sprint or a configuration task.
• Build vs. buy for admin CRUD. Rather than budgeting custom Livewire screens for credential entry, provider selection, and connection status, you evaluate adopting a pre-built adapter. Frame the tradeoff explicitly: saved UI engineering hours vs. coupling to a vendor's module conventions and a near-zero-adoption dependency.
• Architecture hedge. The "presentation adapter" pattern keeps integration domain logic UI-agnostic. That's a real product decision enabler: you can ship Livewire now and migrate to Inertia/Vue later without rewriting the integration core. Worth capturing as a risk-reduction argument, not just a technical note.
• Roadmap sequencing. Because it is a thin adapter over an existing domain module, "integrations console" can be pulled forward cheaply only if the team is already on the parent module. If not, this package adds a dependency chain with no independent value — a sequencing input, not a standalone feature.
• Use cases where it plausibly fits. Internal ops tooling for managing customer credentials; SaaS admin panels for connector management; multi-tenant "connect your account" onboarding flows.

Signal caveats that must accompany any of the above: zero stars, zero dependents, an unclear license (NOASSERTION), and a single-vendor origin. There is no external validation, no community support path, and no evidence of production use. Treat adoption as "vendoring a first-party internal component," not "adopting an ecosystem package."

When to Consider This Package

Adopt (or evaluate seriously) when all of the following hold:

• You are already committed to the Liberu modular Laravel stack and the companion module-integrations package is in your dependency tree. The adapter is worthless without its domain module.
• Your front end is Livewire-first (TALL stack), and your team can read and modify Livewire component code rather than only consume it.
• You need integration-management screens soon and the core module already handles the hard parts (provider registry, token/credential storage, connection state).
• You are prepared to pin a version, fork it, and own maintenance — assume no upstream support.
• Legal/compliance has cleared the ambiguous license, or you can obtain clarification from the maintainer before shipping commercially.

Look elsewhere when:

• You are not on the Liberu module family — the dependency chain is not justified by a presentation-only package.
• You need React/Vue/Inertia or a headless API surface; this is a Livewire-specific adapter.
• You expect provider breadth out of the box. The adapter renders; the domain module defines which integrations exist. Validate provider coverage in the core module before promising anything to customers.
• You require commercial support, an SLA, or a clearly asserted OSI license.
• You need proven, widely deployed prior art. The realistic alternatives are Laravel's own primitives (Socialite, HTTP client, custom OAuth handling), a commercial starter kit, or an embedded iPaaS vendor if integration breadth is the actual product bet.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost UI accelerator for an integrations settings screen — not a strategic platform bet. It can shorten time-to-demo for "connect your account" flows if we are already using the underlying Liberu integrations module. It carries two governance items: an unclear license that legal must clear, and a maintainer-risk profile typical of a single-vendor package with no external users. Recommendation: treat it as internal-style code we vendor and own, not as a dependency we rely on.

To engineering: It is a Livewire presentation adapter over module-integrations — components for listing, connecting, and configuring integrations, with the domain logic kept separate. No adoption signal (0 stars, 0 dependents), so budget for reading the source, pinning a commit, and forking if we ship it. Upside is genuine: the adapter boundary means we can swap the UI layer later without touching integration logic. Ask the team to confirm Livewire version compatibility and that the parent module covers the providers we actually plan to offer before we commit any roadmap dates.