Wire Core Laravel Package

Product Decisions This Supports

• Build-vs-borrow for foundational primitives. Actions, modals, notifications, icon registries, and semantic color tokens are surfaces every Laravel/Livewire team either hand-rolls or inherits. This package sits on the "borrow" side of that ledger, but at zero stars and zero dependents it functions today as a pattern reference, not a dependency. The decision it actually informs is the shape of our in-house primitives layer, not whether to run composer require.
• Ecosystem bets. Whether we standardize on a shared "Wire" stack. A core package with no public consumers is either pre-release scaffolding for a larger ecosystem or orphaned plumbing. Both are valid states to observe; neither is a state to depend on. Track it as a leading indicator for a platform bet, not the bet itself.
• Architecture standardization across the portfolio. If multiple Laravel apps are reimplementing the same action/modal/notification patterns, a shared foundation is the correct shape of a solution. This package documents what that layer looks like — trait composition on a base component, invokable actions with a single return contract, modals that take an ID rather than a serialized model, semantic color tokens — even if we never install it.
• Design-system scoping. The bundled icon registry and semantic color→Tailwind map are a proposal for where design tokens live. "Own the token layer or outsource it" is a scoping decision distinct from the vendor decision, and should be made deliberately rather than by default. Icon sets churn faster than anything else in a UI layer; whichever way we go, resolution should sit behind one facade we control.
• Vendor and maintenance-risk policy. How much foundational surface are we willing to outsource to a single-maintainer package with no adoption? The precedent matters most at the foundation tier, where the bar should be highest — foundations should be boring and battle-tested, not pioneering. A dev-main-only distribution with no tagged semver releases and no CI is a hard stop for anything on the critical path.
• Roadmap sequencing. Whether to spend iteration time on primitive/design-system work now or defer until the ecosystem shows signal. The cost of waiting is low; the cost of adopting early and forking later is roughly a quarter of unplanned maintenance.
• Greenfield vs. retrofit gating. Foundation-first only. Adopting onto an app with existing action/notification/modal abstractions produces duplicate trait methods (fatal at boot), competing notification contracts, and two icon-resolution paths. The convenience delta never covers the migration.

When to Consider This Package

Consider it if:

• You are a maintainer or early contributor to the Wire ecosystem and need the shared layer to keep sibling packages consistent — you are buying into the ecosystem, not just the code.
• You are building a greenfield internal tool where speed beats longevity, the blast radius is contained, and breaking changes can be absorbed without a migration project.
• You want a reference implementation to crib patterns from under MIT — reading the source is free, the license permits direct reuse, and for a two-or-three-idea extraction that is the highest-value use today.
• Your stack already matches Wire's assumptions (Laravel 10/11, PHP 8.1+, Blade/Livewire componentization, Tailwind), so integration is genuinely zero-config.
• You are explicitly willing to become maintainer of last resort: fork it, own it, treat upstream as optional. Pre-agree the trigger — "no tagged release in 180 days" is a reasonable line — and keep the wrapper thin so a fork is a rename, not a migration.

Look elsewhere if:

• Anything on the critical path depends on it. Traits mixed into base components create deep coupling; a zero-dependent package is a single point of failure with a bus factor of one.
• You need documentation, community support, a security-response process, or an LTS commitment — none are evidenced. With no docs, the source is the spec, and onboarding cost is real engineering hours.
• You need a mature primitive layer today. Filament, Laravel Nova, the Livewire ecosystem, Blade UI Kit, and established icon sets (Heroicons, Lucide) cover most of this surface with far more adoption and far less risk.
• Your team would be the first production user. Zero dependents is a specific red flag for a foundation — foundations should be proven, not pioneering.
• Procurement or compliance requires demonstrated provenance and maintenance commitments. MIT is fine; the absence of releases, CI, and merge history is not.
• You are retrofitting onto an existing app with in-house primitives, or your team would half-follow the package's Blade/view conventions. A half-followed convention costs more than no convention.

Verdict for planning purposes: treat as evaluate / pattern-reference, not adopt. No production dependency without a tagged semver release, a declared framework constraint, and a named internal owner.

How to Pitch It (Stakeholders)

For executives — one line: This is a small, MIT-licensed Laravel/Livewire helper library that shows us a clean design for shared UI primitives; we are using it as a blueprint to make a build-vs-buy decision, not as a dependency we are betting the roadmap on.

For engineering — the honest summary: nyoncode/wire-core centralizes the repetitive bits of a Livewire app — base component classes and traits, invokable actions, modal state, notification dispatch, an icon registry, and a semantic color→Tailwind map — with zero configuration. The shape of it is good and worth copying: compose behavior on a single app-owned base component, model user-triggerable operations as invokable actions with an explicit result contract, hold modal open/payload state in component properties and pass IDs rather than serialized models, and resolve icons and colors through one token layer. The distribution of it is not production-ready: zero stars, zero dependents, no published docs, no evident CI, and a dev-main-only install that cannot be meaningfully version-pinned. Trait method collisions with our own base classes fail at boot with error messages that point at class names rather than the conflicting traits, so any mixing requires a pre-flight method diff.

Recommended ask: a bounded spike — one engineer, one afternoon, on the least critical internal screen — to port the three or four patterns worth keeping into our own thin primitives layer, with one regression test per subsystem. Isolate behind App\Livewire\WireComponent and an App\Support\Icon facade from day one so any future vendor swap is a single-file change. If the spike confirms the patterns pay for themselves, we build them ourselves; if the package later ships tagged releases, real docs, and framework constraints, we revisit adoption as a straightforward substitution rather than a migration.

What we are explicitly not doing: installing it on any existing application, putting it on a critical path, or letting it become a load-bearing service provider. Keep the fork cost at an afternoon by design.