Application Livewire Laravel Package

Getting Started

Reality check before you start. This package scores ~20/100 with zero stars, zero dependents, and a NOASSERTION license. Treat it as an internal, pre-adoption module rather than a community-maintained library: budget an hour to read the source before you commit to it, and pin it to an exact commit rather than a floating constraint.

1. Confirm what it actually adapts. The name says "Application Core livewire presentation adapter," which tells you only that it wraps liberusoftware/application-core (or similar) for Livewire. Read composer.json first:

composer show liberusoftware/application-livewire --all

Look at require — that is your real dependency graph, and it will tell you which Livewire major version you are on (v2 vs v3 changes everything below) and which core package supplies the ports.

2. Install from source, not from a tag you trust blindly. With no dependents there is no de-risking via transitive use:

composer require liberusoftware/application-livewire:dev-main
# then in composer.json, replace the constraint with a commit hash

If it isn't on Packagist, use a vcs repository entry or a path repository pointing at a sibling checkout.

3. Find the entry points in this order:

• src/Providers/*ServiceProvider.php — what it registers, what it binds, whether it calls Livewire::component(...), loadViewsFrom(...), mergeConfigFrom(...), loadMigrationsFrom(...).
• config/*.php — what is publishable and what the defaults assume.
• src/Http/Livewire/ or src/Livewire/ — the actual components.
• resources/views/livewire/ — markup, and whether it hardcodes Tailwind/Bootstrap assumptions.
• routes/ — whether it ships any routes at all (many adapters don't; components are embedded by the host app).

4. First use case: read-only index. Don't start with a write path. Pick the simplest listing component, drop it into a Blade view, and confirm the package's view of the world renders against your database:

<livewire:application-index />

If that tag doesn't resolve, you haven't found the component alias — grep for Livewire::component and protected static string $name / public function getName() depending on version. Once the index renders, add one detail view and then one mutation. That sequence tells you where the core boundary actually sits before you build anything on top of it.

Implementation Patterns

Treat the package as a thin adapter, and keep it thin. The value of a ports-and-adapters split is that Livewire components own presentation state only — filters, pagination cursor, selected tab, form draft — while the core owns invariants. When you extend this package, the anti-pattern to avoid is a save() that touches Eloquent directly and bypasses whatever command/action the core exposes:

// Preferred shape: delegate to the core's use case, return a DTO to the view
public function approve(ApproveApplication $approve): void
{
    $result = $approve->handle(new ApproveApplicationCommand(
        id: $this->applicationId,
        actorId: auth()->id(),
    ));

    $this->application = $result->toArray(); // serialize at the boundary
    $this->dispatch('application-approved');
}

Keep component state serializable. Livewire hydrates public properties from the request. If the core hands you entities with value objects, collections of aggregates, or objects holding a DB connection, hydration will silently degrade or throw. Convert to arrays/DTOs/IDs in mount() and in every action return. This is the single most common source of "works on first load, breaks on second request" bugs in adapter packages.

Compose rather than fork. If you need a variant of a shipped component, subclass or wrap it — don't copy it into app/. Copying means you inherit the package's future breaking changes as a manual merge, and with this package's release cadence (next release dated 2026) you will be reconciling by hand. If the view is wrong, override the view via loadViewsFrom precedence or republish views to resources/views/vendor/... and leave the class alone.

Cross-component communication via events, not shared state. Parent/child with #[On] or $listeners, and $this->dispatch(...) upward. If the core already emits domain events, listen to those in a thin listener that re-dispatches a Livewire event — this keeps the adapter decoupled from core internals and gives you one place to adapt when the core renames something.

Pagination and filtering belong to the core's query objects. If the package ships a WithPagination trait usage, keep $perPage and the filter array as public properties and pass them into the core's repository/criteria object on each render. Don't cache query builders as properties.

Testing. Use Livewire::test(Component::class) for adapter behaviour, and bind fake/simple implementations of the core ports in the container so you are testing the component, not the persistence layer:

Livewire::test(ApplicationIndex::class)
    ->set('status', 'pending')
    ->assertSee('Invoice #')
    ->assertDispatched('application-approved');

If the package has no tests of its own (likely at this score), your tests are the only regression net. Write them for every component you actually embed, before you upgrade either Livewire or the core.

Gotchas and Tips

License is the biggest risk, not the code. NOASSERTION means GitHub could not identify a recognised license. Before this touches a commercial codebase, get written clarification from the maintainer or an explicit license file. "Public repository" is not "licensed for use."

Zero dependents means zero field reports. You are the first person to hit every bug. Pin to a commit, vendor-fork it if you must, and keep a PATCHES.md of local changes so upgrades are mechanical.

Livewire v2/v3 drift is the most likely breakage. Check whether components use $rules + $this->validate() vs #[Validate], whether events are emit or dispatch, and whether the provider uses the Livewire::component() facade (safe) or file-based discovery with a namespace configured in config/livewire.php (fragile — a wrong namespace silently makes tags unresolvable with a confusing "component not found" error).

Silent no-op provider registration. In Laravel's package discovery era, a missing extra.laravel.providers entry means the provider never loads and none of the components exist — but nothing errors at install time. Verify with php artisan about or by dumping app()->getLoadedProviders().

Config publish collisions. If the package ships a config key that shares a name with the core's config, mergeConfigFrom can give you a shallow merge where you expect nested arrays to merge. Check the published file against the vendor default and note the difference.

Domain objects leaking into Blade. If views call methods on hydrated properties that were serialized to arrays, you get Call to a member function on array. This is the hydration issue again — it just surfaces in the template, which sends people looking in the wrong place. When debugging, dd($this->all()) inside render() and check what survived hydration.

Authorization gaps. Adapter packages frequently ship components without policies or authorize() calls, on the assumption the host app gates routes. Livewire components are public endpoints. Audit every public method on every component you expose and add $this->authorize(...) yourself.

Extension points to prefer, in order: view overrides → config → container bindings for core ports → subclassing → forking. Fork last. If you find yourself wanting to fork within the first week, that's a signal the package isn't ready for your use case and a hand-written component against the core's public API will cost less over a year.

Upgrade discipline. With a single release dated in the future and no changelog history to learn from, diff the source between commits before bumping. git diff v1..v2 -- src/ will save you more time than any semver assumption.