Getting Started

This package is a presentation adapter: it ships Livewire components (login, registration, password reset, profile/credential management) that sit on top of liberusoftware/module-identity-core, which owns the actual domain logic. Treat it as UI glue, not as an auth framework — the core module is where the behaviour lives.

Minimal setup:

composer require liberusoftware/module-identity-core-livewire

Because it is an adapter, confirm the core dependency resolved correctly before debugging anything else:

composer show liberusoftware/module-identity-core-livewire
composer show liberusoftware/module-identity-core   # the domain layer

Then publish and inspect what you got:

php artisan vendor:publish --provider="LiberuSoftware\Identity\Livewire\IdentityLivewireServiceProvider"
php artisan route:list | grep -i identity

Where to look first, in this order:

composer.json of the package — the require block tells you which Livewire major and which core version you are actually pinned to. This is the single most important file given the package's age/versioning ambiguity.
src/ — look for a Livewire/ or Http/Livewire/ directory; those are your components, and their render() methods point at the view namespace.
config/ — almost every adapter like this exposes a component map, guard name, redirect targets, and route toggles.
routes/ — check whether routes are auto-registered, under which middleware group, and whether they are opt-in via config.
resources/views/ — the Blade you will be overriding.

First use case: get the login component rendering on a page you control rather than adopting the package's routes wholesale.

{{-- resources/views/auth/login.blade.php --}}
<x-layouts.guest>
    <livewire:identity.login />
</x-layouts.guest>

Verify the component alias resolves (php artisan livewire:list is not a command — use Livewire::test() or just load the page and read the exception). If the alias is namespaced, the tag will be something like <livewire:identity-core::login />; the component's $name/registration in the service provider is authoritative.

Only after a single component renders should you enable the package's own routes — otherwise you are debugging routing, middleware, and the adapter simultaneously.

Implementation Patterns

Keep the adapter thin

The healthy pattern with this package is: Livewire component validates and delegates, core module decides. Resist adding business rules to the component. When you need behaviour the component does not expose, extend the core service and inject it, rather than editing published views to call models directly.

// App\Livewire\Auth\Login extends the package component
class Login extends \LiberuSoftware\Identity\Livewire\Components\Login
{
    // Override only presentation concerns:
    public function render()
    {
        return view('auth.login')->layout('layouts.guest');
    }
}

Then repoint the config map at your subclass, so the package's own route/alias resolves to your version:

// config/identity-livewire.php
'components' => [
    'login' => App\Livewire\Auth\Login::class,
],

This is the main extension point — prefer it over editing files in vendor/.

Publish-and-override for views

Two viable strategies, pick one and be consistent:

View override (recommended): keep the package component, publish views, and place replacements at resources/views/vendor/{namespace}/livewire/login.blade.php. Upgrades stay clean.
Component subclass: only when you need to change properties, actions, or the redirect target — things Blade cannot express.

Mixing both leads to "I edited the view but the behaviour is still wrong" confusion, because the class and the template now have different owners.

Wiring into your own auth surface

If you already have Breeze/Jetstream/Fortify, do not mount this package's routes. Disable them in config and embed individual components into your existing pages:

// config/identity-livewire.php
'routes' => ['enabled' => false],

Then compose: <livewire:identity.login /> inside your existing guest layout, <livewire:identity.profile /> behind your auth middleware. This is the most common real-world integration and the one that avoids duplicate /login route collisions.

Reacting to outcomes via events

Adapters typically dispatch domain events after a successful action. Listen rather than polling component state:

// App\Providers\EventServiceProvider
protected $listen = [
    \LiberuSoftware\Identity\Core\Events\IdentityAuthenticated::class => [
        \App\Listeners\StampLastLogin::class,
        \App\Listeners\SyncToCrm::class,
    ],
];

Confirm the exact event class names by grepping the core package (grep -r "dispatch(" vendor/liberusoftware/module-identity-core/src). Do not assume the names.

Testing

Test the adapter through Livewire's harness, not through HTTP, so failures point at the component:

Livewire::test(\LiberuSoftware\Identity\Livewire\Components\Login::class)
    ->set('email', '[email protected]')
    ->set('password', 'secret')
    ->call('authenticate')
    ->assertHasNoErrors()
    ->assertRedirect('/dashboard');

$this->assertAuthenticated();

Write these tests in your own suite on day one. With zero dependents and zero stars, your test suite is the only regression net you have.

Multi-guard / multi-tenant

If your app has admin and customer guards, the adapter's guard is almost certainly config-driven. Set it explicitly per panel rather than relying on the default:

'guard' => 'admin',

and mount separate component instances (or separate config sets) per panel. Do not try to make one instance serve both.

Gotchas and Tips

The license is NOASSERTION. This is the highest-priority item, above any code concern. Composer reports no recognised license, which means automated compliance tooling will flag it and you have no stated grant of rights. Get legal sign-off or a written clarification from the maintainer before shipping it to production. Until then, treat it as evaluation-only.

Zero stars, zero dependents, future-dated release. A last release date of 2026-10-26 combined with 0 stars and 0 dependents strongly suggests a private/unpublished module that has been mirrored or re-tagged with a skewed clock. Practical consequence: pin exactly ("liberusoftware/...": "1.2.3" or a commit hash), commit composer.lock, and consider vendoring the source into your repo. Assume no upstream support and no security advisories.

Livewire major mismatch is the most likely first failure. wire:model vs wire:model.live, $rules vs #[Validate] attributes, and layout syntax (->layout() vs @layout) all changed between v2 and v3. If components render but never update, check composer show livewire/livewire against the adapter's require constraint first — not your Blade.

Routes may bypass your middleware expectations. Auto-registered guest routes often sit in the web group only. If you need login throttling, add it yourself — rate limiting on a Livewire component is not automatic, because the POST goes to /livewire/update, not to your login route. Use RateLimiter inside the component action or ->middleware('throttle:...') if the package supports route middleware config.

Redirect-after-login lives in two places. There is usually a config value and a hardcoded fallback in the component's redirect()/$redirect property. If changing config appears to do nothing, check the component class — and be aware Livewire full-page components use redirect() while inline components ignore it.

Session and guard mismatch presents as silent login failure. You authenticate successfully, then get bounced back to /login. This is nearly always config('auth.defaults.guard') differing from the guard the adapter authenticates against, or a SESSION_DRIVER/domain mismatch. php artisan config:clear first, then compare guards.

View publishing tags are guesswork. If vendor:publish with the provider publishes nothing, list the tags:

php artisan vendor:publish --provider="...ServiceProvider" --tag=identity-livewire-views
# try: identity-views, livewire-views, views, config, identity-core-config

The provider's publishes() array is the only truth; open it rather than guessing repeatedly.

Validation messages come from the package's lang files. Override them in lang/vendor/{namespace}/ rather than editing the component, or translations will vanish on the next composer update.

Debugging checklist, in order: php artisan about (confirm Livewire version and providers loaded) → php artisan route:list | grep identity (routes registered?) → component resolves in isolation via Livewire::test(Component::class) (class-level failure) → render in a page (layout/Blade failure) → check storage/logs/laravel.log for the core module's exceptions (domain-level failure). Each step isolates one layer of the adapter stack, which is what saves you time on a package with no documentation to search.

Extension points worth knowing before you fork: the component config map, app()->bind() on the core's service contracts, the view namespace in loadViewsFrom(), and dispatched events. Almost every requirement can be met through one of those four without touching vendor/. If you find yourself patching vendor code, stop and vendor the package into app/ or a local path repository instead — that at least makes the divergence visible and testable.

Identity Core Livewire Laravel Package