Api Access Livewire Laravel Package

Getting Started

This is a presentation adapter, not a standalone feature. It assumes a sibling domain package (something like liberusoftware/api-access or module-api-access) already provides the models, actions, and authorization for API clients/tokens. Install the domain package first or the Livewire components will fail at mount() with missing class errors.

Install (likely not on Packagist given 0 dependents):

"repositories": [
    { "type": "vcs", "url": "https://github.com/liberusoftware/module-api-access-livewire" }
]

composer require liberusoftware/api-access-livewire:@dev
php artisan vendor:publish --provider="LiberuSoftware\\ApiAccess\\Livewire\\ApiAccessLivewireServiceProvider"
php artisan migrate

Run vendor:publish interactively (no tag) first — the tag names in low-traffic packages are frequently undocumented or renamed between releases.

Where to look first, in this order:

1. src/*ServiceProvider.php — register/blade namespace, component aliases, config merge, migration loading. This tells you the exact <livewire:...> tag names, which are almost never in the README.
2. src/Livewire/ (or src/Http/Livewire/) — the actual components. mount(), $rules, and authorize() calls reveal the required route-model bindings and guards.
3. resources/views/livewire/ — check whether markup depends on Tailwind, Flux, Filament, or plain Bootstrap. This determines whether the components will look broken inside your layout.
4. config/api-access-livewire.php (if present) — guard names, pagination, route prefixes.
5. composer.json — the livewire/livewire constraint (v2 vs v3 changes everything below) and the core api-access version it was built against.

First use case: drop a token-management panel into an existing authenticated dashboard. Mount the component in a Blade view inside your app layout, hit the page, and confirm it renders against the domain package's tables before wiring it into navigation. That single smoke test validates install, provider registration, migrations, view namespace, and core-package coupling at once.

<livewire:api-access.token-manager />

(Verify the alias from the service provider; the exact segment is the most likely thing to differ.)

Implementation Patterns

Adapter discipline. Treat every component as a view over domain actions. When you need business logic — scoping tokens to a tenant, rotating secrets, custom expiry rules — implement it in the core package and inject it, rather than editing the published component. This is the only way you survive an upgrade of a package with zero community scrutiny.

Full-page vs. embedded. Most adapters ship both: an embeddable component and a route-registered full-page component. Prefer embedding inside your own layout so you control navigation and middleware; use the package routes only if you accept their guard configuration.

// routes/web.php
Route::middleware(['auth', 'verified'])->group(function () {
    Route::get('/settings/api', ApiTokens::class)->name('api.tokens');
});

Authorization at the boundary. Do not assume the package enforces ownership. Add a gate in mount() or wrap the component in middleware, and always test with a second user:

public function mount(): void
{
    $this->authorize('viewApiTokens', auth()->user());
}

If the component's mount() already calls authorize(), find the policy it references and register it — an unregistered policy silently 403s every request and is the #1 "package is broken" false alarm.

Event-driven integration. Adapters typically dispatch() domain events on create/revoke. Listen rather than override:

Event::listen(TokenCreated::class, function ($event) {
    activity()->performedOn($event->token)->log('api token issued');
});

Composition with a settings page. Mount several components side by side (list + create form) and rely on Livewire's $refresh or a shared dispatch('token-saved') to keep them in sync. Avoid cross-component $parent coupling; it breaks when the package refactors.

Testing. Use Livewire::test() against the package's own components to establish a baseline before you customize anything:

Livewire::actingAs($user)
    ->test(TokenManager::class)
    ->call('createToken', ['name' => 'ci'])
    ->assertHasNoErrors()
    ->assertSee('ci');

This doubles as executable documentation for a package with no docs, and gives you a regression net if you later fork or override the component.

Overriding without forking. If the provider registers aliases via Livewire::component('api-access.token-manager', ...), you can re-register the same alias to your own subclass in a later-loading provider. That is usually cleaner than editing vendor/.

Gotchas and Tips

License is NOASSERTION. This is the single most important finding. NOASSERTION in a composer.json/GitHub sense means no recognized SPDX license was detected — do not assume MIT because the rest of the Liberu ecosystem is permissive. Read the LICENSE file (or its absence) before this touches anything commercial. With 0 dependents and 0 stars, there is no ecosystem norm to appeal to.

Zero-adoption risk. No stars and no dependents means effectively no one has run this in production but the author. Pin an exact commit, vendor it, or fork it into your own namespace. Do not use a floating @dev constraint in a deployed application — the release date metadata is already inconsistent, and branch history may be rewritten.

Livewire 2 vs 3 drift. In v2 you will see $listeners, emit(), and $rules as a property; in v3, #[On], dispatch(), and #[Validate] attributes. A package this small is often written against one and never updated. If components silently fail to react to events, check the constraint in composer.json against your installed version before debugging your own code.

Undeclared frontend dependencies. Adapter views are commonly authored against whatever the author's app used — Tailwind with a custom palette, Flux, or Filament components. If the UI renders unstyled or throws "unknown component," that is a styling dependency, not a bug. Publish the views and translate classes to your stack.

Migrations may not exist here. The adapter should not own the schema — the domain package does. If vendor:publish exposes migrations, they may be duplicates of the core package's and will collide on table names. Publish one set only, and check loadMigrationsFrom in the provider.

Config caching. After publishing config or changing guards: php artisan config:clear && php artisan view:clear && php artisan route:clear. Livewire component alias registration is not always config-cache-safe in small packages; if a component 404s in production but works locally, this is why.

Namespace and alias discovery. When unsure of the tag name:

grep -rn "Livewire::component" vendor/liberusoftware/
grep -rn "extends Component" vendor/liberusoftware/api-access-livewire/src
php artisan route:list | grep -i api

Debugging a blank component. Bisect in this order: (1) provider registered — php artisan about; (2) view namespace resolves — view()->exists('api-access-livewire::livewire.token-manager'); (3) core domain classes autoload — instantiate the model in tinker; (4) authorization passes. Nearly every failure is one of these four, in that order.

Extension points to prefer. Config values over published views, published views over subclassed components, subclassed components over edited vendor files. If the package exposes no config and no events, that absence is itself the assessment: budget for a fork.