Profiles Livewire Laravel Package

Getting Started

This package is a presentation adapter: it is expected to ship Livewire components (and Blade views) that render profile screens, while the business rules, models, and persistence live in a separate domain package (typically liberusoftware/profiles or equivalent). Plan to install both.

Minimum steps:

1. Confirm prerequisites — a Laravel app on the Livewire version the package targets (check composer.json for livewire/livewire constraints), plus the core profiles/domain module. Install the domain module first; the adapter is useless alone.
2. Require the package:

   composer require liberusoftware/profiles-livewire
   

   Laravel package discovery should register the service provider automatically; verify with php artisan about or by checking bootstrap/cache/packages.php.
3. Publish what's publishable (if the provider exposes tags):

   php artisan vendor:publish --provider="Liberu\Profiles\Livewire\ProfilesLivewireServiceProvider"
   

   Look for config (config/profiles-livewire.php) and views.
4. Where to look first in the repo:
   • The service provider — this is the source of truth for component aliases (Livewire::component(...)) and view namespaces.
   • src/Livewire/ (or src/Http/Livewire/) — the component classes and their public properties/events.
   • resources/views/ — the Blade markup, which tells you what CSS framework and layout assumptions are baked in.
   • routes/ — if present, it may auto-register /profile style endpoints; if absent, you wire routes yourself.
   • README.md and composer.json require block — the latter reveals which domain package version this adapter was built against.
5. First use case — drop the edit component into an authenticated page:

   <livewire:profiles.profile-edit />
   

   (Confirm the exact alias via php artisan livewire:list on Livewire 3, or by reading the provider.) Wrap the page in auth middleware; profile adapters almost always assume an authenticated user.

Implementation Patterns

Embed, don't fork. The intended workflow is to mount components inside your own pages rather than copy their markup:

{{-- resources/views/pages/account.blade.php --}}
<x-app-layout>
    <livewire:profiles.profile-view :user="auth()->user()" />
    <livewire:profiles.profile-edit :user="auth()->user()" />
</x-app-layout>

Pass models explicitly where the component accepts them; this lets you reuse the same component for admin editing of other users instead of only auth()->user().

Route wrapping. If the package doesn't ship routes, create thin ones:

Route::middleware(['auth', 'verified'])->group(function () {
    Route::get('/profile', ProfilePage::class)->name('profile');
});

Keep the route file in your app, not the vendor directory, so upgrades stay clean.

Compose with domain actions. Because this is an adapter, treat its components as view-layer controllers. When you need extra behavior (audit logging, notifications, tenant scoping), prefer:

• Extending the component and overriding the save/update method to call your domain action, or
• Listening to events the component dispatches (e.g., profile-updated) and reacting in your own listeners.

Customize via published views, not vendor edits.

php artisan vendor:publish --tag=profiles-livewire-views

Then override the published Blade files. If the package only exposes a view namespace (profiles-livewire::livewire.profile-edit), you can override individual views by placing files at the same path under resources/views/vendor/profiles-livewire/.

Avatar/file uploads. Most profile adapters include an avatar component. Configure the disk explicitly:

// config/filesystems.php
'profiles' => ['driver' => 's3', 'root' => 'avatars', ...],

and check whether the component reads a config key (profiles-livewire.avatar.disk) or hardcodes public. If hardcoded, subclass and override the property.

Testing. Livewire components are cheap to test:

Livewire::actingAs($user)
    ->test('profiles.profile-edit')
    ->set('name', 'New Name')
    ->call('save')
    ->assertHasNoErrors();

$this->assertDatabaseHas('profiles', ['name' => 'New Name']);

This is the fastest way to discover a component's actual public property names and validation rules — faster than reading source.

Styling. Liberu modules generally assume Tailwind. If your app uses something else (Bootstrap, CSS modules), publish the views and port the classes rather than fighting the vendor markup.

Gotchas and Tips

• The adapter is not the domain. The single most common failure mode is installing only this package and getting "class not found" or missing model errors. Check composer.json require for the domain package and install it first.
• License is NOASSERTION. That is not "MIT." Before production use, read LICENSE in the repo and confirm the terms with the maintainers. Do not assume permissive licensing.
• Zero stars, zero dependents, release date in 2026. Treat this as unvetted. Pin an exact version ("liberusoftware/profiles-livewire": "1.0.0"), vendor the source into review, and write integration tests before relying on it. A future-dated release also suggests metadata problems — verify the tag actually matches the code.
• Livewire 2 vs 3 syntax. $emit/$dispatch, wire:model vs wire:model.live, and @livewireStyles requirements differ. Check the composer constraint and the markup before assuming.
• Component alias registration. If <livewire:profiles.profile-edit /> throws "component not found," inspect the provider for Livewire::component('profiles.profile-edit', ProfileEdit::class) calls. Older packages sometimes skip auto-registration; you can register manually in your AppServiceProvider.
• Authorization gaps. Presentation adapters frequently assume auth middleware is applied by you. Verify every component either calls $this->authorize() or that your route applies the right policy. Test as an unauthenticated user and as a user editing someone else's profile.
• View namespace collisions. If you also publish views from the domain module, both may target resources/views/vendor/profiles/. Check namespace prefixes in the provider before publishing, or you'll silently override the wrong layer.
• Event payloads drift. If you listen to profile-updated or similar, assert the payload shape in a test — minor releases of small packages change these without notice.
• Debugging checklist:
  • php artisan livewire:list — confirm the component is registered.
  • php artisan view:clear && php artisan config:clear — stale caches mask publishing mistakes.
  • storage/logs/laravel.log — missing view namespace errors are reported as View [profiles-livewire::...] not found.
  • php artisan route:list --path=profile — confirm routes exist if you expected auto-registration.
• Extension point of last resort. If the components are too opinionated, subclass them and override render() and the save method, then register your subclass under your own alias. This keeps you upgrade-compatible at the class level even when the markup changes.